In my opinion, Kubernetes becomes necessary not in high scalability scenarios, but first when high availability is required.
It is a common misconception that when the number of students increases, your first priority is to improve the performance of the platform, and thus you need to increase the number of LMS workers.
In fact, when the number of students increases, your chief concern should be to guarantee high availability. This means that you should (among other things) spread the load over multiple LMS servers – but not only.
In practice, there are many other components which can threaten the availability of your platform. In particular, all data storage components (Elasticsearch, Mongodb, Mysql, Redis, filesystem).
tutor local) really does not work well in multi-server environments. It simply was not designed for that use case (as opposed to Docker swarm). Well, there are ways to load-balance multiple deployments, but it’s very hackish. Thus, when high availability becomes necessary, you should consider switching to a different container orchestrator. There is a swarm (pun intended) of them out there; I made the choice to support Kubernetes in Tutor.
But remember that Kubernetes is not a silver bullet: as I noted above, when chasing high availability, you should also make sure that your data layer is also highly available. Thus, you should move your MySQL/Mongodb/Elasticsearch/Redis/file to separate clusters. Actually, this can be done prior to the move to Kubernetes. It makes perfect sense to take the data layer out of
tutor local prior to making the switch to Kubernetes (or any other deployment target).