It is literally all over the place: you cannot browse a news site, read the news in this field or consult the Meet-ups of the day without hearing about it … it is Kubernetes.
Net4All offers you a series of articles written by technical experts to help you understand this new essential concept!
Docker, or containerisation , is a concept introduced a few years ago, now well established in the IT realm. It offers advantages in terms of managing the environment required to run the application and is widely used by companies of all sizes.
Kubernetes vs. Docker
To draw a parallel with the world of “classic” virtualisation, Kubernetes is to docker what a hypervisor is to a virtual machine with cluster management.
Today, Kubernetes is the de facto standard for large-scale container management. Its goal is to automate the lifecycle, as well as the maintenance of, containers in a given environment.
Kubernetes is today used and supported by major players in the cloud. This concept allows containers to operate independently of the underlying infrastructure layer.
In addition to being sceptical of the underlying infrastructure, Kubernetes facilitates the development of hybrid infrastructures between a number of cloud providers of different types (private cloud and public cloud). Openshift, a product developed by Redhat and based on Kubernetes, focuses on the hybridisation and instrumentalisation of the solution.
Why Kubernetes ?
Kubernetes has become a fashionable tool that everyone wants to test, because, globally, everyone agrees: Kubernetes is cool.
More precisely, how is Kubernetes to be used, and why?
Kubernetes makes it possible to transform containerisations into large-scale deployment tools: the main advantage is that this allows for integrating deployment processes in terms of continual integration/ongoing development, in order to be able to make your application evolve through the development, staging and production phases in a controlled manner.
If you have fast development processes and your application changes very frequently, it is clear that, when combined with CI/CD, Kubernetes is the link that allows you to apply dynamism all along the chain.
This does not work without taking a certain number of risks: containerisation redistributes responsibilities in terms of keeping interpreters up to date across teams that are not necessarily accustomed to managing these tasks.
The infrastructure is not left behind. Some cloud integrations have difficulty in supporting updates. It is essential to take these elements into account before any production implementation, in order to avoid ending up with an obsolete implementation as soon as it is put in place.
Kubernetes is based on relatively simple concepts:
The “control plane” comprises an API server, a scheduler and a controller manager. All of these components are combined in one machine that we call “Kubernetes master”. This master machine is the conductor of the orchestra, so to speak, the one that will manage the different Kubernetic nodes in charge of running the workload.
An initial infrastructure therefore comprises a master and a minimum of 2 nodes.
As discussed, the main aim of Kubernetes is the abstraction of the “hardware” part. This has the advantage of allowing you to start a Kubernetes cluster on any basic infrastructure: conventional hypervisor, bare metal, public cloud or even raspberry for the brave ones.
This advantage makes Kubernetes very easy to prototype, although the technology itself remains complex.
General Kubernetes Concept
The pod is the smallest entity within the Kubernetes cluster. It is a container, or set of containers, intended for operating a part of the application. However, the “one container per pod” model remains the most widespread.
It is important to take into account that each pod must remain stateless, as pods can be started and stopped by the cluster master on the fly. Everything in the local storage is therefore transitory by default. In order to keep relevant data generated during the life of the pod, it is nevertheless possible to create persistent volumes.
At the network level, each pod is assigned an IP address in the cluster, but is not accessible from the outside. It is possible to access the services provided by the pod directly through this address, but this method of proceeding is not advised, since said services are transitory. It would therefore be more appropriate to go through a service in order to be able to make the pods communicate with one other.
Kubernetes services may be perceived as being load balancers for pods. Their task is to redirect the requests that reach them to one of the associated pods. Each service is entered in the DNS server of the cluster, which allows access to a set of pods with an identifier that remains fixed.
Pods are registered on a service using a selector. This works simply as a tag, and all pods bearing this tag are automatically used as the target of the service.
There are, however, other ways to define a service. It is, for example, possible to enter a fixed IP address as the target of the service, in order to use the service to access a service that is external to the cluster, such as a database.
Services can only be accessed from within the cluster, but, in order to be accessible from the outside, they can be targeted by an ingress controller.
The ingress controller is an essential part of the Kubernetes cluster, being the public entry point for applications. This functions as a reverse proxy in front of an infrastructure, and does, for example, permit a first filtering to be carried out on incoming requests, if the ingress controller selected allows it.
Depending on the domain to access, this makes it possible to access a specific Kubernetes service or a particular “directory”.
The ingress controllers officially supported by the Kubernetes project are nginx and Google Cloud. There are, however, other perfectly compatible solutions, such as HAProxy, Traefik or F5.
When using a Kubernetes cluster managed on a public cloud, it is advisable to use the ingress controller proposed by the cloud in question, in order to interface better with the infrastructure provided.
Kubelet and Container Runtime
Kubelet is an agent running on each node of the cluster. It takes care of the pods running on each node, acting as an intermediary between the orchestrator and the container runtime.
The container runtime is the software that runs the containers. Historically, this role was filled by Docker, but other software, such as containerd or CRI-O, is now able to fill this role. Since the integration of CRI (Container Runtime Interface), the container runtime used is entirely transparent at the cluster level, as well as from the user’s perspective.
Deployments and DaemonSets
Deployments and DaemonSets are ways of ensuring that pods are fully functional in the cluster. They therefore manage the execution of the latter, but likewise their lifecycle, in other words their creation and destruction.
Out of these methods, Deployment is the one most frequently used. It allows for a constant defined number of replicas of a pod in the cluster, while retaining the option of increasing this number manually, or based on metrics.
DaemonSets, on the other hand, are used to deploy internal cluster services (such as log aggregation), since their uniqueness will ensure that a pod replica is available on each node of the cluster.
There are still other ways to manage pods on a Kubernetes cluster, such as the ReplicaSet, which ensures that there is always a given number of replicas of a pod on a cluster, but the latter is often replaced by Deployment, which allows the same work to be carried out while at the same time being more flexible.
Do you have questions or requests regarding Kubernetes? Our technical experts are available to discuss your project.
Guillaume Petitpierre, Linux System Administrator
Following an apprenticeship as a computer scientist (specialising in Android development), Guillaume continued his studies in software development, obtaining his Bachelor’s degree. Since 2017, Guillaume has been managing the deployment and maintenance of client platforms for Net4All.
Kevin Chollet, Linux Division Manager
Kevin is an HES Engineer in Telecommunications, with experience as a freelancer. He joined Net4All in 2014 with the main mission of managing the Linux Division and the infrastructure.