Kubernetes… A word behind which actually hides the answer to a fairly simple need: How to deploy applications without worrying about the underlying systems and network infrastructure?
Today one of the most important buzzwords in IT CVs, kubernetes is a project initiated by google.
Disclaimer: I want to specify that this is a popularization article. I will therefore make shortcuts to facilitate understanding, while trying to be as close to reality as possible. I invite you to read other articles, much more technically advanced, if you want to become an expert in this tool.
But what is this thing everyone is talking about?
When we say it’s a buzzword, it’s true. But it’s not just a fad. The tool was designed to simplify the management of an Information System.
Just that.
Basically, take the biggest part of what you’ve acquired in experience managing IT server parks, and throw it in the trash.
We’re going to do something else
However, kubernetes is neither the only available solution, nor the solution to everything. Swarm or mesos can bring solutions comparable to kubernetes. But when the project has Google behind it, well it starts with good chances of succeeding in coming first. (mesos is under apache license, and swarm comes from docker)
It’s as much a concept, as a tool
So, we need to clarify some concepts. Kubernetes has as a prerequisite the use of containers. There are several types, but we will focus on the most widespread solution: Docker
I talk more in detail about docker in my article that deals with the subject and in the one that deals with virtualization. I invite you to read them to understand the rest.
Like Mesos, which claims to be an OS (operating system) of datacenter, Kubernetes has the vocation to hide machines from the point of view of users and applications, aggregating them into clusters and centralizing the management and deployment of applications.
Conceptually, it looks like this with applications in green
In principle, I throw my application into it, and kubernetes takes care of finding it a place, or places (according to the need in number of instances) and creates a path allowing me to contact it.
To do this, Kubernetes is based on a master and slave system. Masters organize, slaves execute commands.
Masters are distributed on 1, 3, 5 or 7 machines (an odd number, to allow them to elect a leader who will centralize orders).
Slaves are variable in number, and are the machines on which our applications run.
The slave, with the command app, and docker containers
Slaves report to the master their available resources and the master manages all the resources of the slaves. When we want to start a docker container on the cluster, we address the config (in the form of a yaml config file, most of the time, and via the kubectl command) to the master, who orders one of its slaves to start this container. This container is associated with the virtual network that kubernetes offers between its instances.
The group of masters, in yellow, and the slaves orbiting around
Via this virtual network, different containerized applications can talk to each other and to the outside of the kubernetes cluster. A particular set of rules, called ingress allows the outside to reach some of these applications via load-balancers offering a secure access portal.
Without specific rules, applications are not visible outside kubernetes. It’s even a choice. Many are the applications that will never leave the cluster, it behaving like a real information system internally. We indeed find network, applications, ports, load-balancers.
So, it’s great, when do we start?
At the risk of surprising you, you shouldn’t put it everywhere.
Kubernetes is based on the container concept. Who says container, says your application is stateless. In two words, this means that the application part must not keep any information. Each restart makes it lose accumulated data, not stored outside the container (in a database for example). The container’s file system is ephemeral.
What’s the point you’ll say? It helps with scalability, scaling. We remove the application’s hooks to make it easily transportable and duplicable.
So of course, there are ways to force our stateful applications (the opposite of stateless, therefore) into kubernetes. But I wouldn’t recommend them. It’s more skillful not to force tools to adapt to our needs, but rather to find a tool that corresponds to what we expect. In this framework, it’s quite excluded to put databases in kubernetes. For this, I would advise you mesos, via the DC/OS distribution, which is tailored for stateful, or any solution other than Kube.
If you absolutely want to do it, you can ignore these recommendations, but know that it won’t be without impact on performance, or the agility of your infrastructure.
How to try it?
With a prototype.
The best way to get started is to use minikube. Tutorials to install it are legion on the net, and the single-node (server) kubernetes solution that minikube represents will allow you to simply understand if your applications are ready to take the step. The minikube doc, in French, is here.
If you’re familiar with docker, all this should go smoothly. If not, I invite you to become so, so much it’s becoming a standard. You can also take a look at my article on docker.