Many users of Docker containers wonder how to manage the elements of a large-scale system on multiple hosts, and how to bring them all into a balanced state. Kubernetes is the solution!
In this article, the Clever team showcases the basic concepts and architecture elements of this open-source technology. Enjoy reading and you will see that running Docker containers on multiple hosts is not as tricky as it seems.
Kubernetes in a Nutshell
One more weighty advantage is that the system provides a high-level API and optimal container grouping, allowing you to define container pools, balance loads, and also specify the location of each element.
Benefits of Kubernetes
If you have never used this technology, you are missing out on its many benefits! Here are the most notable ones:
- Strong architecture. Google engineers have applied their impressive knowledge and experience to create this stable and secure system.
- Easy adaptability. This platform can be synced with most modern tools, services, frameworks, and programming languages. Since developers are constantly updating the system, it is very flexible and user-friendly, making Kubernetes one of the best solutions in its niche.
- A wide set of useful features. Almost no task is impossible for this platform. You can quickly find the necessary features and effectively tackle even the most complex container-related projects.
- Durability and smooth operation, even with extreme workloads.
- Leading developers and engineers are taking note of Kubernetes, so we can expect it to continue evolving, growing, and offering innovative solutions to various categories of users.
Below are the most important concepts you should know to start working with Kubernetes.
Node: a mechanism within a cluster.
Pod (module):p Even though some modules include a single container, this is by far not the limit. There can be as many containers as you need. Single containers are called modules, since all elements work the way they would work on a single host without containers.
Modules share common namespaces and do not work in isolation from one another. Consequently, they share a certain IP address and port, and can find each other through localhost, or interact via IPC.
In addition, all containers in a module have access to shared volumes. That is, they can mount them and work on the same volumes if necessary. To achieve this functionality, a module must work as a single deployable part. Each individual sample (with all its containers) is intended for a holistic launch.
This is a new concept for the typical Docker user. Even though Giant Swarm users have long been able to use modules without Kubernetes, only a few actually do so. For some people, this application means returning from “one process per container” to “deploying the entire LAMP at once.”
However, this is not how modules are meant to be used. The value of the module concept boils down to the joint support and management of auxiliary containers, along with the application container. This simplifies processes such as logging or monitoring agents and using backup tools.
If you are a newbie who does not know how to use modules, you can start by using them with one container, just as you would when working with Docker.
A module is the most basic concept in Kubernetes. By itself, it is ephemeral. If it dies, it cannot be transferred to a new node. If you want to keep one or more instances valid, you need another concept – replica sets.
Replica sets: Currently, the main difference is that replica sets support more advanced value-based switches. They are more flexible than replication controllers. Nevertheless, the following explanation is suitable for both.
The module itself is ephemeral and can be restarted only if the node on which it was launched has stopped. This state allows replica sets to come into effect. You can make sure the specified number of module instances (or replicas) are running at any moment in time.
If you want the module to remain valid, you need to make sure there is an appropriate set of replicas, including the replica for a relevant module. In this case, the replica set will take care of restarting the instances.
As mentioned earlier, the replica set ensures that the specified number of replicas is started. By changing the number of replicas in the definition of a replica set, you can scale the modules by turning them on or off.
A set of replicas can control not only a specific module but also a group of different modules united by a common label. This allows you to create a list of replicas, for example, to scale all the modules representing the app frontend without using identical replica lists for each frontend module.
You can include the module definition directly in the replica set definition. This way you can manage both at once.
Replication Controllers: These elements ensure that a necessary set of replicas is launched at any moment in time.
Services: These are abstractions defining a logical pod set and the access policy for it.
Volumes:Directories that can contain data accessible in the container.
Labels: Combinations of keys and values attached to objects, for example, pods. You can use them while creating and selecting object sets.
Kubectl Command Line Interface: management tool.
Each active cluster contains an agent working on separate nodes (kubelet) and wizard features (APIs, scheduler, etc) synced with a distributed storage. The below image shows the optimal state, with some nuances to be elaborated. For example, a kubelet (all the elements, in fact) should run on its own in the container. This way the scheduler can be made 100% connectable.
We can divide the architecture into features that work on each node, and features that belong to a higher level and apply to all the system elements. The features necessary for controlling the node from the wizard side and for installing applications work on each node. Of course, Docker is used for each node. It provides image loading and container launching.
This element manages different system components.
Each node is equipped with a balancer for proxy. It can redirect TCP and UDP data within backend environment. You can monitor and change its settings via API.
System management elements
The management system includes several elements. In most of today’s projects, all these elements run on the main node. However, developers promise to change this to create favorable conditions for building a failover cluster. Such elements are well synced and provide a single cluster representation.
The state of the wizard is reflected in etcd, showing the security of configuration data and informing other components about a state change.
This tool binds non-running pods to nodes. This is done via the /binding API command. This element is connectable. Developers claim that work with several schedulers at once is quite possible.
Internal API is designed to ensure the smooth operation of the master server. It is a CRUD system with built-in business logic, realized via separate elements. As a rule, it deals with REST processes, monitors them ,and changes the corresponding elements in etcd and, sporadically, events in other directories.
We have considered the technology’s key features. But of course, the opportunities Kubernetes provides go beyond them.
All other processes running on the general system level can be managed via a special controller manager. This unit can be divided into separate categories, to create independent connections between them. With a strict and clear structure, it will be much easier for you to find and change different elements in respective controllers.
We hope the above material proves useful. If you have additional Kubernetes-related questions, do not hesitate to ask the Clever team. We are happy to consult with you.