Comprender la arquitectura de Kubernetes

Aprendamos la arquitectura de Kubernetes en detalle

Asumo que tiene un conocimiento básico de Kubernetes. Si no es así, consulte los siguientes artículos de introducción e instalación

https://geekflare.com/kubernetes-introduction/

https://geekflare.com/install-kubernetes-on-ubuntu/

Kubernetes sigue una arquitectura maestro-esclavo. La arquitectura Kubernetes tiene un nodo maestro y nodos trabajadores. Hay cuatro componentes de un nodo maestro

• Servidor API Kube
• controlador
• programador
• etcd

Y, el nodo trabajador tiene tres componentes

• kubelet
• kube-proxy
• tiempo de ejecución del contenedor

Este es el aspecto de una arquitectura Kubernetes

Permítame hablarle en detalle de los componentes del nodo maestro y de los nodos trabajadores

Nodo maestro

El nodo maestro gestiona el clúster Kubernetes y es el punto de entrada para todas las tareas administrativas. Puede hablar con el nodo maestro a través de la CLI, la GUI o la API. Para conseguir tolerancia a fallos, puede haber más de un nodo maestro en el clúster. Cuando tenemos más de un nodo maestro, habría un modo de alta disponibilidad, y con un líder realizando todas las operaciones. Todos los demás nodos maestros serían los seguidores de ese nodo maestro líder

Además, para gestionar el estado del clúster, Kubernetes utiliza etcd. Todos los nodos maestros se conectan a etcd, que es un almacén distribuido de claves y valores

Permítame explicarle todos estos componentes uno por uno

Servidor API

El Servidor API realiza todas las tareas administrativas en el nodo maestro. Un usuario envía las órdenes de reposo al servidor API, que valida las solicitudes, las procesa y las ejecuta. etcd guarda el estado resultante del clúster como un almacén distribuido de valores clave

Programador

A continuación, tenemos un planificador. Como su nombre indica, el planificador programa el trabajo a diferentes nodos trabajadores. Dispone de la información sobre el uso de recursos de cada nodo trabajador. El programador también tiene en cuenta los requisitos de calidad del servicio, la localidad de los datos y muchos otros parámetros similares. A continuación, el planificador programa el trabajo en función de los pods y los servicios

Gestor de controladores

Los bucles de control que regulan el estado del clúster Kubernetes son gestionados por el gestor de control. Ahora bien, cada uno de estos bucles de control conoce el estado deseado del objeto que gestiona y consulta su estado actual a través de los servidores API

En un bucle de control, si el estado deseado no coincide con el estado actual del objeto, entonces el bucle de control toma medidas correctivas para que el estado actual coincida con el estado deseado. Así, el gestor de control se asegura de que su estado actual sea el mismo que el estado deseado

etcd

El etcd es un almacén distribuido clave-valor que se utiliza para almacenar el estado del clúster. Por lo tanto, debe formar parte del maestro Kubernetes o también puede configurarlo externamente. etcd está escrito en goLang y se basa en el algoritmo de consenso Balsa

La balsa permite que la colección de máquinas funcione como un grupo coherente que puede sobrevivir a los fallos de algunos de sus miembros. Incluso si algunos de los miembros dejan de funcionar, este algoritmo puede seguir funcionando en cualquier momento. Uno de los nodos del grupo será el maestro, y el resto serán los seguidores

Sólo puede haber un maestro, y todos los demás tienen que seguir a ese maestro. Además de almacenar el estado del cluster, etcd también se utiliza para almacenar los detalles de configuración, como las subredes y los mapas de configuración

Nodo trabajador

Un nodo trabajador es un servidor virtual o físico que ejecuta las aplicaciones y está controlado por el nodo maestro. Los pods se programan en los nodos trabajador, que disponen de las herramientas necesarias para ejecutarlos y conectarlos. Los pods no son más que una colección de contenedores

Y para acceder a las aplicaciones desde el mundo exterior, hay que conectarse a los nodos worker y no a los nodos maestros

Exploraremos los componentes de los nodos worker

Tiempo de ejecución del contenedor

El tiempo de ejecución del contenedor se utiliza básicamente para ejecutar y gestionar un ciclo de vida continuo en el nodo trabajador. Algunos ejemplos de tiempos de ejecución de contenedores que puedo darle son los contenedores rkt, lxc, etc. A menudo se observa que docker también se denomina tiempo de ejecución del contenedor, pero para ser precisos, permítanme decirles que docker es una plataforma que utiliza contenedores como tiempo de ejecución del contenedor

Kubelet

Kubelet es básicamente un agente que se ejecuta en cada nodo trabajador y se comunica con el nodo maestro. Por lo tanto, si usted tiene diez nodos trabajadores, entonces kubelet se ejecuta en cada nodo trabajador. Recibe la definición del pod por diversos medios y ejecuta los contenedores asociados a ese puerto. También se asegura de que los contenedores que forman parte de los pods estén siempre sanos

El kubelet se conecta al tiempo de ejecución del contenedor utilizando el marco gRPC. El kubelet se conecta a la interfaz del tiempo de ejecución del contenedor (CRI) para realizar operaciones con los contenedores y las imágenes. El servicio de imágenes se encarga de todas las operaciones relacionadas con las imágenes, mientras que el servicio en tiempo de ejecución se encarga de todas las operaciones relacionadas con los pods y los contenedores. Estos dos servicios tienen dos operaciones diferentes que realizar

Permítame decirle algo interesante, los tiempos de ejecución de los contenedores solían estar codificados en Kubernetes, pero con el desarrollo de IRC, Kubernetes puede ahora utilizar diferentes tiempos de ejecución de contenedores sin necesidad de recompilar. Así, cualquier tiempo de ejecución de contenedores que implemente IRC puede ser utilizado por Kubernetes para gestionar pods, contenedores e imágenes de contenedores. Docker shim y los contenedores CRI son dos ejemplos de CRI shim. Con docker shim, los contenedores se crean utilizando docker instalado en los nodos trabajadores y, a continuación, internamente docker utiliza un contenedor para crear y gestionar contenedores

Kube-proxy

Kube-proxy se ejecuta en cada nodo trabajador como proxy de red. Escucha al servidor API para cada creación o eliminación de punto de servicio. Para cada punto de servicio, kube-proxy establece las rutas para poder llegar a él

Conclusión

Espero que esto le ayude a comprender mejor la arquitectura de Kubernetes. Kubernetes habilidades están siempre en la demanda, y si usted está buscando para aprender a construir la carrera, a continuación, echa un vistazo a este curso Udemy.