(**) Translated with www.DeepL.com/Translator
“Kubernetes” is a container orchestrator for “Docker” (but not only). “Docker” allows to create containers from an image, I won’t go into detail here, the web is full of documentations on this subject. “Kubernetes” manipulates “Docker”, so “Kubernetes” alone is useless, while “Docker” works perfectly independently.
Images and “Docker” containers
A “Docker image” contains an application with all its software dependencies. A Container is an instance of this image. Compared to object programming, an image is a “class”, a container is a manipulable object.
I can therefore, within the limits of the host server’s resources, start as many instances (containers) of an image as I want on a host server.
Why use “Docker”?
There are several reasons for this, but in production, what interests us above all: to facilitate deployments…
Let’s take this example, I want to install an “Apache” type web server, at choice :
-
I take a virtual server (VM) or a physical server (bare metal), like “Linux Debian” and I install “Apache” with the command:
apt-get -y install apache2. The service is installed on the server and directly accessible. If you want to add another “Apache2” service, it’s complicated : how to install two “Apache2” services, make them listen on two different ports… This operation takes time and requires a good knowledge in terms of system administration (sysadmin). -
The other solution is to use “Docker”. I will start two containers from the single “Apache2” image. I have no configuration to change, both will listen on port 80, but in their respective execution area (notion of isolation). To expose these two services, I would still need two ports (80 and 8080) on the “host” server. It will be enough to tell “Docker” to “route” port 80 of the “host” server to port 80 of the first Container, and port 8080 of the “host” server to port 80 of the second Container. (80->80 and 8080->80).
Processes launched from the “Docker” have no knowledge of the host or other containers, this process runs in a “cage” (jail) completely isolated from the rest of the system. “Docker” therefore implements a communication system between the host server and a container, but also a communication system that allows the containers to communicate with each other.
Use of “Docker”
Here again I don’t go into detail, other people have written entire books on “Docker”, what interests me is :
- Its installation on a server
- Recover or make images
- Manage containers (start, stop, add, delete…)
- Expose (network) containers to be used on the local network, internet…
- Access storage resources, databases,… which can also be “containerized”.
“Kubernetes”
Once “Docker” is understood, you quickly realize, especially if you are doing scalability, that it becomes “very, very, very complicated” to manage. This is why the “sysadmin” needs an Orchestrator. This is a layer superior to “Docker” which makes it easier to manage all the containers needed in production.
So “easily” is not the right term, because “Kubernetes”: It’s complicated…
Keep in mind: “Kubernetes” is designed for Cloud providers such as Ovh, Hetzner, Google, Amazon, Azure,…
But when everything works, container management becomes… much simpler. You don’t have to search on which server is installed on which container, “Kubernetes” takes care of balancing the demand. “Kubernetes” also allows to store the configuration of the containers in a single place (configmap), to centralize persistent storage spaces and much more.
For example I have an application “Docker” image, I create its configuration and store it in a “configmap” entry, I then create a “Kubernetes” configuration that indicates the name of the “Docker” image to use, the “configmap” entry and I deploy with “Kubernetes”. The scaling ? It’s only one command, “Kubernetes” takes care of the rest.
Adding an application is first of all describing it: list of necessary containers, its resources… We will talk about “deployment”. Once the application is started, the notion of “Pod” will be evoked.
A Pod is an application unit (started) for “Kubernetes”, which does not know directly the notion of container. Keep in mind : A container is necessarily embedded in a “pod “, a pod can integrate several containers. This allows for easier communication between the containers contained in a pod, all containers can communicate on the “localhost (127.0.0.1)” address of the “pod”.