Kubernetes es una plataforma de organización de contenedores que automatiza la implementación y el escalado de cargas de trabajo en contenedores. Kubernetes se ha ganado la reputación de ser complejo y difícil de manejar. Así es como se combinan los componentes individuales para formar un grupo.
Definición del clúster
Una sola instalación de Kubernetes se denomina «clúster». Dentro del clúster, hay uno o más nodos disponibles para ejecutar sus contenedores. A Nodo es una representación de una máquina física que se ha unido al clúster.
Kubernetes también tiene un Plano de control superficie. Esto funciona independientemente de los nodos trabajadores. El plano de control es con lo que interactúas. Expone la API de Kubernetes y es responsable de administrar los nodos trabajadores. Por lo general, no manipula directamente los nodos y sus cargas de trabajo.
Instruir a Kubernetes para que cree una carga de trabajo comienza con una llamada a la API al plano de control. A continuación, el plano de control determina los nodos en los que se deben programar sus contenedores. No importa cuántos nodos tenga, solo habrá un plano de control dentro de su clúster.
Papel del plano de control
En términos más generales, el plano de control es responsable de la gestión global de su clúster. Cualquier operación que pueda afectar a múltiples nodos o la infraestructura del clúster será administrada por el plano de control.
El plano de control consta de varios componentes independientes. Juntos, son responsables de administrar la configuración del clúster, ejecutar y escalar cargas de trabajo y reaccionar a los eventos dentro del clúster (como un nodo que se queda sin memoria).
El núcleo del plano de control es kube-apiserver. Este componente proporciona la API HTTP de Kubernetes que consume a través de herramientas como Kubectl y Helm. La API es la forma en que interactúa con su clúster. También lo utilizan otros componentes del clúster, como los procesos de trabajo del nodo, para transmitir información al plano de control.
Los recursos de su clúster, como pods, servicios y trabajos, son administrados por «Controladores. » Los controladores controlan sus recursos para garantizar la salud y la preparación. También identifican los cambios que se han solicitado y luego toman medidas para migrar el estado actual al nuevo estado deseado.
Los controladores son administrados en conjunto por administrador-controlador-kube. Este componente del plano de control inicia y ejecuta los controladores individuales. Este proceso siempre estará en ejecución. Si alguna vez se detuviera, los cambios realizados a través del servidor de API no se identificarían y nunca se producirían cambios de estado.
Otro componente crítico del plano de control es programador de kube. El programador es responsable de asignar pods a nodos. La programación generalmente requiere la consideración de varios parámetros diferentes, como el uso actual de recursos de cada nodo y cualquier restricción que haya aplicado en su manifiesto.
El programador evaluará la idoneidad de cada Nodo y luego delegará el Pod para que se ejecute en el Nodo más apropiado. Si la disponibilidad del nodo cambia o se solicitan más réplicas de un pod, el programador tomará medidas para reprogramar la carga de trabajo en consecuencia.
El plano de control completo generalmente se ejecuta en un solo nodo dentro del clúster. Es técnicamente posible para abarcar el plano de control a través de múltiples nodos. Esto ayuda a maximizar su disponibilidad.
Por lo general, la pérdida del plano de control lo deja incapaz de administrar su clúster, ya que la API y las funciones de programación se desconectan. Sin embargo, los pods en los nodos de trabajo seguirán funcionando; periódicamente intentarán reconectarse al plano de control.
Comunicación entre nodos y el plano de control
Kubernetes mantiene un bidireccional canal de comunicación entre los nodos y el plano de control.
La comunicación es necesaria para que el plano de control pueda instruir a los nodos para que creen nuevos contenedores. En la dirección opuesta, los nodos deben enviar datos sobre su disponibilidad (como estadísticas de uso de recursos) al plano de control. Esto garantiza que Kubernetes pueda tomar decisiones informadas al programar contenedores.
Todos los nodos trabajadores ejecutan una instancia de kubelet. Esta es una utilidad de agente responsable de mantener la comunicación con el plano de control de Kubernetes. Kubelet también supervisa continuamente los contenedores que ejecuta Node. Notificará al plano de control si un contenedor cae en un estado insalubre.
Cuando un nodo necesita enviar datos al plano de control, Kubelet se conecta al servidor API del plano de control. Utiliza la misma interfaz HTTPS a la que te conectas a través de herramientas como kubectl. Kubelet está preconfigurado con credenciales que le permiten autenticarse en Kubernetes.
El tráfico desde el plano de control a los nodos se maneja nuevamente usando kubelet. Kubelet expone su propio punto final HTTPS al que puede acceder el plano de control. Este punto final acepta nuevos manifiestos de contenedores, que luego usa Kubelet para ajustar los contenedores en ejecución.
¿Qué más ejecutan los nodos?
Kubelet no es el único binario que debe ejecutar un nodo de Kubernetes. También encontrará una instancia de proxy de kube en cada nodo. Este es responsable de configurar el sistema de red del nodo para cumplir con los requisitos de las cargas de trabajo de su contenedor.
Kubernetes tiene el concepto de «servicios,» que exponen varios pods como una sola identidad de red. Es kube-proxy que convierte las definiciones de servicio en las reglas de red que brindan el acceso que solicitó.
kube-proxy configura la infraestructura de red del sistema operativo para exponer los servicios creados por kubelet. El reenvío de tráfico lo maneja la capa de filtrado de paquetes a nivel del sistema operativo o el propio kube-proxy.
Además de kubelet y kube-proxy, los nodos también necesitan tener un tiempo de ejecución de contenedor disponible. El tiempo de ejecución del contenedor es responsable de extraer imágenes y ejecutar realmente sus contenedores. Kubernetes admite cualquier tiempo de ejecución que implemente su Interfaz de tiempo de ejecución del contenedor especificación. Los ejemplos incluyen containerd y CRI-O.
Conclusión
Kubernetes implica mucha terminología. Dividir los grupos en sus partes constituyentes puede ayudarlo a apreciar cómo se interconectan los componentes individuales.
El plano de control se encuentra por encima de todos los nodos y es responsable de administrar las operaciones del clúster. Los nodos se ven mejor como iguales directamente debajo del plano de control. Existe una comunicación continua de ida y vuelta entre los nodos y el plano de control. Usted, como usuario, solo interactúa con el Plano de control a través del servidor API.
Por lo tanto, el plano de control es el centro de su clúster. Por lo general, no se relaciona directamente con los nodos. En su lugar, envía instrucciones al plano de control, que luego crea los horarios adecuados para cumplir con su solicitud. Las cargas de trabajo solo se programan en los nodos cuando el plano de control envía un manifiesto de contenedor a una de las instancias de kubelet disponibles.
Cuando un nodo recibe un nuevo manifiesto, utilizará el tiempo de ejecución de su contenedor para extraer la imagen adecuada e iniciar una nueva instancia de contenedor. kube-proxy luego modificará la configuración de la red para configurar los servicios y hacer que su carga de trabajo sea accesible. Kubelet transmite datos sobre el estado del nodo a Kubernetes, lo que le permite tomar medidas para reprogramar los pods si los recursos del nodo se ven limitados.
