En artículos anteriores hemos visto en qué consiste Docker, cuáles son sus conceptos principales y cómo ponerlo en marcha.
Sin embargo, el hecho de tener que hacer todo por comandos con Docker puede resultar tedioso. Por una parte nos sigue faltando seguridad: el hecho de si se me cae un contenedor se me levante automáticamente, o se balanceen dependiendo de los recursos que tengo disponibles en el cluster…
Bien, pues para eso están los orquestadores: para automatizar despliegues, escalar, controlar nuestras aplicaciones y no gestionar nuestro pool de forma manual.
En este campo podemos distinguir varios (Docker Swarm, Kubernetes…), pero el más famoso es Kubernetes, ya que tiene una comunidad muy extendida.
Kuriosidad
Como dato curioso, Kubernetes nace en 2014 de un proyecto de Google llamado Borg. Originalmente se llamaba “Proyecto Siete” y es una clara referencia a un personaje de Star Trek Voyager, Seven of Nine.
Después ya se le cambió el nombre basándose en la palabra Κυβερνήτης del griego, que significa timonel o piloto, por ser el que “va a llevar las riendas” de nuestros contenedores.
Y si nos fijamos en el logo de Kubernetes (o K8s), vemos que es un timón de 7 puntas.
Características y funcionalidades
Hemos dicho que Kubernetes va a complementar a Docker cuando queremos realizar despliegues y orquestación a gran escala, clusterizando recursos y trabajando con multiples servidores.
¿Qué me va a ofrecer?
Si fallan contenedores puede reiniciarlos, pararlos o reemplazarlos automáticamente. O si se me cae el servidor, que sea capaz de mover sus contenedores a otra parte
Parte de la orquestación es decidir en qué nodo hay que ejecutarlos según sus características o restricciones
Según el uso de CPU, me va a permitir un escalado manual o automático de las aplicaciones de forma vertical y muy fácil
K8s asigna IP y nombre DNS a un conjunto de contenedores (pod) y permite el balanceo de las aplicaciones entre ellos
Voy a poder programar los despliegues, diciéndole cuántas réplicas de cada uno quiero, y se va a poder volver a un estado anterior haciendo un rollback automático si algo ha ido mal
Las contraseñas y otros datos sensibles son ocultados de forma segura en forma de “secretos” en nuestro clúster y vamos a poder pasárselos a los pod en el momento de creación
Los contenedores, por defecto, son efímeros. La información guardada en ellos no es persistente, pero es evidente que necesitamos que nuestras aplicaciones tengan la posibilidad de que su información no se pierda. La solución es añadir volúmenes (almacenamiento persistente) a los pods para que lo puedan utilizar los contenedores
Arquitectura y componentes
Por una parte tenemos los nodos en Kubernetes: son las máquinas que componen el clúster Kubernetes. Estas máquinas pueden ser físicas o virtuales, y estar desplegadas on-premise o en la nube. A su vez los nodos pueden ser nodos master o nodos worker, que como kuriosidad, en la documentación de las primeras versiones de Kubernetes se denominaban Minions.
Es la capa de control de K8s, la que va a gestionar el estado declarativo, va a chequear la salud de los pods, regenerar los contenedores que fallan y va a hacer el reparto de trabajo entre los nodos worker (los verdes)
Puede haber un único nodo master o varios si queremos tener redundancia y asegurar la HA. El nº de máster tiene que ser siempre impar para que sea posible establecer quórum.
En la máquina del master no se ejecutan contenedores de producción.
En la capa del master tenemos:
• API Server: Es el componente que expone la API de K8s hacia el público y se utiliza con la CLI de Kubernetes (kubectl). Es el punto de entrada para todos los comandos REST utilizados para controlar el cluster. Cada vez que se hace una petición, por CLI o por interfaz gráfica, p.ej: crear un pod, es el que procesa, las valida y las ejecuta.
•Parte de orquestación: Scheduler. Es el que va a ver la petición de crear contenedores y decide en qué nodo worker hay que ejecutarlos y le envía la información al nodo. Tiene en cuenta los recursos disponibles en cada nodo worker, y los recursos necesarios para que se ejecute un servicio.
• Controller Manager. Es el componente que ejecuta los controladores. Un controlador usa el API server para observar el estado del clúster y realiza los cambios en el estado actual para cambiarlo al estado deseado. p.ej: Replication controller es el controlador de replicación, que se ocupa de mantener el nº de pods que hemos definido en su despliegue. Nosotros solo definimos el nº de réplicas en el manifest, o archivo de despliegue de los pods, y es responsabilidad del controlador de replicación volver a crear un pod caído o eliminar uno que se haya programado de más.
• Etcd es la base de datos distribuida de K8s. Los datos pueden ser son los trabajos que se programan, crean y despliegan, estado y detalles de los pods, los namespaces o la información de replicación.
El que curra. Son los que ejecutan nuestras aplicaciones dentro de pods. Cada nodo worker puede ejecutar múltiples pods, que no son más que grupo de contenedores que se consideran como una unidad, comparten IP y recursos.
Entonces, de forma general, dentro de cada worker tenemos:
•Los pods. Se puede decir que es la forma de agrupar contenedores dentro de Kubernetes. El motor de creación y ejecución de los contenedores va a ser Docker, en la mayoría de los casos.
•El kubelet, que es un agente que hay dentro de cada nodo worker y es el que se utiliza para que el master se pueda comunicar con ellos. Obtiene la configuración que le pasamos de los pods del API server y garantiza que estén corriendo y funcionando correctamente. También se comunica con la base de datos etcd para obtener información de los servicios y registrar los detalles de los nuevos servicios creados.
•El kube-proxy actúa como proxy de red y balanceador de carga enrutando el tráfico hacia el contenedor correcto en función de la dirección IP y el número de puerto indicados en cada petición.