Comprender la arquitectura de Kubernetes

Aprendamos la arquitectura de Kubernetes en detalle.

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

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

Programador del controlador del servidor API de Kube, etc.

Y el nodo trabajador tiene tres componentes.

tiempo de ejecución del contenedor kubelet kube-proxy

Así es como se ve una arquitectura de Kubernetes:

arquitectura de kubernetes

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

Nodo maestro

El nodo maestro administra el cl√ļster de 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 lograr la tolerancia a fallas, 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 administrar el estado del cl√ļster, Kubernetes usa etcd. Todos los nodos maestros se conectan a etcd, que es un almac√©n de clave-valor distribuido.

nodo maestro de kubernetes

Déjame explicarte sobre todos estos componentes uno por uno.

Servidor API

API Server realiza todas las tareas administrativas en el nodo maestro. Un usuario env√≠a los comandos restantes al servidor API, que luego valida las solicitudes, luego las procesa y las ejecuta. etcd guarda el estado resultante del cl√ļster como un almac√©n de clave-valor distribuido.

programador

Después de eso, tenemos un planificador. Entonces, como sugiere el nombre, el programador programa el trabajo para diferentes nodos trabajadores. Tiene la información de uso de recursos para cada nodo trabajador. El programador también considera los requisitos de calidad del servicio, la ubicación de los datos y muchos otros parámetros similares. Luego, el programador programa el trabajo en términos de módulos y servicios.

Administrador del controlador

Control Manager gestiona los bucles de control sin terminaci√≥n que regulan el estado del cl√ļster de Kubernetes. Ahora, cada uno de estos lazos de control conoce el estado deseado del objeto que administra, y luego miran su estado actual a trav√©s de los servidores API.

En un lazo de control, si el estado deseado no cumple con el estado actual del objeto, entonces el lazo de control toma los pasos correctivos para que el estado actual sea el mismo que el estado deseado. Entonces, el administrador del controlador se asegura de que su estado actual sea el mismo que el estado deseado.

etc.

El etcd es un almac√©n de clave-valor distribuido que se utiliza para almacenar el estado del cl√ļster. Por lo tanto, tiene que ser parte del maestro de Kubernetes o tambi√©n puede configurarlo externamente. etcd est√° escrito en goLang y se basa en el algoritmo de consenso de Raft.

La balsa permite que la colecci√≥n de m√°quinas funcione como un grupo coherente que puede sobrevivir a las fallas de algunos de sus miembros. Incluso si algunos de los miembros no funcionan, este algoritmo a√ļn puede funcionar en cualquier momento. Uno de los nodos del grupo ser√° el maestro y el resto ser√°n los seguidores.

Solo puede haber un maestro, y todos los dem√°s maestros deben seguir a ese maestro. Adem√°s de almacenar el estado del cl√ļster, etcd tambi√©n se usa 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 trabajadores, que cuentan con 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, debe conectarse a los nodos trabajadores y no a los nodos maestros.

nodo trabajador de kubernetes

Exploremos los componentes del nodo trabajador.

Tiempo de ejecución del contenedor

El tiempo de ejecución del contenedor se usa básicamente para ejecutar y administrar un ciclo de vida continuo en el nodo trabajador. Algunos ejemplos de tiempos de ejecución de contenedores que les puedo dar son los contenedores rkt, lxc, etc. A menudo se observa que docker también se conoce como tiempo de ejecución de contenedores, pero para ser precisos, déjame decirte que docker es una plataforma que usa 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 principal. Entonces, si tiene diez nodos trabajadores, kubelet se ejecuta en cada nodo trabajador. Recibe la definición del pod por varios medios y ejecuta los contenedores asociados con ese puerto. También se asegura de que los recipientes que forman parte de las vainas estén siempre sanos.

El kubelet se conecta al tiempo de ejecución del contenedor mediante el marco gRPC. El kubelet se conecta a la interfaz de tiempo de ejecución del contenedor (CRI) para realizar operaciones de contenedores e imágenes. El servicio de imágenes es responsable de todas las operaciones relacionadas con la imagen, mientras que el servicio de tiempo de ejecución es responsable de todas las operaciones relacionadas con el pod y el contenedor. Estos dos servicios tienen dos operaciones diferentes para realizar.

Déjame decirte algo interesante, los tiempos de ejecución de contenedores solían estar codificados en Kubernetes, pero con el desarrollo de CRI, Kubernetes ahora puede usar diferentes tiempos de ejecución de contenedores sin necesidad de volver a compilar. Por lo tanto, Kubernetes puede usar cualquier entorno de ejecución de contenedores que implemente CRI para administrar pods, contenedores e imágenes de contenedores. Los contenedores Docker shim y CRI son dos ejemplos de CRI shim. Con docker shim, los contenedores se crean utilizando docker instalado en los nodos de trabajo y luego, internamente, docker usa un contenedor para crear y administrar contenedores.

Proxy Kube

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

Conclusión

Espero que esto te ayude a comprender mejor la arquitectura de Kubernetes. Las habilidades de Kubernetes siempre est√°n disponibles, y si est√° buscando aprender para desarrollar su carrera, consulte este curso de Udemy.