We all hope that applications are always available, at all hours, every day of the year. How can we make this possible? Come and see, I present to you Kubernetes. Even your competitors have surrendered to this phenomenon, will you?

Server virtualization techniques have evolved towards the use of containers in an increasingly widespread way. With the containers, the “on my machine it worked","What do I have to install?","show me your configuration", etc. In a very brief way, this is because each container is an exact copy of an image and can be executed anywhere, without assuming a change when programming. Therefore, the philosophy of working with containers is no longer "start-stop", but "create-destroy".

Containers solve many problems for us, but not all: what if our service does not respond? What if the machine crashes? What if the CPU is fuming? As well, Kubernetes It comes to provide solutions to these problems and, like containers, they can gallop anywhere.

But what is Kubernetes? In short, he is a container orchestrator. From its basic level, Kubernetes is an opensource platform for running and coordinating containerized applications. Kubernetes automates the management and deployment of these containerized applications.

Its main virtue is to make the components of our application independent through their layers of abstraction, thus, by decoupling them, maintenance is simpler and the ability to self-recover from problems is remarkable. A change in any module will not affect the others and they can be deployed and managed dynamically.

Automate containers with Kubernetes

Sounds good. Let's imagine we have a system with a Nexus, as an artifact manager; un Jenkins, as a continuous integration server; all accessible through an Apache web server and each one in its corresponding container. The Jenkins is down!, Kubernetes builds a new one; Apache traffic is increasing and you need more resources!, Kubernetes replicates an Apache for you; We need to update our version of Nexus!, Kubernetes swaps your container with the old version for the new one. And all this in an unattended way Oooh!

To better understand this wonder called Kubernetes, you have to have a clear idea of how your abstraction layers are organized.

Kubernetes architecture

We start from the bottom:

1. Under. Kubernetes is a container orchestrator whose minimum unit of execution is pods. A pod represents a set of containers running on the same host, so they share resources and an IP address. The life cycle of a pod is ephemeral, and the way to control them is through a deployment.
2. Deployment. This layer controls the state of the pods, adjusting their current and desired (or declared) state to the established control rate. Thus, in the event of a container failure, the deployment is responsible for starting it up again. Therefore, having multiple replicas of the same pod allows for fault tolerance. Each pod has its own IP address, but ensuring that a pod will always have a unique address is not possible. For this reason there are services.
3. Services. They offer one more level of abstraction in communication between pods. If a deployment has a service associated, when the service is accessed, load balancing is performed between all replicas. This favors scalability within each node, since it can grow or decrease according to the need for resources.
4. Nodes. The servers that the master controls are designated as nodes. (also called minions) and are the servers responsible for accepting and running the workloads using their local and external resources. At its base, we find two options:

• • Individual machines (physical or virtual) in a Kubernetes cluster using a shared network to communicate between each server.
  • As part of one of the orchestration services offered by cloud providers such as Google Cloud o Microsoft Azure.

5. Maestro. Within these nodes, at least one server functions as teacher. This server acts as a gateway exposing an API for users and clients, checking the status of other servers (nodes.), deciding how to divide and assign work and organizing communication among other components.

Now that we know what Kubernetes is, whose turn is it to train this monster? Is it for developers, administrators or both share the cake? All roads lead to "DevOps".

If you want more information about Kubernetes, you are in luck, here is a phenomenal course of the URJC (I attest, I was there) given by Micael Gallego, Patxi Gortázar and Fede Díaz:

On Github the support material for this URJC Kubernetes course.

Next steps: to get going right now, I recommend that you start with Minikube, which is a Kubernetes to deploy locally (it only has a master and a node, no cluster crazy things, but it comes in handy to get started with the topic). And for it!