Arquitectura de Kubernetes: Worker Node

En la entrada anterior, vimos en líneas generales la arquitectura global de kubernetes, entrando más en detalle en el Master Node. En esta entrada sobre la arquitectura de kubernetes, veremos en mayor profunidad el worker node.

Elementos de una Arquitectura de Kubernetes

De una manera resumida, podríamos decir que kubernetes cuenta con los siguientes componentes:

• Uno o varios master nodes.
• Uno o varios worker nodes.
• Almacen distribuido clave-valor, como puede ser etcd.

• 

Worker Node

El worker node, nos proporcionara un entrono de ejecución para las aplicaciones. Estas aplicaciones que se encuentran contenerizadas en Pods y son controladas por los agentes del Control Plan que se ejecutan en el Master Node. Un pod es la unidad mínima en kubernetes.

Componentes Worker Node

Un Worker Node tiene los siguientes componentes:

• Contenedor en tiempo de ejecución (Container runtime)
• kubelet
• kube-proxy
• Complementos parar DNS, Dashboard, cluster-level monitoring y logging.

Container runtime

Como hemos mencionado en la primera entrada, sobre la introducción a Kubernetes, se ha definido como un orquestador de contenedores; pero el problema es que por si mismo no tiene la capacidad para poder gestionar y controlar estos contenedores; es por eso que requiere de un container runtime, para que estos contenedores puedan ser planificados. Aunque es bastante habitual trabajar con Docker, kuberntes soporta más tipos de contenedores, como CRI-O , rkt, rktlet o containerd.

kubelet

Kubelet es un agente que se encuentra corriendo en cada nodo y se comunica con los componentes del Control Plane del nodo master. Recive las definiciones del Pod del API Server e interacciona con el container runtime para ejecutar contenedores asociados al Pod. También monitoriza la salud de los contenedores que se ejecutan en los Pods.

El kubelete se conecta al container runtime usando el Container Runtime Interface (CRI), el cual consiste en una serie de librerías, API gRPC, y protocol buffers o protobuf.

• 

Según podemos ver en el dibujo, kubelet va a actuar como un cliente gRPC que através de protobuf se conectará con la interfaz CRI, que actúa como servidor gRPC. CRI se encargará de implementar dos servicios, el primero será ImageService, que será el responsable de todas las imagenes, y el segundo RuntimeService que será responsable de todas las operaciones relacionadas con el Pod y los contenedores.

Gracias al desarrollo de CRI en kubernetes se permite la utilización de cualquier container runtime que pueda implementar CRI para gestionar los Pods, contenedores e imágenes.

Kube-Proxy

El Kube-proxy es el agente de red que se ejecuta en cada nodo responsable de las actualizaciones dinámicas y el mantenimiento de todas las reglas de red en el nodo. Es el encargado de reenvíar las solicitudes de conexión a los Pods.

Complementos

Los complementos son características y funcionalidades del clúster que no están todavía disponibles en kubernetes, pero pueden ser incorporadas a través de terceros, como por ejemplo:

• DNS: Es un servidor DNS requerido para asignar registros DNS a objeto y recursos de kubernetes.
• Dashboard: Es una interfaz de usuario web de uso general para la gestión de clústeres.
• Monitoring: Recopila métricas a nivel de clúster y las guarda en un almacén de datos centra.
• Logging: Recopila logs y los salva en un almacén central de log para su análisis.

Conclusión

En esta entrada hemos visto un poco más sobre la arquitectura de kubernetes, viendo el Worker Node. En la próxima entrada continuaremos con más componentes de arquitectura de Kubernetes, los tipos de redes en Kubernetes.