The original post comes from here
Kubernetes is the most popular Open Source technology of the last five years. It was created by Google to allow companies to use container (Docker) applications in production. Today, Kubernetes is the new standard for running applications in the Cloud or on its servers (on-premise). I even heard from a Cloud architect from Azure: "our customers no longer come to us to do Cloud, but to do Kubernetes". That's to say how much a utility software* upsets a whole ecosystem. Despite all the very positive elements we can read about Kubernetes, there are also dark sides. Here are the seven things that nobody will tell you about Kubernetes.
It takes months to use Kubernetes in production.
When you want to go with Kubernetes, you want to know how to do it. There are countless resources and means to create a Kubernetes infrastructure. For example, AWS allows you to create your cluster in only a few minutes. Still, we discover very quickly that this is not enough. To benefit from the power of Kubernetes, you need:
- install and configure a CI/CD
- integrate it with your working environment (git)
- set the monitoring, alerting, and management to deploy services
In short, it takes between 4 and 6 months of work for your Kubernetes to be usable in production. I let you judge for yourself with this checklist of recommendations before going into production.
Kubernetes is complex to operate.
The buzz around Kubernetes is such that one would think that mastering this technology is the minimum for any technical person. Except that Kubernetes requires real system and network knowledge to master the beast. Worse, Kubernetes is not for developers, and it shows from the first 30 seconds of use. Have you ever wondered why there are so many training and providers for Kubernetes? Wouldn't it remind you of the time of Oracle, Windows, VMware certifications? Kubernetes is not as simple as it seems.
Kubernetes doesn't scale to the infinite.
As with all technical solutions, there are "hard limits" to remain in optimal conditions of use. This rule does not spare Kubernetes. There are many limitations to good practice. Whether it is the number of pods (which allows managing one or more containers), the number of workers (a Kubernetes server), or merely the physical resources such as the processor, the memory, and the network. Surprisingly, Kubernetes in the Cloud is even more subject to resource limitations specific to each Cloud provider. For example, AWS limits the number of pods that can run on a worker based on its size. Kubernetes is not magic; it will not allow you to become the next Google effortlessly.
Kubernetes doesn't (yet) allow you to be Cloud agnostic.
Kubernetes is to the Cloud what TCP/IP is to the network. A communication protocol that all the actors (AWS, GCP, Azure, Digital Ocean, ...) of the Cloud are talking about in 2020. The idea behind an agnostic Cloud is to be able to change whenever you want, without any change on your side. Kubernetes is the first step to allow the Cloud to be agnostic. However, much work remains on the network, storage, and management of applications with data (databases, storage). For example, Kubernetes is not made to manage databases (even if you can do it thanks to statefulsets and operators) - which is constraining when you know that 100% of applications need to process and store data in databases. Besides, cloud providers are modifying the internal workings of Kubernetes to integrate it into their infrastructures. Efforts have been made, but there is still a long way to go.
Kubernetes is not as secure as you think.
Kubernetes can host containers - the advantage is that it consumes little CPU and RAM and starts up very quickly. But its most significant disadvantage is to be insecure. A Container is only a process that starts on its host machine, which means that all Containers running on a server can see what other Containers are doing (even if it's not something trivial). The container is often confused with virtual machine (VM) technology, which allows you to isolate an application by virtualizing the hardware. Initiatives like Alcide or Kata Containers offer solutions to secure containers, but if your application is very sensitive to security, then maybe you should not use Kubernetes.
Kubernetes is not the solution to all your problems.
Before using Kubernetes, you already had performance, security, or even organizational problems? Kubernetes will not be able to solve them for you. Worse, it will add others. Kubernetes should not be considered as a solution to all problems. Using Kubernetes requires a significant part of maturity. Developers will have to design applications following new concepts to work appropriately on Kubernetes. The goal of Kubernetes is to simplify the horizontal scaling (on several servers) of applications. Does your business need to add this complexity? Only you have the answer.
Conclusion
Even if I raise some negative points, Kubernetes is a solution that is interesting to consider in 2020. It answers many technical challenges in a very skillful way - especially on the management of applications in a distributed system. However, before you jump into managing your infrastructure with Kubernetes, ask yourself the right questions - what do you need to accomplish? Why would you need to use Kubernetes? What are the alternatives available today? What problem do you want to address?
And you, do you use Kubernetes in production? How do you live it?
Feel free to contact me on Linkedin or Discord to discuss it further.
utility software: Kubernetes is an Application Scheduler. It does nothing more than indicating on which server each application should run. Although the problem is simple to understand, it is very complex to solve. Hence the usefulness of Kubernetes.
Top comments (0)