En este articulo veremos la arquitectura del cluster Kubernetes, cuales son sus componentes, objetos y muchas cosas que necesitamos conocer antes de embarcarnos en el despliegue de aplicaciones sobre este mismo. Entonces para ello vamos primer plano de nuestro cluster.
Descubriendo los laberintos de Kubernetes
Aun no tengo los recursos para hacer imágenes divertidas, así que he dibujado la arquitectura. No es una gran obra de arte, pero vamos que está muy cerca :-).
El cluster Kubernetes consiste de dos componentes principales, estos son el Master o Control Plane y también tenemos los Nodos o Workers que en la imagen vemos uno, pero podemos tener muchos más.
Dentro del Control Plane – Master, tenemos cuatro componentes fundamentales, estos son: Etcd, API Server, Controller Manager y Scheduler.
Para el caso de los Nodos – Workers, tenemos Kubelet y Container Runtime. Para nuestro ejemplo de instalación que hicimos previamente, utilizamos Docker en este caso.
Ahora para entender y comprender de mejor manera cada uno de estos componentes, vamos a ir en detalle por cada uno de ellos. Comenzamos por el Master.
Conociendo al Maestro de los nodos del clúster Kubernetes
Como bien saben, hay mucha mucha información acerca de Kubernetes, por lo tanto me he apoyado en muchas de esas definiciones para explicar qué hace cada uno de los componentes, también de cursos y de experiencia utilizando Kubernetes. No es nada del otro mundo, las definiciones ya estaban y no hay mucho que descubrir en ellas, pero sí debemos tener claro cuál es su función y cuál es su razón de existir y para eso comenzamos revelando aquellos laberintos del maravilloso Kubernetes.
API Server: Es el componente central para todos los demás componentes, se encargará de validar el objeto antes de guardar la información en etcd. El API Server está diseñado para escalar horizontalmente, es decir, escala mediante la implementación de más instancias. Puede ejecutar varias instancias del API Server y equilibrar el tráfico entre esas instancias. Para acceder al API Server podemos utilizar Kubectl mediante línea de comandos o alguna herramienta gráfica de tipo cliente para ejecutar API´s REST como lo es Postman.
Controller Manager: El Controller Manager es un proceso que integra los controladores que se incluyen con Kubernetes. Básicamente, un controlador observa el estado del clúster a través de la función de observación del API Server y cuando recibe una notificación, realiza los cambios necesarios para intentar mover el estado actual hacia el estado deseado.
Además, Controller Manager realiza las funciones de ciclo de vida tales como la creación de namespaces (espacios de nombre) y el ciclo de vida, recolección de basura de eventos, basura de pods finalizados, basura, basura y más basura.
Scheduler: El trabajo del Scheduler es asignar la creación de los pods pero indicando el nodo en dónde se realizará esto. Se registra con Api Server para cualquier objeto o recurso del cluster que esté recién creado.
El Scheduler determina en qué nodo deben crearse los pods mediante un algoritmo. Comprueba si el Worker tiene la capacidad o no. Después de determinar el nodo, el programador simplemente actualizará la especificación del recurso y lo enviará al servidor API. El servidor Api actualiza la especificación de recursos y se almacena en etcd. El servidor Api notifica al kubelet del nodo trabajador seleccionado por el Scheduler.
Etcd: Es una base de datos que almacena el estado del clúster y los metadatos, vale decir, la creación de cualquier objeto (pods, implementaciones, replicación). Etcd es un almacén de clave-valor distribuido que proporciona una forma confiable de almacenar datos en un grupo de máquinas. Como se demuestra en el diagrama, el API Server es el único que puede comunicarse directamente con etcd.
Los nodos trabajadores del clúster Kubernetes
Kubelet: Kubelet registra el nodo que se está ejecutando con el API Server. Kubelet es un servicio y es responsable de recibir información desde el Master y enviar información hacia el Master, supervisa el API Server para los pods que están programados en el nodo y, luego, iniciará los contenedores del pod indicando el tiempo de ejecución.
Kubelet monitorea el estado de los contenedores en ejecución e informa al API Server sobre el estado, los eventos y el consumo de recursos. Kubelet también realizará controles de estado del contenedor y este mismo se reiniciará si es necesario.
Kube-proxy: En términos muy muy simples, es el encargado de la red para que se comuniquen los contenedores en los Pods. Esto refleja los servicios definidos en la API de Kubernetes en cada nodo y puede realizar un reenvío de secuencias TCP, UDP y SCTP simple o un reenvío de TCP, UDP y SCTP por turnos a través de un conjunto de backends.
Container Runtime (Docker): es un software que implementa y administra contenedores.
Conclusion
Con esta definición de componentes tenemos algo más claro sobre el funcionamiento que tienen estos mismos dentro del clúster Kubernetes. No es nada de fácil entrar en los detalles, pero en los siguientes artículos, vamos a ir paso a paso para que se entienda cada una de las configuraciones sobre nuestro clúster y así vamos soltando la mano para perder el miedo al enorme Kubernetes. 😉
Nos vemos en el siguiente articulo, dejen sus comentarios para mejorar. Un abrazo.
