[28/05/2021] Kubernetes es la tecnología más destacada en los microservicios modernos. Está diseñada para simplificar y automatizar la administración de grupos de microservicios de aplicaciones en contenedores. Debajo de esta simple noción hay un mundo de complejidad. Este artículo le brinda una comprensión conceptual detallada de cómo funciona esta importante tecnología.
Una forma útil de pensar en Kubernetes es como un sistema operativo distribuido para contenedores. Proporciona las herramientas y los comandos necesarios para orquestar la interacción y el crecimiento de contenedores (más comúnmente contenedores Docker), y los contenedores de infraestructura en los que se ejecutan. Kubernetes, una herramienta general diseñada para funcionar en una amplia gama de escenarios, es un sistema muy flexible -y muy complejo.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Siga leyendo para comprender la arquitectura que hace funcionar a Kubernetes.
Nodos de trabajo y plano de control de Kubernetes
Existen dos aspectos de Kubernetes: los nodos de trabajo y el plano de control. En los nodos de trabajo se encuentran las aplicaciones en contenedores reales, junto con las herramientas de Kubernetes necesarias. El plano de control es donde residen las herramientas para gestionar este clúster. La Figura 1 tiene una mirada de alto nivel a esta arquitectura.
Plano de control y nodos de trabajo de Kubernetes.
Como puede ver en la Figura 1, la arquitectura se divide entre los nodos de trabajo y los nodos principales responsables de ejecutar cargas de trabajo y ejecutar herramientas de administración, respectivamente.
En ambos casos, los nodos son máquinas virtuales o reales.
Incremento de los nodos de Kubernetes frente a cargas de trabajo
Es importante tener en cuenta que Kubernetes conoce la infraestructura subyacente como los recursos (computación, memoria, disco y red) disponibles para su uso en la ejecución de cargas de trabajo del nodo de trabajo, pero no las controla directamente. Kubernetes es responsable de incrementar la escala de las cargas de trabajo, pero un mecanismo de orden superior (como el aumento de escala automático de la nube pública o la intervención manual) es responsable de ajustar la disponibilidad de los nodos. Un controlador (del que aprenderá en breve) está disponible para interactuar con sistemas externos para este propósito.
Componentes del nodo de trabajo de Kubernetes
La Figura 2 ilustra los elementos esenciales de un nodo de trabajo de Kubernetes. Echemos un vistazo a cada uno de los componentes.
Detalle del nodo de trabajo de Kubernetes.
Kubelet: Un kubelet es un programa "pequeño” que se ejecuta en el nodo de trabajo responsable de negociar entre el plano de control y el nodo. Su propósito principal es hacer cumplir las directivas que provienen del clúster de nodos principales en los pods, así como informar sobre la condición actual de las cargas de trabajo.
Proxy de Kube: El proxy de kube es responsable de hacer cumplir las reglas de la red en el nodo y permitir el tráfico hacia y desde el nodo.
El proxy de kube es distinto del ingreso, que opera a nivel de clúster y define reglas para las rutas de red al clúster.
Pods: Los pods son la unidad de trabajo discreta en el nodo. Los pods son el nivel de replicación. Son una abstracción que envuelve una o varias aplicaciones en contenedores. Los pods proporcionan una forma de agrupar y aislar, de forma lógica, los contenedores que se ejecutan juntos, al mismo tiempo que permiten la comunicación entre pods en la misma máquina. La relación entre contenedores y pods está controlada por descriptores de implementación de Kubernetes.
Implementaciones y ReplicaSets: Los pods generalmente se configuran e implementan como parte de un ReplicaSet. Un ReplicaSet define las características de tiempo de ejecución deseadas del pod y hace que Kubernetes funcione para mantener ese estado. Los ReplicaSets generalmente se definen mediante una implementación, que define tanto los parámetros del ReplicaSet como la estrategia a utilizar (es decir, si los pods se actualizan o recrean) al administrar el clúster.
Sidecars: A nivel de pod, la funcionalidad adicional se habilita a través de complementos adicionales. Sidecars maneja tareas como el registro a nivel de pod y la recopilación de estadísticas.
La Figura 3 proporciona una vista más detallada de los pods en un nodo de trabajo.
Figura 3. Detalle del pod de Kubernetes.
Plano de control de Kubernetes
Hasta ahora nos hemos centrado en comprender el lado del trabajo de las cosas. Pasemos ahora al lado del controlador y comprendamos cómo opera Kubernetes para controlar el funcionamiento del clúster.
La Figura 4 ofrece una vista detallada de los componentes del nodo principal.
Figura 4. Detalle del nodo principal de Kubernetes.
Etcd: El componente más simple de entender es etcd (pronunciado "et-cee-dee”). Etcd es un almacén de objetos distribuidos que actúa como base de datos de registro para la configuración y el estado de todo el clúster.
Servidor API: Como se ve claramente en la Figura 4, el servidor API es el mecanismo de comunicación central para el clúster. Gestiona la interacción entre el plano de control, los nodos de trabajo y los administradores, a medida que aplican cambios de configuración a través de las herramientas de línea de comandos de Kubernetes (como kubectl) u otra interfaz de usuario.
Scheduler: El Scheduler es responsable de identificar el nodo en el que se ejecutarán los pods. Los detalles de cómo se determina esto, varían según las características de los pods y el estado existente de los nodos disponibles. La estrategia de cómo el scheduler se acerca a esta toma de decisiones se puede ajustar hasta la capacidad de escribir schedulers personalizados. El programador interactúa con el servidor API en la realización de su trabajo.
Controller: El componente del controlador es responsable de mantener el clúster en el estado deseado, según lo configurado, y de moverlo hacia ese estado cuando se aleja de él. El controller actúa como una especie de termostato que especifica un estado deseado y luego trabaja para mantenerlo.
En la terminología de Kubernetes, crea un objeto, que es una entidad persistente registrada dentro de etcd. El objeto es un registro de cómo deberían ser las cosas. Luego, el controller actúa para asegurarse de que el objeto tenga las especificaciones o propiedades deseadas.
Como ejemplo, un ReplicaSet (mencionado anteriormente) define cuántos pods deben ejecutarse según los criterios de uso. El ReplicaSet es el objeto, y el recuento de pod detallado es la especificación. El estado real del clúster con respecto a ese ReplicaSet es el estado. El controller recibe informes consistentes del clúster en cuanto a este estado, y toma medidas para que el estado coincida con las especificaciones mediante la creación o destrucción de módulos.
Repositorio de imágenes de contenedores
Un último componente para tener en cuenta es el repositorio de imágenes (también llamado registro de imágenes). Este componente existe fuera del clúster y los administradores, así como el plano de control, acceden a él para descargar las definiciones de contenedor necesarias. Los registros están alojados por una variedad de organizaciones, incluido Docker Hub, y pueden ser públicos o privados. Todos los principales proveedores de nube ofrecen repositorios administrados para uso empresarial.
Kubernetes regula los contenedores
Ahora comprende la arquitectura de Kubernetes y cómo funciona Kubernetes para lograr su objetivo. No es un sistema simple, pero eso se debe a que implementar, administrar e incrementar la escala de aplicaciones basadas en contenedores no es un objetivo simple. Kubernetes es lo suficientemente configurable y flexible para hacer frente a la amplia gama de escenarios de aplicaciones, basadas en contenedores, que se encuentran en la naturaleza.
Kubernetes es la tecnología preeminente en los enfoques actuales de la arquitectura de software. En consecuencia, el conocimiento de Kubernetes será esencial para cualquier persona interesada en DevOps, contenedores, aplicaciones nativas de la nube y arquitectura de microservicios.
Basado en el artículo de Matthew Tyson (InfoWorld) y editado por CIO Perú
Matthew Tyson es fundador de Dark Horse Group, Inc. Cree en la tecnología que da prioridad a las personas. Cuando no está tocando la guitarra, Tyson explora el campo y el interior filosófico. Escribe para JavaWorld desde el 2007.
Puede ver también: