Get best of the week

Kubernetes: open source vs vendor

Hi, my name is Dmitry Krasnov. For over five years now, I have been administering Kubernetes clusters and building complex microservice architectures. Earlier this year, we launched Kubernetes cluster management service based on Containerum. Taking this opportunity, I’ll tell you what this Kubernetes is and how integration with the vendor differs from open source.

For starters, what is Kubernetes. This is a system for managing containers on a large number of hosts. From the Greek, by the way, it is translated as “pilot” or “helmsman”. Originally developed by Google, after which the Cloud Native Computing Foundation, an international non-profit organization that brings together leading global developers, end users and container technology providers, was transferred as a technological contribution.



Steer a large number of containers


Now let's see what kind of containers these are. This application with all its surroundings - mainly libraries on which the program depends. All this is packaged in archives and presented in the form of an image that can be run regardless of the operating system, tested and not only. But there is a problem - managing containers on a large number of hosts is very difficult. Therefore, Kubernetes was created.

A container image is an application plus its dependencies. The application, its dependencies and the image of the OS file system are located in different parts of the image, the so-called layers. Layers can be reused for different containers. For example, for all applications in the company, the Ubuntu base layer can be used. When starting containers, there is no need to store multiple copies of one base layer on the host. This allows you to optimize the storage and delivery of images.

When we want to start the application from the container, the necessary layers are superimposed on each other and an overlay file system is formed. A layer for recording is superimposed on top, which, when the container is stopped, is deleted. This ensures that when you start the container, the application will always have the same environment, which cannot be changed. This ensures reproducibility of the environment on different host operating systems. Whether it be Ubuntu or CentOS, the environment will always be the same. In addition, the container is isolated from the host using the mechanisms built into the Linux kernel. Applications in the container do not see 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 these is Docker. It allows you to ensure the full life cycle of containers. However, it only works on one host. If you need to manage containers on multiple hosts, Docker can turn the lives of engineers into hell. That's why Kubernetes was created.

The demand for Kubernetes is precisely due to the ability to steer groups of containers on multiple hosts as some single entities. The popularity of the system provides the ability to build DevOps or Development Operations, in which Kubernetes is used to start the processes of this DevOps itself.



Figure 1. Schematic representation of how Kubernetes works

Full automation


DevOps, in principle, is an automation of the development process. Roughly speaking, developers write code that is poured into the repository. Then this code can be automatically collected 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 participation from the developers themselves. Due to this, the assembly is significantly accelerated, since the developer does not have to do this on his computer - he just writes a piece of code, pushes the code into the repository, and then the pipeline starts, which may include the assembly, testing, rolling out process. And this happens with every commit, so testing is ongoing.

At the same time, using the container allows you to be sure that the entire environment of this program will go into production exactly in the form in which it was tested. That is, there will be no problems from the category “on the test there were some versions, in production - others, but when set - everything fell”. 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, you will need a huge staff. That's why we use Kubernetes.

Pros, Pros, Pros


If we talk about the advantages of Kubernetes as a platform, then it has significant advantages in terms of managing the microservice architecture.

  • . — . , — . . , Kubernetes .
  • . Kubernetes . . , . Kubernetes , Service Discovery. IP- Kubernetes. health check` .
  • . . Kubernetes ConfigMap`. . , .
  • Persistent Volumes. , , . . Kubernetes — Persistent Volumes. , , . , .
  • Load Balancer. , Kubernetes Deployment, StatefulSet .., . . Kubernetes . , ? , . Kubernetes Load Balancer. . . , . Kubernetes.

Kubernetes is best at launching microservice architectures. Implementing a system in classical architecture is possible, but pointless. If the application cannot work in several replicas, then what is the difference - in Kubernetes or not?

Open source Kubernetes


Open source Kubernetes is a great thing: it installed and works. You can deploy on your iron servers, on your infrastructure, put wizards and workers on which all applications will run. And most importantly - all this is free. However, there are nuances.

  • The first is the exactingness of the knowledge and experience of administrators and engineers who will deploy and accompany all this. Since the client receives complete freedom of action in the cluster, he bears the responsibility for the operability of the cluster. And to break everything here is very simple.
  • The second is the lack of integration. If you run Kubernetes without some popular virtualization platform, you won’t get all the benefits of the program. Such as using Persistent Volumes and Load balancer services.



Figure 2. The 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 that is already configured and ready to work.
  • Secondly, the vendor itself sets up a cluster and configures integration with the cloud.

How is this happening with us. The engineer who launches the cluster indicates how many workers he needs and with what parameters (for example, 5 workers, each with 10 CPUs, 16 GB of RAM and, say, 100 GB of disk). Then it gains 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 vendor’s area of ​​responsibility (if the service is provided according to the managed service model).

However, such a 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 the client wants to tie some specific functionality to Kubernetes, for example, authentication via LDAP, and the management plane configuration does not allow this.



Figure 3. An example 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 wants to do what he does. But a great chance to shoot himself in the leg. With Vendors, this is more complicated, because everything is thought out and configured for the company. The biggest drawback of open source Kubernetes is the requirement for specialists. With a vendor, the company is spared this headache, but it will have to decide whether to pay its specialists or the vendor.





Well, the pros are obvious, the cons are also known. Invariably one thing: Kubernetes solves a lot of problems by automating the management of multiple 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 provider #CloudMTS

More articles:


All Articles