Conozcamos en detalle la arquitectura de Kubernetes.
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/es/kubernetes-introduction/
https://geekflare.com/es/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 programador programa el trabajo en función de los pods y los servicios.
Gestor de controladores
El gestor de control gestiona los bucles de control que regulan el estado del clúster Kubernetes. Ahora bien, cada uno de estos bucles de control conoce el estado deseado del objeto que gestiona y, a continuación, consultan 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 Raft.
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 worker, 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.
Exploremos los componentes de los nodos trabajadores.
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 CRI 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 luego 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. Las habilidades de Kubernetes son siempre de la demanda, y si usted está buscando para aprender a construir la carrera, a continuación, echa un vistazo a este curso Udemy.