Hola a todos!
En esta ocasión vamos a contar básicamente los componentes clave de Kubernetes explicados de manera simplificada para que los pueda entender cualquiera aunque no tenga un background potente en informática.
NOTA: Se añades esquema.
Sí, hoy nos metemos a tocar, aunque sea de soslayo a ese gigante de la orquestación de contenedores que se ha hecho tan famoso y que hoy en día aparece en todas las presentaciones sobre microservicios, DevOps, CI/CD y todas esas cosas que nos parecen tan modernas a los old-school como yo.
Vamos a intentar aprender cómo funciona todo esto por dentro, aprendiendo en este momento cuáles son los componentes principales de Kubernetes y cómo se relacionan entre sí, pero con un enfoque como suelo hacerlo yo, de andar por casa, sin tecnicismos innecesarios ni hablar de arquitecturas enrevesadas que podrían confundir a los menos doctos (tranquilos, yo soy el menos docto de todos), hablaremos de lo justo y necesario para que nos suene un poco, que lo entendamos y podamos empezar a hablar de todo esto.
¿Qué es Kubernetes?
Kubernetes es un sistema de orquestación de contenedores (tipo Docker) que nos ayuda a desplegar, administrar, escalar las aplicaciones empaquetadas en contenedores de forma automática, pero no es que lo haga solamente de manera automática, sino que además es muy muy muy fiable y por supuesto repetible porque sino, sería terriblemente malo como automatizador jejejeje
Este servicio se ha convertido en un pilar clave para cualquier arquitectura moderna que se precie basada en microservicios o en entornos híbridos.
El problema que tiene, es que no es el servicio más intuitivo, sino que a veces necesitas bastante tiempo para entenderlo, pero no os preocupéis, para eso estamos nosotros aquí, para ayudarte.
¿Cuáles son los componentes esenciales de Kubernetes?
Kubernetes se compone de varios elementos que interactuan entre sí de manera distribuida, como una especie de orquesta.
Los componentes básicos son los siguientes:
Nodo/s:
Los nodos, o “node/s”, según el idioma, son las máquinas que ejecutan los contenedores, estas pueden ser físicas o virtuales. Cada nodo contiene un agente que se llama kubelet, un motor de contenedores, que puede ser tipo Docker o Containerd, y un proxy para facilitar las conexiones a la red.
Nodos se pueden tener uno o más, pueden ser diez, o cien, mil, … según el tamaño de tu clúster.
Pod:
El Pod es la unidad más pequeña que se puede desplegar en Kubernetes, es como una especie de caja que puede contener uno o más contenedores que trabajarán juntos. Los contenedores dentro de un pod comparten la dirección IP y otros datos de red, el almacenamiento si este se configura en el clúster, y un ciclo de vida. Con ciclo de vida nos referimos a que se despliegan y destruyen juntos.
NOTA: Es importante saber que en Kubernetes no se gestionan contenedores individuales, sino que se despliegan, gestionan y destruyen Pods.
Control plane:
El control panel, es como el cerebro de todo esto, es un conjunto de componentes que deciden qué pasa, cuándo y dónde en un clúster de Kubernetes. Si volvemos a referirnos a la orquesta de antes, este sería el director de dicha orquesta. El Cotrol plane incluye el API Server, el Scheduler, el Controller Manager y el etcd.
- El API Server es por así decirlo el puente de acceso al castillo o la puerta de entrada. Todo pasa por aquí, tanto a través de la Command Line Interface de Kubernete (kubectl), como a través de una app desplegada o de una herramienta externa. Todos ellos siempre se deberán comunicar con el API server.
- El Scheduler decide hacia que nodo se dirigirá y ejecutará cada Pod, teniendo en cuenta disponibilidad, los recursos disponibles y las reglas que se hayan definido.
- El Controller Manager se asegura de que el estado del sistema sea el deseado y si algo se para o se cae, lo relanzará para que siga activo. Si algo desaparece, lo crea de nuevo, el tema es que todo siga activo.
- El etcd es la base de datos (DDBB) distribuida en la que se guarda todo, la configuración, el estado del clúster, las definiciones, etc…
Service:
Un Service es lo que mantiene las aplicaciones accesibles y estables dentro de un clúster de Kubernetes. Los Pods pueden aparecer y desaparecer a consecuencia de reinicios, por escalado de recursos, etc. y el Service será, por así decirlo un punto fijo para acceder a ellos, es como una especie de punto de acceso VIP en los clústeres de red, o sea como un nombre DNS o IP virtual que siempre está ahí, redirigiendo al Pod que le toque a cada momento.
Ingress:
Nos permite exponer nuestras aplicaciones al exterior, con una especie de web pública que gestiona el tráfico HTTP/HTTPS desde fuera del clúster hacia dentro, enrutando a los servicios correctos. Con las reglas de Ingress se pueden configurar reglas como
“Si llega una petición a la API, mándala a X”.
Namespace:
Un Namespace es una forma de dividir tu clúster en “espacios virtuales” que son realmente útiles en caso de tener varios equipos compartiendo el clúster, en caso de tener distintas fases de desarrollo como por ejemplo Desarrollo, Integración y Producción, o en caso de tener necesidad de separar recursos de manera lógica. Todo sigue dentro del mismo clúster físico, pero cada grupo es como si tuviera su clúster propio.
Persistent Volume:
Los contenedores son efímeros, se destruyen y se pierden los datos, pero no siempre se quiere eso. Para almacenar datos que sobrevivan reinicios o destrucción de Pods, se usarán “Persistent Volumes”, que son recursos de almacenamiento conectados al clúster. Esta es clave si tenemos bases de datos, archivos de usuario o logs que se quieren conservar.
¿Cómo encajan todas estas piezas?
Cuando pensamos en Kubernetes, podemos hacer el simil de un aeropuerto, en el que tendremos los Pods que son los aviones (contenedores), los Nodos que son las pistas donde aterrizan, el Control plane es la torre de control que organiza el tráfico, los Services son las puertas de embarque, el Ingress es la entrada principal con filtros y rutas, los Namespaces son las diferentes terminales, y los Persistent Volumes son el equipaje que nunca quieres perder.
¿Sirven los Kubernetes para todo?
Pues la verdad es que no, aunque Kubernetes es una herramienta potentísima, también es compleja, requiere una curva de aprendizaje muy dura, una configuración fina y mucha experiencia. Para casos simples, herramientas como Docker Swarm o plataformas PaaS como Azure App Service pueden ser más rápidas y mucho más cómodas. Pero si estás gestionando un sistema grande, distribuido, o con múltiples servicios que deben escalar y sobrevivir a fallos… Kubernetes puede ser tu mejor aliado.
¿Por dónde empiezo?
Si esto te ha picado la curiosidad, y quieres comenzar a trabajar o a probar Kubernetes, te recomiendo que consultes los siguientes recursos que aquí te dejamos:
Conocer los componentes básicos de Kubernetes te da una ventaja enorme a la hora de entender cómo funciona y qué está pasando dentro de tu app cuando algo no va bien. Este es el primer paso para dominar este entorno que, aunque sea un poco complejo, te permitirá construir sistemas realmente robustos, escalables y listos para soportarlo todo.
La próxima vez que alguien hable de Pods, Nodes o etcd… ya no te sonará a chino,
Espero que os haya gustado.
Un saludo
