Everyone is containerizing with Docker. Thanks to this we can vastly implement new software versions, however, this post is not about the advantages of containerization. I want to focus more on Kubernetes.
In my work, I have very often encountered problems with scaling the application. When the load increases, you need to up the right number of containers to handle it. We must do it quickly with one command and not by calling another „docker run”. Thanks to this action savings appear.
The number of deployments based on Docker that we can have in our companies makes it necessary to manage a container farm. Nothing can be done without the right tools when developing custom software services. Additionally, it is necessary to keep the configuration in a place that can be shared to easily restore the services. So here we have a concept of orchestration.
The phenomenon of containerization is not so new, but the orchestration relatively is. If we already decided to put our software into Docker, then in order not to be a victim of our success, sooner or later, we will have to choose a solution that will provide us a stability when scaling up the project. It is worth to know the concept even if we do not plan to increase the size of the stack beyond one frontend container and one backend container.
What is the orchestration?
Let’s get through some basic definitions for rookies. An orchestration is a mechanism that allows you to administrate servers cluster with running a containerization service.
Kubernetes is a big open source project originally designed by Google. Huge community means that code can have very few bugs, but if from the beginning it was written wrong or a community doesn’t have enough skills to make a code safe, then there may be a lot of holes in it, like in WordPress for example.
K8s (synonym for „Kubernetes”) is free and anyone can implement it on their own infrastructure. It’s great for managing containers on development servers that require frequent changes.
I don’t have to say that initiation of orchestration is necessary if you have a bunch of servers that run many applications in containers. Thanks to the orchestration, we can keep our configuration in the repository, create changes and easily deploy, even in a case of accidental removal of the given containers. It also allows for comfortable scaling which is needed, when we want our solutions to have high availability.
Docker Swarm vs Kubernetes: what’s the difference?
It is worth noting that Docker himself encourages to use Kubernetes. Kubernetes gives you more options to scale your applications. There was a case when I wanted to have many replicas of Apache Kafka and ZooKeeper and doing it on Docker Swarm failed. However, with Kubernetes it did not cause any major problems.
Both orchestration technologies allow you to define in the file what applications you want to run and how. However, Kubernetes has many types of so-called manifestos. It gives more flexibility. In order to define deployments for Docker Swarm, we must additionally install the Docker Compose tool, for which the files must be in the right version.
Namespaces give us separation of our deployments. If we properly watch where we put the containers, then, for example, we don’t need to create additional Kubernetes clusters and fear data overwriting. With one cluster we can better manage our resources.
Kubernetes has native service discovery technology using etc. In addition, it allows balancing the load. It makes the services register under a specific name and can be easily recognized by the name of the space.
For some people, it may be a defect that the Docker Compose only allows you to use YAML files when Kubernetes also accepts JSON.
If we want to use Kubernetes in the cloud we can use various solutions such as:
- Google Container Engine (Google),
- Cloud Kubernetes Service (IBM),
- Azure Kubernetes Service (Microsoft),
- VMware Kubernetes Engine (VMware).
If someone used Docker Compose earlier it will be difficult for him to go to manifestos but I think that is worth considering the benefits. There is a similar situation with the Vi editor which is very difficult to use in the beginning, but the more time we spend using it, the more it speeds up our work.
The main servers in the Kubernetes cluster provide APIs implementing the RESTful interface. Thanks to that we can communicate with the cluster using various programs.
Why companies should start using Kubernetes in DevOps?
The benefits of having your own applications in containers are obvious. Orchestration using Kubernetes gives you the ability to automatically handle the network, store data (you can also choose your own Software Defined Storage), autoscaling, logging, notifications etc. However, the most important factor for business is that K8s can significantly reduce costs by better use of hardware resources without affecting application performance or user experience and even more – you can see a performance increase.
