Todos esperamos que las aplicaciones estén siempre disponibles, a todas horas, todos los días del año. ¿Cómo podemos hacer esto posible? Pasen y vean, les presento a Kubernetes. Hasta sus competidores se han rendido a este fenómeno, ¿lo harás tú?

Las técnicas de virtualización de servidores han evolucionado hacia la utilización de los contenedores de forma cada vez más extendida. Con los contenedores se acabó aquello de “en mi máquina funcionaba”, “¿qué me tengo que instalar?”, “enséñame tu configuración”, etc. De forma muy resumida, esto es porque cada contenedor es una copia exacta de una imagen y puede ejecutarse en cualquier lugar, sin suponer un cambio a la hora de programar. Por tanto, la filosofía de trabajo con contenedores ya no es “start-stop”, sino “create-destroy”.

Los contenedores nos solucionan numerosos problemas, pero no todos: ¿y si nuestro servicio no responde?, ¿y si la máquina se cae?, ¿y si la CPU está echando humo? Pues bien, Kubernetes viene a aportar soluciones para estos problemas y, al igual que los contenedores, pueden galopar en cualquier lugar.

Pero ¿qué es Kubernetes? Siendo escueto, es un orquestador de contenedores. Desde su nivel básico, Kubernetes es una plataforma opensource para ejecutar y coordinar aplicaciones en contenedores. Kubernetes automatiza la gestión y la implantación de estas aplicaciones en contenedores.

Su virtud principal es hacer independientes los componentes de nuestra aplicación mediante sus capas de abstracción, así al desacoplarlos, el mantenimiento es más simple y la capacidad de autorrecuperación frente a problemas es notable. Un cambio en cualquier módulo no afectará a los demás y pueden ser desplegados y gestionados dinámicamente.

Automatiza los contenedores con Kubernetes

Suena bien. Imaginemos que tenemos un sistema con un Nexus, como gestor de artefactos; un Jenkins, como servidor de integración continua; accesible todo a través de un servidor web Apache y cada uno en su correspondiente contenedor. ¡El Jenkins se ha caído!, Kubernetes levanta uno nuevo; ¡El tráfico en Apache aumenta y necesita más recursos!, Kubernetes te replica un Apache; ¡Necesitamos actualizar nuestra versión de Nexus!, Kubernetes te cambia el contenedor con la versión antigua por la nueva. Y todo ello de forma desatendida ¡Oooh!

Para entender mejor esta maravilla llamada Kubernetes, hay que tener una idea clara de cómo están organizadas sus capas de abstracción.

Arquitectura Kubernetes

Comenzamos desde abajo:

1. Pod. Kubernetes es un orquestador de contenedores cuya unidad mínima de ejecución son los pods. Un pod representa un conjunto de contenedores ejecutándose en un mismo host, por lo que comparten recursos y dirección IP. El ciclo de vida de un pod es efímero, y la manera de controlarlos es a través de un deployment.
2. Deployment. Esta capa controla el estado de los pods, ajustando su estado actual y el deseado (o declarado) al ritmo de control establecido. Así, en caso de fallo de un contenedor, el deployment es el responsable de arrancarlo de nuevo. Por lo tanto, tener varias réplicas del mismo pod te permite una tolerancia a fallos. Cada pod tiene su propia dirección IP, pero asegurar que un pod siempre tendrá una dirección única no es posible. Por este motivo existen los servicios.
3. Servicios. Ofrecen un nivel más de abstracción en la comunicación entre pods. Si un deployment tiene asociado un servicio, cuando se accede al servicio se hace balanceo de carga entre todas las réplicas. Esto favorece la escalabilidad dentro de cada nodo, ya que puede crecer o decrecer según la necesidad de recursos.
4. Nodos. Los servidores que el maestro controla se designan como nodos (también llamados minions) y son los servidores responsables de aceptar y ejecutar las cargas de trabajo utilizando sus recursos locales y externos. En su base, nos encontramos dos opciones:

• • Máquinas individuales (físicas o virtuales) en un clúster Kubernetes utilizando una red compartida para comunicarse entre cada servidor.
  • Como parte de uno de los servicios de orquestación ofrecidos por los proveedores de nube como Google Cloud o Microsoft Azure.

5. Maestro. Dentro de estos nodos, como mínimo un servidor funciona como maestro. Este servidor actúa como una puerta de enlace exponiendo una API para usuarios y clientes, comprobando el estado de otros servidores (nodos), decidiendo cómo dividir y asignar el trabajo y organizando la comunicación entre otros componentes.

Ahora que sabemos qué es Kubernetes, ¿a quién le toca amaestrar a este monstruo?, ¿es para desarrolladores, administradores o ambos se reparten el pastel? Todos los caminos llevan a “DevOps”.

Si queréis ampliar la información sobre Kubernetes, estáis de suerte, aquí os dejamos un fenomenal curso de la URJC (doy fe, estuve allí) impartido por Micael Gallego, Patxi Gortázar y Fede Díaz:

En Github está disponible el material de apoyo de este curso de Kubernetes de la URJC.

Siguientes pasos: para ponerte en marcha ya mismo, te recomiendo que empieces con Minikube, que es un Kubernetes para desplegar en local (solo tiene un master y un nodo, sin locuras de clúster, pero viene bien para poder iniciarnos con el tema). ¡Y a por ello!