Arquitectura de Kubernetes

En la entrada inmediata anterior intitulada "¿Qué es Kubernetes?", revisamos con cierto detalle qué es Kubernetes. En esta entrada, exploraremos la arquitectura de Kubernetes, los diferentes componentes de los Nodos Maestro y Nodo Trabajador, la administración del estado del clúster con etcd y los requisitos de configuración de la red. También hablaremos sobre la especificación de red denominada Container Network Interface (CNI), que utiliza Kubernetes.

Los objetivos a tratar en esta entrada son:

• Analizar la arquitectura de Kubernetes.
• Explicar los diferentes componentes de los Nodos Maestro y Nodo Trabajador.
• Discutir sobre la gestión del estado del clúster con etcd.
• Revisar los requisitos de configuración de la red para Kubernetes.

Arquitectura de Kubernetes

En un nivel muy alto, Kubernetes tiene los siguientes componentes principales:

• Uno o más "Nodos Maester"
• Uno o más "Nodos Worker"
• Almacén de key-value distribuido, como etcd

A continuación, exploraremos la arquitectura de Kubernetes con más detalle.

Nodo Maestro o Amo (Master Node)

El Nodo Principal, Nodo Amo o Nodo Maestro proporciona un entorno de ejecución para el plano de control, responsable de administrar el estado de un clúster de Kubernetes. Es el cerebro detrás de todas las operaciones dentro del clúster. Los componentes del plano de control son agentes con roles muy distintos en la gestión del clúster. Para comunicarse con el clúster de Kubernetes, los usuarios envían solicitudes al nodo principal a través de una herramienta de interfaz de línea de comandos (CLI), un panel de Interfaz Gráfica de Usuario (GUI) basada en Navegador o una Interfaz de Programación de Aplicaciones (API).

Componentes del Nodo Maestro o Amo

El Nodo Principal, Nodo Amo o Nodo Maestro, cuenta con los siguientes componentes:

• API Server
• Scheduler
• Controller Managers
• etcd

En las secciones siguientes, las discutiremos con mayor detalle.

Componentes del Nodo Maestro o Amo - API Server

Todas las tareas administrativas están coordinadas por kube-apiserver, un componente del plano de control central que se ejecuta en el nodo principal. El Servidor API o API Server intercepta las llamadas RESTful de usuarios, operadores y agentes externos, luego las valida y las procesa.

Durante el procesamiento, el API Server lee el estado actual del clúster de Kubernetes desde el etcd y después de la ejecución de una llamada, el estado resultante del clúster de Kubernetes se guarda en el almacén de datos distribuidos de llave-valor (key-value) para su persistencia. El API Server es el único componente del plano principal o maestro, que se comunica con el almacén de datos etcd, tanto para leer como para guardar la información de estado del clúster de Kubernetes desde/hacia él, actuando como una interfaz de intermediario para cualquier otro agente del plano de control que requiera acceder a los datos del clúster. Almacén de Datos.

El API Server es altamente configurable y personalizable. También admite la adición de API Servers personalizados, cuando el API Server principal se convierte en un proxy para todos los API Servers personalizados secundarios, enrutando todas las llamadas RESTful entrantes a ellos en función de reglas personalizadas definidas.

Componentes del Nodo Maestro o Amo - Scheduler

La función del Kube Scheduler es asignar nuevos objetos, como pods, a los Nodos. Durante el proceso de agendado-programación, las decisiones se toman según el estado actual del clúster de Kubernetes y los requisitos del nuevo objeto. El Scheduler obtiene de etcd, a través del API Server, datos de uso de recursos para cada Nodo Trabajador (Worker Node) en el clúster. El Scheduler también recibe del API Server los requisitos del nuevo objeto que forman parte de sus datos de configuración.

Los requisitos pueden incluir restricciones que los usuarios y operadores establezcan, como programar el trabajo en un nodo etiquetado con el par disk==ssdkey/value. El Scheduler también tiene en cuenta los requisitos de Calidad de Servicio (QoS), la ubicación de los datos, la afinidad, la antiafinidad, las "manchas" (taints), la tolerancia, etc.

El Scheduler es altamente configurable y personalizable. Se soportan y admiten Schedulers adicionales personalizados, por lo que los datos de configuración del objeto deben incluir el nombre del Scheduler personalizado que se espera que tome la decisión de agendado-programación para ese objeto en particular; si no se incluyen tales datos, se selecciona el Scheduler predeterminado.

Un Scheduler es extremadamente importante y bastante complejo en un clúster Kubernetes de varios nodos. En un clúster Kubernetes de un solo nodo, como el que se explora más adelante en este curso, el trabajo del Scheduler es bastante simple.

Componentes del Nodo Maestro o Amo - Controller Managers

Los Controller Managers son componentes del plano de control en el Nodo Principal, Maestro o Amo que ejecuta controladores para regular el estado del clúster Kubernetes. Los controladores son bucles de vigilancia que se ejecutan continuamente y comparan el estado deseado del clúster (proporcionado por los datos de configuración de los objetos) con su estado actual (obtenido del almacén de datos etcd a través del API Server). En caso de una discrepancia, se toman medidas correctivas en el clúster hasta que su estado actual coincida con el estado deseado.

El kube-controller-manager ejecuta controladores responsables de actuar cuando los nodos dejan de estar disponibles, para garantizar que los recuentos de pod sean los esperados, para crear endpoilnts, cuentas de servicio y tokens de acceso a las API.

El cloud-controller-manager ejecuta controladores responsables de interactuar con la infraestructura subyacente de un proveedor de La Nube cuando los nodos dejan de estar disponibles, para administrar los volúmenes de almacenamiento cuando los proporciona un servicio en La Nube y para administrar el enrutamiento y el equilibrio de carga.

Componentes del Nodo Maestro o Amo - etcd

etcd es un almacén de datos distribuidos de key-value que se utiliza para conservar el estado de un clúster de Kubernetes. Los datos nuevos se escriben en el almacén de datos solo agregándolos. Los datos nunca se reemplazan en el almacén de datos. Los datos obsoletos se compactan periódicamente para minimizar el tamaño del almacén de datos.

De todos los componentes del plano de control, solo el API Server puede comunicarse con el almacén de datos etcd.

La herramienta de administración basadas en Interfaz de Línea de Comando (CLI) de etcd proporciona capacidades de copia de seguridad, instantáneas y restauración que son útiles especialmente para un clúster Kubernetes de instancia única de etcd, que es común verles en entornos de desarrollo y aprendizaje. Sin embargo, en los entornos de Stage y Producción, es extremadamente importante replicar los almacenes de datos en modo Alta Disponibilidad o HA, para la resiliencia de los datos de configuración del clúster.

Algunas herramientas de arranque del clúster Kubernetes, de forma predeterminada, aprovisionan Nodos Maestros etcd apilados, donde el almacén de datos se ejecuta junto con los otros componentes del Plano de Control en el mismo Nodo Maestro, compartiéndolos con ellos. Para el aislamiento del almacén de datos de los componentes del Plano de Control, el proceso de arranque se puede configurar para utilizar un etcd externo, donde el almacén de datos se aprovisiona en un "host" separado dedicado, reduciendo así las posibilidades de un fallo de etcd. Las configuraciones etcd, tanto apiladas como externas, admiten configuraciones en modalidad HA. etcd se basa en el algoritmo Raft Consensus que permite que una colección de máquinas funcione como un grupo coherente, que pueda sobrevivir a las fallas de algunos de sus miembros. En un momento dado, uno de los nodos del grupo será el Maestro y el resto serán los Seguidores. Cualquier nodo puede tratarse como un Nodo Maestro.

etcd está escrito en el lenguaje de programación Go (de Google). En Kubernetes, además de almacenar el estado del clúster, etcd también se usa para almacenar detalles de configuración como subredes, ConfigMaps, Secrets, etc.

Nodo Trabajador (Worker Node)

Un Nodo Trabajador proporciona un entorno de ejecución para las aplicaciones cliente. Aunque son Microservicios en Contenedores, estas aplicaciones están encapsuladas en pods, controlados por los agentes del Plano de Control del Clúster en el que se ejecutan, dentro del Nodo Principal. Los pods se programan en los Nodos Trabajadores, donde encuentran los recursos informáticos, de memoria y de almacenamiento necesarios para ejecutarse, así como las redes para comunicarse entre sí y con el mundo exterior. Un pod es la unidad de programación más pequeña de Kubernetes. Es una colección lógica de uno o más Contenedores Programados juntos. Los exploraremos más a fondo en capítulos posteriores.

Además, para acceder a las aplicaciones desde el mundo exterior, nos debemos conectar a los Nodos Trabajadores y NO al Nodo Maestro. Profundizaremos en esto en capítulos futuros.

Componentes del Nodo Trabajador

Los Nodos Trabajadores tienen los siguientes componentes:

• Container runtime
• kubelet
• kube-proxy
• Addons para el DNS, Dashboard, cluster-level monitoring y logging

En las próximas secciones, los discutiremos con más detalle.

Componentes del Nodo Trabajador: Container Runtime (tiempo de ejecución o ambiente de ejecución)

Aunque Kubernetes se describe como un "motor de orquestación de contenedores", no tiene la capacidad de manejar directamente los contenedores. Para ejecutar y administrar el ciclo de vida de un contenedor, Kubernetes requiere un tiempo o ambiente de ejecución de contenedor en el Nodo donde se programará un Pod y sus contenedores. Kubernetes admite muchos tiempos o ambientes de ejecución de contenedores:

Docker: aunque es una plataforma de contenedores que utiliza containerd como ambiente de ejecución de contenedores, es el más utilizado con Kubernetes
CRI-O: un ambiente de ejecución de contenedores ligero para Kubernetes. También admite registros de imágenes de Dockercontainerd: un ambiente de ejecución de contenedores simple y portátil que proporciona robustez
rkt: un motor de contenedor nativo para Pods. También ejecuta imágenes de Dockerrktlet: una implementación de Kubernetes Container Runtime Interface (CRI) que usa rkt.

Componentes del Nodo Trabajador: kubelet

El kubelet es un agente que se ejecuta en cada nodo y se comunica con los componentes del Plano de Control desde el nodo principal. Recibe definiciones de Pod, principalmente del Servidor de las API, e interactúa con el Entorno de Ejecución del Contenedor en el Nodo, para ejecutar Contenedores asociados con el Pod. También monitorea el estado de los Contenedores en ejecución del Pod.

El kubelet se conecta al Entorno de Ejecución del Contenedor mediante la Interfaz de Entorno de Ejecución del Contenedor (Container Runtime Interface - CRI). CRI consta de búferes de protocolo, API de gRPC y bibliotecas.

Interfaz de Entorno de Ejecución del Contenedor

Como se muestra arriba, el kubelet que actúa como cliente gRPC se conecta al "shim CRI" (Calzas CRI) que actúa como Servidor gRPC para realizar operaciones de Contenedor e Imagen. CRI implementa dos servicios: ImageService y RuntimeService. El primero (ImageService) es responsable de todas las operaciones relacionadas con la Imagen, mientras que el segundo (RuntimeService) es responsable de todas las operaciones relacionadas con el Pod y el Contenedor.

Los Tiempos o Entornos de Ejecución de Contenedores solían estar codificados en Kubernetes, pero con el desarrollo de CRI, Kubernetes ahora es más flexible y usa diferentes Tiempos o Entornos de Ejecución de Contenedores sin la necesidad de volver a compilar. Kubernetes puede usar cualquier Tiempo o Entorno de Ejecución de Contenedor que implemente CRI para administrar Pods, Contenedores e Imágenes de Contenedor.

En la siguiente sección, discutiremos algunas de las "shim CRI".

Componentes del Nodo Trabajador: "Shim" CRI o Calzas CRI

A continuación, encontrará algunos ejemplos de calzas CRI:

• Dockershim (Estibador)
  Con Dockershim, los Contenedores se crean utilizando Docker instalado en los Nodos de Trabajo. Internamente, Docker usa containerd para crear y administrar Contenedores.

• cri-containerd
  Con cri-containerd, podemos usar directamente la descendencia más pequeña de Docker en un Contenedor para crear y administrar Contenedores.

• CRI-O
  CRI-O permite usar cualquier Entorno o Tiempo de Ejecución compatible con la Open Container Initiative (OCI) en Kubernetes. En el momento en que se creó este documento, CRI-O admitía runC y Clear Containers como Entornos o Tiempos de Ejecución de Contenedores. Sin embargo y en principio, se puede conectar cualquier Entorno o Tiempo de Ejecución que sea compatible con la OCI.

Componentes del Nodo Trabajador: kube-proxy

El kube-proxy es el agente de red que se ejecuta en cada Nodo e es responsable de las actualizaciones dinámicas y el mantenimiento de todas las reglas de red en el Nodo. Extrae los detalles de la red de los Pods y reenvía las solicitudes de conexión a los Pods.

Exploraremos las redes Pod con más detalle en entregas posteriores.

Componentes del Nodo Trabajador: Addons (Complementos)

Los Complementos son características y funcionalidades del Clúster que aún no están disponibles dentro de Kubernetes, por lo que se implementan a través de Pods y servicios de terceros.

DNS: El DNS del clúster es un servidor DNS necesario para asignar registros DNS a objetos y recursos de Kubernetes.
Dashboard o Panel de Control: Interfaz de usuario basada en web (vía navegador), de propósito general, para la gestión-administración de los Clústeres.
Monitoring o Supervisión: Recopila métricas de Contenedores a nivel de Clúster y las guarda en un almacén central de datos.
Logging o Registro: Recopila registros de Contenedores a nivel de Clúster y los guarda en un almacén central de registros para su posterior análisis.

Desafíos para las Redes

Las aplicaciones basadas en microservicios desacoplados dependen en gran medida de las redes para imitar el acoplamiento estrecho que alguna vez estuvo disponible en la era monolítica. Las redes, en general, no son las más fáciles de entender e implementar. Kubernetes no es una excepción, ya que un orquestador de microservicios en Contenedores debe abordar 4 desafíos de red distintos:

• Comunicación de Contenedor a Contenedor dentro de los Pods
• Comunicación de Pod a Pod en el mismo Nodo y en todos los Nodos del Clúster
• Comunicación Pod-to-Service dentro del mismo Namespace y entre Namespaces de Clústers
• Comunicación externa al servicio para que los clientes accedan a aplicaciones en un Clúster.

Todos estos desafíos de redes deben abordarse antes de implementar un Clúster de Kubernetes. A continuación, veremos cómo resolvemos estos desafíos.

Comunicación de Contenedor a Contenedor dentro de los Pods

Al hacer uso de las características del kernel del sistema operativo del host subyacente, un Entorno o Tiempo de Ejecución de Contenedores crea un espacio de red aislado para cada Contenedor que inicia. En Linux, ese espacio de red aislado se denomina Network Namespace. Un Network Namespace se comparte entre Contenedores o con el sistema operativo del host.

Cuando se inicia un Pod, se crea un Network Namespace dentro del Pod, y todos los contenedores que se ejecutan dentro del Pod compartirán ese Network Namespace para que puedan comunicarse entre sí a través de localhost.

Comunicación Pod a Pod a través de los Nodos del Clúster

En un Clúster Kubernetes, los Pods son asignados a los Nodos de forma aleatoria. Independientemente de su Nodo Anfitrión (host), se espera que los Pods puedan comunicarse con todos los demás Pods del Clúster, todo esto sin la implementación de la Traducción de Direcciones de Red (NAT). Este es un requisito fundamental de cualquier implementación de redes en Kubernetes.

El modelo de red de Kubernetes tiene como objetivo reducir la complejidad y trata los En un clúster de Kubernetes, los pods se programan en los nodos de forma aleatoria. Independientemente de su nodo host, se espera que los pods puedan comunicarse con todos los demás pods del clúster, todo esto sin la implementación de la traducción de direcciones de red (NAT). Este es un requisito fundamental de cualquier implementación de redes en Kubernetes.

El modelo de red de Kubernetes tiene como objetivo reducir la complejidad y trata los Pods como lo hace con las Máquinas Virtuales (VMs) en una red, donde cada Máquina Virtual recibe una dirección IP, por lo que cada Pod recibe una dirección IP. Este modelo se llama "IP-per-Pod" y garantiza la comunicación de Pod a Pod, del mismo modo que las máquinas virtuales pueden comunicarse entre sí.

Sin embargo, no nos olvidemos de los Contenedores. Éstos comparten los Network Namespaces de la red del Pod y deben coordinar la asignación de puertos dentro del Pod tal como lo harían las aplicaciones en una Máquina Virtual, todo mientras pueden comunicarse entre sí en el localhost, dentro del Pod. Sin embargo, los Contenedores se integran con el modelo de red general de Kubernetes mediante el uso del Container Network Interface (CNI) compatible con los complementos o pugins del CNI. El CNI es un conjunto de especificaciones y bibliotecas que permiten a los complementos configurar la red para los Contenedores. Si bien hay algunos complementos o plugins principales, la mayoría de los complementos o plugins del CNI son soluciones de Redes Definidas por Software (SDN) de terceros que implementan el modelo de redes de Kubernetes. Además de abordar el requisito fundamental del modelo de red, algunas soluciones de red ofrecen soporte para políticas de red. Flannel, Weave, Calico son solo algunas de las soluciones de Redes Definidas pot Software disponibles para los Clústeres de Kubernetes.

El Entorno o Tiempo de Ejecución del Contenedor delega la asignación de IP al Container Network Interface (CNI), que se conecta al plugin configurado subyacente, como Bridge o MACvlan, para obtener la dirección IP. Una vez que el respectivo plugin proporciona la dirección IP, el Container Network Interface (CNI) la reenvía al Entorno o Tiempo de Ejecución del Contenedor solicitado.

Para obtener más detalles, puede explorar la documentación de Kubernetes.

Comunicación desde el Pod hacia el munto exterior

Para implementar con éxito aplicaciones en Contenedores que se ejecutan en Pods dentro de un clúster de Kubernetes, se requiere accesibilidad (vía la red de cómputo) desde y hacia el mundo exterior. Kubernetes permite esta accesibilidad a través de Servicios, que son construcciones complejas que encapsulan las definiciones de reglas de red, en los Nodos del Clúster. Al exponer los servicios al mundo exterior con el uso del kube-proxy, las aplicaciones se vuelven accesibles desde fuera del Clúster a través de una IP virtual.

Tendremos una entrada completa dedicado a esto, por lo que profundizaremos en esto más adelante.