Kubernetes, what is it?
Find more tutorials explaining the basics of a subject in ten minutes with the tag what is it.
Go read Docker, what is it? for a quick reminder.
Kubernetes, also known as K8s or Kube, is a technology orchestrating containers, like Docker containers,
for hightly scalable applications.
On a machine, the operating system is responsible for the management of the memory, the network,
the life and death of the processes and so on... You can imagine Kubernetes as a cluster wide
operating system: dispatching the load on several machines, monitoring the life and death of
the containers, attributing IP addresses to services and so on...
Using YAML or JSON files, Kubernetes allows to easily describe a complete architecture
and to deploy it on the main cloud technologies like Amazon Web Services or Google Cloud Platform.
A Kubernetes cluster is composed of 2 kinds of nodes:
the masters orchestrating the whole system and the non-master nodes, also known as "minions",
receiving the orders, regularly reporting and executing the containerized applications.
K8s exposes a REST API for the communication with a master: monitoring, upload of the YAML files...
The most common way of interaction with this API is the CLI tool kubectl.
This is a theoretical tutorial. Learn how to put Kubernetes in practice in the next tutorials.
Pods
Kube does not directly deploy and replicate the docker containers on the nodes.
It uses an upper layer, a container of containers, called "pod".
The "pod" is the smallest entity handled by Kubernetes: it's the one being duplicated, deployed,
destroyed by the masters. A pod simulates a complete logical host,
in the old times it would have been the equivalent of one physical or virtual machine.
A pod can run several docker containers: they will share all
the resources of this logical host, like the volumes or the network.
Actually, running several containers in the same pod is in general not a good practice:
it implies that the services provided by the containers are strongly coupled and can't be
deployed or replicated independently. There is however some legitimate cases like for instance
a container running an HTTP server coupled to a container ensuring the monitoring or logging.
When describing the architecture with, for instance a YAML file, you can tell Kubernetes
that you always want X pods running at a time, with a maximum of Y allocated memory for each,
running containers based on a specific docker image.
We call this configuration: the desired state.
Kubernetes is continuously monitoring the pods, always trying to match the desired state.
The basic example: if a pod dies, Kube will recreate another.
Misc info about the pods:
- A pod is always deployed on only one node but a single node can run several clones of the same pod.
- Each pod has a unique IP address and DNS name in the cluster.
- A pod can die and another pod can be created at any moment. You must never target a pod explicitly in any script.
Wait! If I cannot target a pod, how can I communicate with the service offered by my docker containers?
Services
The "service" is a Kubernetes entity, with its own IP address and DNS name.
Kubernetes balances the requests received to a service to a bulk of related pods.
The Kube service is the entry point for accessing the service offered by the docker containers
both from the inside and the outside of the cluster. The creation of a service also involves the
creation of another entity: the entrypoint. Internally, the entrypoint keeps an up-to-date
record of all the pods linked to a service.
If a linked pod dies or is created, Kubernetes will automatically
know and respectively remove or add it to the load balancing of the service.
The link between a service and its pods is made through a system of labels.
For instance, if the service is tagged by the label "tuto4dev_front", all pods with this same label
will be linked to the service. The link can be composed of several labels. A pod can have
additional labels compared to the ones targetted by the service.
Deployments
The "deployment" is the highest layer handling a pod, it manages the creations, the updates
and the rollbacks of the replica sets.
The "replicaset" represents the group of pods linked to a service. For instance, if you want
10 instances of an HTTP server, a ReplicaSet is created with 10 pods.
Updating the declaration of a deployment provokes the creation of a new replicaset.
The old pods from the old replicaset are shut down one by one,
each time involving the creation of a new pod in the new replicaset.
The old replicaset is not automatically destroyed, easing the rollback with a single command.
In this case, the pods are shut down and new pods are created back in the old replicaset.
Processes on the masters and nodes
The master of a cluster is composed of 3 main processes:
- kube-apiserver: the entry point for the clients. It is the process managing the REST API.
- kube-controller-manager: it controls everything and makes sure that the current state of the system matches the desired state.
- kube-scheduler: it gives work to the pods.
The non-master nodes are composed of 2 main processes:
- kubelet: the agent communicating with the master, waiting for work and sending reports. It is the process actually creating the pods. You can access the kubelet at the port 10255 of the node.
- kube-proxy: it manages the network stuff like the IP address attribution and the load balancing.
Learn more about Kubernetes on the official site.
Have a nice day :)