Kubernetes: los nodos - Tutorial de Kubernetes

Kubernetes está orientado a funcionar como un clúster. Por lo tanto, uno de sus conceptos principales es el de los nodos que lo conforman, ya sea para ejecutar aplicaciones o para controlarlas. En este caso vamos a hablar de los nodos en los que se ejecutan las aplicaciones, que son los que forman parte del plano de datos y concretamente de sus componentes de gestión. El primero del que podemos hablar es de kubelet. Kubelet es un componente que tiene un agente por cada uno de los nodos del clúster y que se encarga de vigilar y arrancar los POD, es decir, cuando recibe una petición arranca los POD con sus determinadas especificaciones que son necesarias para su funcionamiento y mientras está ejecutando está vigilando todos los POD que tenemos en nuestros nodos para ver que siguen ejecutándose de manera correcta y cumplen la especificación. Y esta especificación la recibe de la API de Kubernetes. Nosotros o un sistema de gestión lanza, despliega en la API de Kubernetes una definición de un objeto que queremos lanzar, puede ser un servicio, una aplicación o lo que sea, y entonces la API se encarga de comunicarse con el kubelet con la especificación de lo que hay que ejecutar y dónde hay que ejecutarlo. Muy relacionado con el kubelet tenemos el CRI o el "runtime". El CRI es el que está encargado de ejecutar de verdad los contenedores. Digamos que es el software que se gestiona en última instancia de ejecutar un contenedor, ponerle los permisos adecuados, que corran el kernel de manera adecuada, etc. Es también el que se descarga las imágenes de Docker o las imágenes OCI, según lo que estemos instalando a nuestro clúster, desde los registros de Docker o los registros OCI y utiliza el protocolo CRI para comunicarse con el kubelet, que es un estándar que pusieron dentro de Kubernetes para, digamos, tener un intermediario entre el kubelet y el sistema de contenedores para poder insertar diferentes "runtimes" o diferentes maneras de gestionar contenedores que no son de Docker. Después tenemos el kube-proxy, que es una especie de balanceador de carga interno que tenemos dentro de Kubernetes que mantiene en marcha todas las reglas de red del sistema. Utiliza para ello el filtrado y el sistema de gestión de redes y paquetes del sistema operativo. Y con ello lo que hace es funcionar a modo de balanceador de carga entre los diferentes nodos para repartir el tráfico que recibimos de fuera y para gestionar el tráfico que tenemos interno entre los servicios. Después tenemos los diferentes objetos que podemos ejecutar en el clúster. Normalmente, son objetos que lanzaremos nosotros. Desde el más básico, que es un POD, que es la mínima expresión de despliegue que podemos hacer de un contenedor dentro de Kubernetes, hasta otros más complejos como son los servicios, que son una especie de balanceador internos de red entre nuestros diferentes POD. Los "deployments", que es una especie de objeto que hay por encima de los POD que nos sirve para gestionar lanzamiento de POD con diferentes reglas. Los ConfigMap, que son diferentes valores de configuración que podemos guardar en un objeto para que los consulten las aplicaciones o los servicios que tenemos ejecutando dentro de Kubernetes. U otros objetos, como los secretos, que son parecidos a los ConfigMap pero en este caso para guardar secretos. Todos estos objetos pueden ser ya bien los que vienen por defecto dentro de la API de Kubernetes o extendiendo la API de Kubernetes con diferentes opciones o sistemas personalizados para lanzar nuestras aplicaciones y servicios dentro del clúster.