Cómo funciona Kubernetes
Una instalación de Kubernetes correctamente configurada depende de la buena comprensión de la arquitectura del sistema de Kubernetes. Aquí se examinan todos los componentes de una instalación de Kubernetes.
¿Qué es un clúster de equipos?
Un clúster es un conjunto de equipos que se configura para que funcionen de forma conjunta y se muestren como un solo sistema. Los equipos configurados en el clúster manejan los mismos tipos de tareas. Por ejemplo, hospedar sitios web o API, o ejecutar trabajos con gran carga de procesos.
Un clúster usa un software centralizado que se encarga de programar y controlar estas tareas. Los equipos de un clúster que ejecutan las tareas se denominan nodos, y los equipos que ejecutan el software de programación se denominan planos de control.
Arquitectura de Kubernetes
Recuerde que un orquestador es un sistema que implementa y administra aplicaciones. También hemos visto que un clúster es un conjunto de equipos que funcionan de forma conjunta y que se muestran como un solo sistema. Kubernetes se usa como el software de orquestación y de clúster para implementar las aplicaciones y responder a los cambios en las necesidades de recursos de proceso.
Un clúster de Kubernetes contiene al menos un plano principal y uno o más nodos. Las instancias de nodos y planos de control pueden ser dispositivos físicos, máquinas virtuales o instancias en la nube. El sistema operativo host predeterminado de Kubernetes es Linux, compatible de manera predeterminada con las cargas de trabajo basadas en Linux.
También puede ejecutar cargas de trabajo de Microsoft con Windows Server 2019 o posterior en los nodos del clúster. Por ejemplo, imagine que el servicio de procesamiento de datos de la aplicación de seguimiento de drones se ha escrito como una aplicación .NET 4.5 que usa llamadas API específicas del sistema operativo Windows. Este servicio solo se puede ejecutar en nodos que ejecutan un sistema operativo Windows Server.
Ahora, echemos un vistazo más detallado a los nodos de trabajo y los planos de control, así como al software que se ejecuta en cada uno de ellos. Al instalar Kubernetes, es útil comprender el rol de cada componente y la parte del clúster en que cada uno de ellos se ejecuta.
Plano de control de Kubernetes
El plano de control de Kubernetes de un clúster de Kubernetes ejecuta una colección de servicios que administra la funcionalidad de orquestación en Kubernetes.
Desde el punto de vista de quien está aprendiendo, tiene sentido usar un único plano de control en el entorno de prueba a medida que se va explorando la funcionalidad de Kubernetes, Sin embargo, en implementaciones de producción y en la nube, como Azure Kubernetes Service (AKS), la configuración preferida es una implementación de alta disponibilidad con entre tres y cinco planos de control replicados.
Nota:
El hecho de que un plano de control ejecute software específico para mantener el estado del clúster no excluye que el plano de control ejecute otras cargas de trabajo de proceso, pero, por lo general, se recomienda excluir el plano de control de la ejecución de cargas de trabajo de aplicaciones no críticas y de usuario.
Nodo de Kubernetes
Un nodo en un clúster de Kubernetes es la parte en la que se ejecutan las cargas de trabajo de proceso. Cada nodo se comunica con el plano de control a través del servidor de la API para informarle sobre los cambios de estado en el nodo.
Servicios que se ejecutan en un plano de control
Kubernetes se basa en varios servicios administrativos que se ejecutan en el plano de control. Estos servicios administran aspectos como la comunicación de componentes del clúster, la programación de cargas de trabajo y la persistencia de estado del clúster.
Los siguientes servicios componen el plano de control de un clúster de Kubernetes:
- Servidor de API
- Memoria auxiliar
- Scheduler
- Administrador de controladores
- Administrador de controladores de nube
¿Qué es el servidor de API?
El servidor de la API podría considerarse como el front-end para el plano de control del clúster de Kubernetes. Todas las comunicaciones realizadas entre los componentes de Kubernetes se realizan a través de esta API.
Por ejemplo, los usuarios usan una aplicación de línea de comandos denominada kubectl que permite ejecutar comandos en el servidor de API del clúster de Kubernetes. El componente que proporciona esta API se denomina kube-apiserver, y es posible implementar varias instancias de este componente para que se pueda escalar en el clúster.
Esta API expone una API RESTful que permite publicar comandos o archivos de configuración basados en YAML. YAML es un estándar de serialización de datos legibles para los lenguajes de programación. Los archivos YAML se usan para definir el estado previsto de todos los objetos dentro de un clúster de Kubernetes.
Por ejemplo, imagine que quiere aumentar el número de instancias de la aplicación en el clúster. Se debe definir el nuevo estado con un archivo basado en YAML y enviar este archivo al servidor de la API. El servidor de API valida la configuración, la guarda en el clúster y, por último, tramita el aumento configurado de implementaciones de la aplicación.
¿Qué es la memoria auxiliar?
La memoria auxiliar es un almacenamiento persistente en el que el clúster de Kubernetes guarda su configuración completa. Kubernetes usa un almacén de clave-valor confiable distribuido de alta disponibilidad denominado etcd. En este almacén de clave-valor se almacenan el estado actual y el estado deseado de todos los objetos del clúster.
En un clúster de Kubernetes de producción, la recomendación de Kubernetes oficial es tener entre tres y cinco instancias replicadas de la base de datos de etcd para obtener alta disponibilidad.
Nota:
etcd no es responsable de la copia de seguridad de datos. El responsable de asegurarse de que existe un plan de copia de seguridad eficaz para hacer copias de seguridad de los datos de etcd es usted.
¿Qué es Scheduler?
Scheduler es el componente responsable de asignar las cargas de trabajo en todos los nodos. Supervisa el clúster en busca de contenedores recién creados y los asigna a nodos.
¿Qué es el administrador de controladores?
El administrador de controladores inicia y supervisa los controladores configurados para un clúster por medio del servidor de API.
Kubernetes utiliza controladores para realizar un seguimiento de los estados de los objetos en el clúster. Cada controlador se ejecuta en un bucle de no terminación mientras supervisa y responde a los eventos del clúster. Por ejemplo, hay controladores para supervisar nodos, contenedores y puntos de conexión.
El controlador se comunica con el servidor de la API para determinar el estado del objeto. Si el estado actual es diferente del estado deseado del objeto, el controlador toma medidas para garantizar el estado deseado.
Imagine que uno de los tres contenedores que se ejecutan en el clúster deja de responder y produce un error. En este caso, un controlador decide si es necesario iniciar contenedores nuevos para garantizar que las aplicaciones estén siempre disponibles. Si el estado deseado es ejecutar tres contenedores en todo momento, se programa la ejecución de un contenedor nuevo.
¿Qué es el administrador de controladores de nube?
La función del administrador de controladores de nube es integrar las tecnologías de nube subyacentes del clúster cuando este se ejecuta en un entorno de nube. Estos servicios pueden ser equilibradores de carga, colas o almacenamiento, por ejemplo.
Servicios que se ejecutan en un nodo
Hay varios servicios que se ejecutan en un nodo de Kubernetes para controlar el modo en que se ejecutan las cargas de trabajo.
Los servicios siguientes se ejecutan en el nodo de Kubernetes:
- Kubelet
- Kube-proxy
- Entorno de ejecución de contenedor
¿Qué es kubelet?
Kubelet es el agente que se ejecuta en cada nodo del clúster y que supervisa las solicitudes de trabajo desde el servidor de la API. Su labor es garantizar que la unidad de trabajo solicitada está en ejecución y en buen estado.
Kubelet supervisa los nodos y se asegura de que los contenedores programados en cada nodo se ejecutan según lo esperado. Kubelet administra solo los contenedores que crea Kubernetes. y no es responsable de volver a programar el trabajo para que se ejecute en otros nodos si el nodo actual no puede ejecutar el trabajo.
¿Qué es kube-proxy?
El componente kube-proxy es responsable de las redes de clústeres locales y se ejecuta en cada nodo. Garantiza que cada nodo tenga una dirección IP única. También implementa reglas para controlar el enrutamiento y el equilibrio de carga del tráfico con iptables e IPVS.
Este proxy no presta servicios DNS por sí mismo. Se recomienda usar un complemento de clúster DNS basado en CoreDNS, que se instala de forma predeterminada.
¿Qué es el entorno de ejecución de contenedor?
El entorno de ejecución de contenedor es el software subyacente que ejecuta los contenedores en un clúster de Kubernetes. El entorno de ejecución es responsable de capturar, iniciar y detener las imágenes de contenedor. Kubernetes admite varios runtime de contenedor, incluidos, entre otros, Docker, containerd, rkt, CRI-O y frakti. La compatibilidad con muchos tipos de entornos de ejecución de contenedor se basa en la interfaz de entorno de ejecución de contenedor (CRI). CRI es un diseño de complemento que permite a kubelet comunicarse con el entorno de ejecución de contenedores disponible.
El runtime de contenedor predeterminado en AKS está en containerd, un runtime de contenedor estándar del sector.
Interactuación con un clúster de Kubernetes
Kubernetes proporciona una herramienta de línea de comandos denominada kubectl para administrar el clúster. kubectl se usa para enviar comandos al plano de control del clúster o para obtener información sobre todos los objetos de Kubernetes a través del servidor de la API.
kubectl usa un archivo de configuración que incluye la siguiente información de configuración:
- La configuración del clúster especifica un nombre de clúster, información del certificado y el punto de conexión de la API de servicio asociado al clúster. Esta definición permite la conexión desde una sola estación de trabajo a varios clústeres.
- La configuración del usuario especifica los usuarios y sus niveles de permisos al acceder a los clústeres configurados.
- La configuración del contexto agrupa los clústeres y los usuarios mediante un nombre descriptivo. Por ejemplo, podemos tener un "dev-cluster" y un "prod-cluster" para identificar los clústeres de desarrollo y de producción.
Puede configurar kubectl para conectarse a varios clústeres proporcionando el contexto correcto como parte de la sintaxis de la línea de comandos.
Pods de Kubernetes
Un pod representa una única instancia de una aplicación que se ejecuta en Kubernetes. Las cargas de trabajo que se ejecutan en Kubernetes son aplicaciones en contenedores. A diferencia de lo que ocurre en un entorno de Docker, no se pueden ejecutar contenedores directamente en Kubernetes. El contenedor se empaqueta en un objeto de Kubernetes denominado “pod”. Un pod es el objeto más pequeño que se puede crear en Kubernetes.
Un solo pod puede albergar uno o varios contenedores. Pero, por lo general, un pod no contiene múltiplos de la misma aplicación.
Un pod incluye información sobre el almacenamiento compartido y la configuración de red, y una especificación sobre cómo ejecutar sus contenedores empaquetados. Las plantillas de pod se usan para definir la información sobre los pods que se ejecutan en el clúster. Las plantillas de pod son archivos codificados con YAML que se reutilizan y se incluyen en otros objetos para administrar implementaciones de pods.
Por ejemplo, supongamos que queremos implementar un sitio web en un clúster de Kubernetes. Hay que crear el archivo de definición del pod en el que se especifican la configuración y las imágenes de contenedor de la aplicación. Luego hay que implementar el archivo de definición del pod en Kubernetes.
Es poco probable que una aplicación web tenga un sitio web como único componente de la solución. Normalmente, una aplicación web tiene algún tipo de almacén de datos y otros elementos auxiliares. Los pods de Kubernetes también pueden incluir más de un contenedor.
Supongamos que en el sitio se usa una base de datos. El sitio web está empaquetado en el contenedor principal y la base de datos, en el contenedor auxiliar. Varios contenedores se comunican entre sí a través de un entorno. Los contenedores incluyen servicios para un sistema operativo host, una pila de red, un espacio de nombres de kernel, memoria compartida y un volumen de almacenamiento. El pod es el entorno de espacio aislado que presta todos estos servicios a la aplicación. También permite que los contenedores compartan su dirección IP asignada.
Puesto que se pueden crear muchos pods que se ejecutan en muchos nodos, puede costar identificarlos. Puede reconocer y agrupar pods con etiquetas de cadena que se especifican al definir un pod.
Ciclo de vida de un pod de Kubernetes
Los pods de Kubernetes tienen un ciclo de vida distintivo que afecta al modo en que se implementan, ejecutan y actualizan. Para empezar, envíe el manifiesto YAML del pod al clúster. Una vez enviado el archivo de manifiesto y guardado en el clúster, define el estado deseado del pod. Scheduler programa el pod en un nodo correcto con suficientes recursos para ejecutar el pod.
Estas son las fases del ciclo de vida de un pod:
| Fase | Descripción |
|---|---|
| Pending | El pod acepta el clúster, pero no todos los contenedores del clúster están configurados o listos para ejecutarse. El estado Pendiente indica el tiempo que un pod está esperando para programarse y el tiempo dedicado a descargar imágenes de contenedor. |
| En ejecución | El pod pasa a un estado en ejecución cuando todos sus recursos estén preparados. |
| Correcto | El pod pasa a un estado correcto al finalizar la tarea prevista y ejecutarse correctamente. |
| Con errores | Los pods pueden generar errores por varias razones. Es posible que se produzca un error en un contenedor del pod, lo que conduce a la terminación de todos los demás contenedores, o es posible que no se encontrase una imagen durante la preparación de los contenedores de pods. En estos tipos de casos, el pod puede pasar a un estado Con errores. Los pods pueden pasar a un estado Con errores desde los estados Pendiente o En ejecución. Un error específico también puede hacer que un pod vuelva a pasar al estado Pendiente. |
| Unknown | Si no se puede determinar el estado del pod, este está en un estado Desconocido. |
Los pods se mantienen en un clúster hasta que un controlador, el plano de control o un usuario los quita explícitamente. Cuando se elimina un pod, se crea un nuevo pod inmediatamente después. El nuevo pod se considera una instancia completamente nueva basada en el manifiesto del pod. No es una copia exacta, por lo que difiere del pod eliminado.
El clúster no guarda el estado del pod ni la configuración asignada dinámicamente. Así, no guarda ni el identificador ni la dirección IP del pod. Esto incide en el modo en que los pods se implementan y en cómo se diseñan las aplicaciones. Por ejemplo, no podemos usar direcciones IP preasignadas en los pods.
Estados del contenedor
Tenga en cuenta que las fases son un resumen del punto en que se encuentra el pod en su ciclo de vida. Al inspeccionar un pod, el clúster usa tres estados para realizar el seguimiento de los contenedores dentro de ese pod:
| State | Descripción |
|---|---|
| En espera | Estado predeterminado de un contenedor y estado en el que se encuentra el contenedor si no está en ejecución o finalizado. |
| En ejecución | El contenedor se está ejecutando según lo esperado sin problemas. |
| Finalizado | El contenedor ya no se está ejecutando. La razón es que todas las tareas se han completado o que ha habido un error en el contenedor por el motivo que sea. Al depurar ambos casos, hay disponibles un motivo y un código de salida. |