Skip to main content

Arquitectura de Cluster

Kubernetes tiene como objetivo alojar tus aplicaciones en contenedores de forma automatizada, facilitando su despliegue en múltiples instancias y simplificando la comunicación entre los servicios de la aplicación. Utilizaremos un enfoque más simplificado que el propuesto en el curso.

Alt text

Control Plane (Maestro)​

Es el conjunto de nodos que contiene los componentes responsables de gobernar Kubernetes. Estos componentes mantienen toda la información necesaria para garantizar el buen funcionamiento del sistema y controlar los pods y nodos trabajadores.

ETCD​

Es la base de datos de Kubernetes. Toda la información del cluster está almacenada en ETCD mediante un conjunto de clave-valor.

Kube-Scheduler​

Se encarga de tomar decisiones sobre la asignación de cada pod en los nodos del cluster, teniendo en cuenta diversas políticas establecidas, como capacidad de los nodos, topología, políticas de restricción, tipo de hardware, entre otros. También considera factores como taints, affinities y otras configuraciones relevantes.

Kube-Controller-Manager​

Desempeña un papel fundamental en el monitoreo de la salud del cluster. Detecta eventuales fallos e intenta corregirlos automáticamente. Por ejemplo, si un nodo o pod deja de responder, el Kube-Controller-Manager interviene para garantizar que el número correcto de pods esté en ejecución, restaurando así el estado deseado del cluster. Este componente actúa como una especie de auditoría, verificando continuamente el estado del cluster para garantizar su conformidad e integridad.

Este componente está formado por otros dos componentes principales: Replication Controller y Node Controller.

Kube-APIServer​

En Kubernetes, todo funciona mediante APIs. El Kube-APIServer es el punto central de esta arquitectura, siendo responsable de la orquestación de las operaciones dentro del cluster Kubernetes. Interpreta las solicitudes enviadas por los componentes, comprendiendo lo que debe ejecutarse o no. La información se almacena en ETCD. Es mediante el Kube-APIServer que los usuarios interactúan y definen los manifiestos.

El comando kubectl se comunica exclusivamente con el Kube-APIServer. Aunque menos común, es posible invocar las APIs directamente con un comando POST, sin el uso de kubectl.

El Kube-APIServer desempeña diversas funciones vitales en el cluster:

  • Hace la autenticación del usuario
  • Valida la solicitud
  • Recupera los datos
  • Actualiza el ETCD (único que interactúa con ETCD)
  • Kube-Controller-Manager, Kube-Scheduler y Kubelet utilizan el Kube-APIServer para hacer actualizaciones en el cluster en sus respectivas áreas.

Al igual que todos los componentes de Kubernetes, el Kube-APIServer se distribuye en forma de binarios.

Nodos Trabajadores​

Son los nodos de Kubernetes que de hecho serán usados para ejecutar los pods.

Kubelet​

Es el agente de Kubernetes que se ejecuta dentro de los nodos para enviar y recibir los datos del Kube-APIServer. Es responsable de leer periódicamente el Kube-APIServer y ejecutar los comandos dentro de los nodos y enviar los informes de estado de los pods al Kube-APIServer.

Es el Kubelet quien tiene la función de hacer el pull de la imagen de los contenedores (usando el CRI) en el nodo y ejecutar los pods. Luego continúa monitoreando el pod y reportando al Kube-APIServer.

El Kubelet siempre se instala manualmente dentro de cada nodo trabajador y generalmente está presente solo en los nodos trabajadores y no en los maestros. El kubeadm no instala el Kubelet. Algunas configuraciones pueden pasarse al Kubelet.

Kube-proxy​

Es el agente de red que garantiza la comunicación entre los pods del cluster incluso estando en diferentes nodos.

Alt text

Alt text

Alt text

Contenedores​

Todas las máquinas que ejecutan pods, generalmente trabajadores, necesitan tener un Container Runtime Interface (CRI) instalado para ejecutar contenedores. No es necesario que sea Docker. De hecho, ni siquiera es muy recomendado instalar Docker para ser el CRI, ya que trae consigo muchas otras herramientas que interactúan con el CRI y no son necesarias en los nodos.

Para eso, podemos usar containerd, que implementa runc, que es el núcleo del CRI sin traer todas esas herramientas que Docker trae. Tanto Docker como containerd usan la especificación de declaración de contenedores que ya conocemos, por lo que cualquier imagen creada por Docker funciona en containerd. El containerd es un proyecto graduado de la CNCF.

Sin embargo, containerd trae consigo una CLI llamada ctr que es poco amigable y más usada para debug, ya que tiene recursos limitados. Con el fin de mejorar un poco la interacción con containerd fue creado el crictl que extiende los recursos del ctr, pero aún no es amigable para propósitos generales sino para debugging especialmente en los nodos trabajadores.

Para ejecutar las cosas de una forma más amigable, podemos usar nerdctl que es muy parecido al CLI de Docker, soporta la mayoría de las opciones que Docker soporta y tiene propósitos generales, inclusive usado para desarrollo de las imágenes.

Alt text