Hello, my name is Dmitry Krasnov. For more than five years I have been administering Kubernetes clusters and building complex microservice architectures. At the beginning of this year, we launched a Kubernetes cluster management service based on Containerum. Taking this opportunity, I will tell you what this very Kubernetes is and how integration with the vendor differs from open source.
To begin with, what is . It is a system for managing containers on a large number of hosts. From Greek, by the way, it is translated as "pilot" or "helmsman". Originally developed by Google, then transferred as a technology contribution to the Cloud Native Computing Foundation, an international non-profit organization that brings together the world's leading developers, end users and container technology providers.
Drive a large number of containers
Now let's figure out what these containers are. This is an application with all its environment - basically, the libraries on which the program depends. All this is packed into archives and presented as an image that can be run regardless of the operating system, tested, and more. But there is a problem - it is very difficult to manage containers on a large number of hosts. This is why Kubernetes was created.
A container image is an application plus its dependencies. The application, its dependencies, and the OS file system image are located in different parts of the image, the so-called layers. Layers can be reused for different containers. For example, all applications in a company could use the Ubuntu base layer. When running containers, there is no need to keep multiple copies of the same base layer on the host. This allows you to optimize the storage and delivery of images.
When we want to run an application from a container, the necessary layers are superimposed on each other and an overlay file system is formed. A recording layer is superimposed on top, which, when the container stops, is removed. This ensures that when the container is launched, the application will always have the same environment, which cannot be changed. This guarantees reproducibility of the environment on different host OSes. Whether it's Ubuntu or CentOS, the environment will always be the same. In addition, the container is isolated from the host using mechanisms built into the Linux kernel. Applications in the container do not see the files, processes of the host and neighboring containers. This isolation of applications from the host OS provides an additional layer of security.
There are many tools for managing containers on the host. The most popular of them is Docker. It allows you to provide a full life cycle of containers. However, it only works on one host. With the need to manage containers across multiple hosts, Docker can make life hell for engineers. This is why Kubernetes was created.
The demand for Kubernetes is precisely due to the ability to steer groups of containers on multiple hosts as some kind of single entity. The popularity of the system provides the ability to build DevOps or Development Operations, in which Kubernetes is used to run the processes of this very DevOps.
Figure 1. Schematic representation of how Kubernetes works
Full automation
DevOps, in principle, is the automation of the development process. Roughly speaking, developers write code that is uploaded to the repository. Then this code can be automatically assembled immediately into a container with all libraries, tested and “rolled out” to the next stage - Staging, and then immediately to Production.
Together with Kubernetes, DevOps allows you to automate this process so that it proceeds with little or no involvement of the developers themselves. Due to this, the assembly is significantly accelerated, since the developer does not have to do this on his computer - he simply writes a piece of code, pushes the code to the repository, after which the pipeline is launched, which may include the process of assembly, testing, rollout. And this happens with every commit, so testing happens all the time.
At the same time, using a container allows you to be sure that the entire environment of this program will be released into production in the form in which it was tested. That is, there will be no problems from the category “there were some versions on the test, others in production, but they put everything down.” And since today we have a trend towards microservice architecture, when instead of one huge application there are hundreds of small ones, in order to administer them manually, a huge staff will be required. That's why we use Kubernetes.
Pros, pros, pros
If we talk about the merits of Kubernetes as a platform, then it has significant advantages in terms of microservice architecture management.
- Managing multiple replicas. The most important thing is the management of containers on multiple hosts. And more importantly, managing multiple application replicas in containers as a single entity. Thanks to this, engineers do not have to take care of each individual container. If one of the containers goes down, then Kubernetes will see this and restart it again.
- cluster network. Kubernetes also has a so-called cluster network with its own address space. Thanks to this, each pod has its own address. A pod is the smallest structural unit of a cluster in which containers are directly launched. In addition, Kubernetes has functionality that combines a load balancer and Service Discovery. This allows you to get rid of the manual management of IP addresses and put this task on the shoulders of Kubernetes. And automatic health checks will help detect problems and redirect traffic to working pods.
- Configuration management. When managing a large number of applications, it becomes difficult to manage application configuration. For this, Kubernetes has special ConfigMap resources. They allow you to centrally store configurations and substitute them into pods when applications are launched. This mechanism allows you to guarantee the consistency of the configuration in at least ten, even in a hundred application replicas.
- Persistent volumes. Containers are inherently immutable and when the container is stopped, all data written to the file system will be destroyed. But some applications store data directly on disk. To solve this problem, Kubernetes has a disk storage management functionality called Persistent Volumes. This mechanism uses external storage for data, it can push persistent storage, block or file, into containers. This solution allows you to store data separately from the workers, which saves them in the event of a breakdown of these same workers.
- load balancer. Even though we manage abstract entities like Deployment, StatefulSet, etc. in Kubernetes, ultimately containers run on ordinary virtual machines or iron servers. They are not perfect and can fall at any moment. Kubernetes will see this and redirect internal traffic to other replicas. But what to do with traffic that comes from outside? If you simply direct traffic to one of the workers, if it goes down, the service will become unavailable. To solve this problem, Kubernetes has services like Load Balancer. They are designed to automatically configure an external cloud balancer for all workers in the cluster. This external balancer directs external traffic to the workers and monitors their status itself. If one or more workers become unavailable, then the traffic is redirected to others. This allows you to create highly available services using Kubernetes.
Kubernetes performs best when launching microservice architectures. It is possible to introduce the system into the classical architecture, but it is pointless. If an application can't run across multiple replicas, then what's the difference - in Kubernetes or not?
Open source Kubernetes
Open source Kubernetes is a great thing: installed and running. You can deploy on your iron servers, on your infrastructure, install masters and workers on which all applications will run. And most importantly, it's all free. However, there are nuances.
- The first is the demands on the knowledge and experience of administrators and engineers who will deploy and maintain all this. Since the client receives complete freedom of action in the cluster, he is responsible for the health of the cluster himself. And it's very easy to break everything here.
- The second is the lack of integration. If you run Kubernetes without some popular virtualization platform, you will not get all the benefits of the program. Such as using Persistent Volumes and Load balancer services.
Figure 2. k8s architecture
Kubernetes from the vendor
Integration with a cloud provider provides two options:
- Firstly, a person can simply click on the "create a cluster" button and get a cluster already configured and ready to work.
- Secondly, the vendor himself installs the cluster and sets up integration with the cloud.
How it happens with us. The engineer who starts the cluster specifies how many workers he needs and with what parameters (for example, 5 workers, each for 10 CPUs, 16 GB of RAM and, say, 100 GB of disk). Then it gets access to the already formed cluster. At the same time, the workers on which the load is launched are completely given to the client, but the entire management plane remains in the area of responsibility of the vendor (if the service is provided according to the managed service model).
However, this scheme has its drawbacks. Due to the fact that the management plane remains with the vendor, the vendor does not give full access to the client, and this reduces the flexibility in working with Kubernetes. Sometimes it happens that a client wants to attach some specific functionality to Kubernetes, for example, authentication via LDAP, but the management plane configuration does not allow this.
Figure 3. Example of a Kubernetes cluster from a cloud provider
What to choose: open source or vendor
So, open source Kubernetes or vendor? If we take open source Kubernetes, then the user does what he wants, then he does with it. But there is a great chance of shooting yourself in the foot. With a vendor it is more difficult, because everything is thought out and configured for the company. The biggest disadvantage of open source Kubernetes is the requirement for specialists. With a vendor company, this headache is spared, but it will have to decide whether to pay its specialists or the vendor.
Well, the pros are obvious, the cons are also known. One thing remains the same: Kubernetes solves a lot of problems by automating the management of many containers. And which one to choose, open source or vendor - everyone decides for himself.
The article was prepared by Dmitry Krasnov, lead architect of the Containerum service of the #CloudMTS provider
Source: habr.com