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:
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.
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.
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.
Tabla de contenidos
