Operadores de Kubernetes

Capítulo 1. Los operadores enseñan nuevos trucos a Kubernetes

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Un Operador es una forma de empaquetar, ejecutar y mantener una aplicación Kubernetes. Una aplicación Kubernetes no sólo se implementa en Kubernetes, sino que está diseñada para utilizar y funcionar en concierto con las instalaciones y herramientas de Kubernetes.

Un Operador se basa en las abstracciones de Kubernetes para automatizar todo el ciclo de vida del software que gestiona. Dado que amplían Kubernetes, los Operadores proporcionan automatización específica de aplicaciones en términos familiares para una comunidad amplia y creciente. Para los programadores de aplicaciones, los Operadores facilitan la implementación y ejecución de los servicios básicos de los que dependen sus aplicaciones. Para los ingenieros de infraestructuras y los proveedores, los Operadores proporcionan una forma coherente de distribuir software en clústeres Kubernetes y reducir las cargas de soporte identificando y corrigiendo los problemas de las aplicaciones antes de que suene el busca.

Antes de empezar a describir cómo los Operadores realizan estas tareas, definamos algunos términos de Kubernetes para proporcionar contexto y un lenguaje compartido para describir los conceptos y componentes de los Operadores.

Cómo funciona Kubernetes

Kubernetes automatiza el ciclo de vida de una aplicación sin estado, como un servidor web estático. Sin estado, cualquier instancia de una aplicación es intercambiable. Este sencillo servidor web recupera archivos y los envía al navegador de un visitante. Como el servidor no registra estado ni almacena entradas o datos de ningún tipo, cuando falla una instancia del servidor, Kubernetes puede sustituirla por otra. Kubernetes denomina réplicas a estas instancias, cada una de las cuales es una copia de una aplicación que se ejecuta en el clúster.

Un clúster Kubernetes es un conjunto de ordenadores, llamados nodos. Todo el trabajo del clúster se ejecuta en uno, algunos o todos los nodos de un clúster. La unidad básica de trabajo, y de replicación, es el pod. Un pod es un grupo de uno o más contenedores Linux con recursos comunes como red, almacenamiento y acceso a memoria compartida.

Nota

La documentación sobre los pods de Kubernetes es un buen punto de partida para obtener más información sobre la abstracción de los pods.

A alto nivel, un clúster Kubernetes puede dividirse en dos planos. El plano de control es, en términos sencillos, el propio Kubernetes. Una colección de pods constituye el plano de control e implementa la interfaz de programación de aplicaciones (API) de Kubernetes y la lógica de orquestación del clúster.

El plano de aplicación, o plano de datos, es todo lo demás. Es el grupo de nodos donde se ejecutan los pods de aplicación. Uno o más nodos suelen estar dedicados a ejecutar aplicaciones, mientras que uno o más nodos suelen estar secuestrados para ejecutar sólo pods del plano de control. Al igual que con los pods de aplicaciones, pueden ejecutarse múltiples réplicas de componentes del plano de control en varios nodos controladores para proporcionar redundancia.

Los controladores del plano de control implementan bucles de control que comparan repetidamente el estado deseado de la agrupación con su estado real. Cuando ambos divergen, un controlador toma medidas para hacerlos coincidir. Los operadores amplían este comportamiento. El esquema de la Figura 1-1 muestra los principales componentes del plano de control, con nodos trabajadores que ejecutan cargas de trabajo de aplicaciones.

Aunque una división estricta entre los planos de control y de aplicación es un modelo mental conveniente y una forma habitual de implementar un clúster Kubernetes para segregar las cargas de trabajo, los componentes del plano de control son una colección de pods que se ejecutan en nodos, como cualquier otra aplicación. En los clústeres pequeños, los componentes del plano de control suelen compartir el mismo nodo o dos con las cargas de trabajo de las aplicaciones.

El modelo conceptual de un plano de control acordonado tampoco es tan ordenado. Por ejemplo, el agente kube let que se ejecuta en cada nodo forma parte del plano de control. Del mismo modo, un Operador es un tipo de controlador, que suele considerarse un componente del plano de control. Sin embargo, los operadores pueden difuminar esta frontera entre planos. Tratar los planos de control y aplicación como dominios aislados es una abstracción simplificadora útil, no una verdad absoluta.

Figura 1-1. Plano de control de Kubernetes y nodos trabajadores

Ejemplo: Servidor web sin estado

Puesto que aún no has configurado un clúster, los ejemplos de este capítulo son más bien "capturas de pantalla" del extracto de terminal que muestran cómo son las interacciones básicas entre Kubernetes y una aplicación. No se espera que ejecutes estos comandos como lo harás con los del resto del libro. En este primer ejemplo, Kubernetes gestiona una aplicación relativamente sencilla y no intervienen Operadores.

Considera un clúster que ejecuta una única réplica de un servidor web estático sin estado:

$ kubectl get pods>
NAME                        READY     STATUS    RESTARTS   AGE

staticweb-69ccd6d6c-9mr8l   1/1       Running   0          23s

Tras declarar que debe haber tres réplicas, el estado real del clúster difiere del estado deseado, y Kubernetes inicia dos nuevas instancias del servidor web para reconciliar ambos, escalando la implementación del servidor web:

$ kubectl scale deployment staticweb --replicas=3
$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
staticweb-69ccd6d6c-4tdhk   1/1     Running   0          6s
staticweb-69ccd6d6c-9mr8l   1/1     Running   0          100s
staticweb-69ccd6d6c-m9qc7   1/1     Running   0          6s

La eliminación de uno de los pods del servidor web desencadena el trabajo en el plano de control para restaurar el estado deseado de tres réplicas. Kubernetes inicia un nuevo pod para sustituir al eliminado. En este extracto, el pod de sustitución muestra un STATUS de ContainerCreating:

$ kubectl delete pod staticweb-69ccd6d6c-9mr8l
$ kubectl get pods
NAME                        READY   STATUS                RESTARTS   AGE
staticweb-69ccd6d6c-4tdhk   1/1     Running               0          2m8s
staticweb-69ccd6d6c-bk27p   0/1     ContainerCreating     0          14s
staticweb-69ccd6d6c-m9qc7   1/1     Running               0          2m8s

El servidor web de este sitio estático es intercambiable con cualquier otra réplica, o con un nuevo pod que sustituya a una de las réplicas. No almacena datos ni mantiene el estado de ninguna manera. Kubernetes no necesita hacer ningún arreglo especial para sustituir un pod averiado, ni para escalar la aplicación añadiendo o eliminando réplicas del servidor.

Stateful es difícil

La mayoría de las aplicaciones tienen estado. También tienen particularidades de inicio, interdependencia de componentes y configuración. A menudo tienen su propia noción de lo que significa "clúster". Necesitan almacenar de forma fiable datos críticos y, a veces, voluminosos. Ésas son sólo tres de las dimensiones en las que las aplicaciones del mundo real deben mantener el estado. Sería ideal gestionar estas aplicaciones con mecanismos uniformes, automatizando al mismo tiempo sus complejos requisitos de almacenamiento, red y conexión a clústeres.

Kubernetes no puede saberlo todo sobre todas las aplicaciones en clúster, complejas y con estado, sin dejar de ser general, adaptable y sencillo. Su objetivo es proporcionar un conjunto de abstracciones flexibles, que cubran los conceptos básicos de la aplicación en cuanto a programación, replicación y automatización de la conmutación por error, al tiempo que proporciona un mecanismo de extensión limpio para operaciones más avanzadas o específicas de la aplicación. Kubernetes, por sí solo, no conoce ni debe conocer los valores de configuración de, por ejemplo, un clúster de bases de datos PostgreSQL, con sus membresías ordenadas y su almacenamiento persistente y con estado.

Los operadores son SRE de software

La Ingeniería de Fiabilidad del Sitio (SRE) es un conjunto de pautas y principios para ejecutar grandes sistemas. Originada en Google, la SRE ha influido notablemente en la práctica del sector. Los profesionales deben interpretar y aplicar la filosofía de la SRE a las circunstancias particulares, pero un principio clave es automatizar la administración de sistemas escribiendo software para ejecutar tu software. Los equipos liberados del trabajo rutinario de mantenimiento tienen más tiempo para crear nuevas funciones, corregir errores y, en general, mejorar sus productos.

Un Operador es como un Ingeniero de Fiabilidad del Sitio automatizado para su aplicación. Codifica en software las habilidades de un administrador experto. Un Operador puede gestionar un clúster de servidores de bases de datos, por ejemplo. Conoce los detalles de configuración y gestión de su aplicación, y puede instalar un clúster de bases de datos de una versión de software y un número de miembros declarados. Un Operador sigue monitorizando su aplicación mientras se ejecuta, y puede hacer copias de seguridad de los datos, recuperarse de los fallos y actualizar la aplicación con el tiempo, automáticamente. Los usuarios del clúster emplean kubectl y otras herramientas estándar para trabajar con los Operadores y las aplicaciones que gestionan, porque los Operadores amplían Kubernetes.

Cómo funcionan los operadores

Los Operadores funcionan ampliando el plano de control y la API de Kubernetes. En su forma más simple, un Operador añade un punto final a la API de Kubernetes, denominado un recurso personalizado (CR), junto con un componente del plano de control que monitorea y mantiene los recursos del nuevo tipo. Este Operador puede entonces emprender acciones basadas en el estado del recurso. Esto se ilustra en la Figura 1-2.

Figura 1-2. Los operadores son controladores personalizados que vigilan un recurso personalizado

CRs de Kubernetes

Los CR son el mecanismo de extensión de la API en Kubernetes. Una definición de recurso personalizada (CRD) define una CR; es análoga a un esquema para los datos de la CR. A diferencia de los miembros de la API oficial, una CRD determinada no existe en todos los clústeres de Kubernetes. Los CRD amplían la API del clúster concreto en el que se definen. Los CRD proporcionan puntos finales para leer y escribir datos estructurados. Un usuario del clúster puede interactuar con los CR con kubectl u otro cliente de Kubernetes, como con cualquier otro recurso de la API.

Cómo se fabrican los operadores

Kubernetes compara un conjunto de recursos con la realidad, es decir, con el estado de ejecución del clúster. Toma medidas para que la realidad coincida con el estado deseado descrito por esos recursos. Los Operadores amplían ese patrón a aplicaciones específicas en clústeres específicos. Un Operador es un controlador personalizado de Kubernetes que observa un tipo de CR y toma acciones específicas de la aplicación para hacer que la realidad coincida con el spec de ese recurso.

Hacer un Operador significa crear un CRD y proporcionar un programa que se ejecute en bucle observando CRs de ese tipo. Lo que hace el Operador en respuesta a los cambios en el CR es específico de la aplicación que gestiona el Operador. Las acciones que realiza un Operador pueden incluir casi cualquier cosa: escalar una aplicación compleja, actualizaciones de la versión de la aplicación, o incluso gestionar módulos del núcleo para nodos de un clúster computacional con hardware especializado.

Ejemplo: El operador etcd

etcd es un almacén distribuido de claves y valores. En otras palabras, es una especie de clúster de base de datos ligero. Un clúster de etcd suele requerir un administrador con conocimientos para gestionarlo. Un administrador de etcd debe saber cómo

• Unir un nuevo nodo a un clúster etcd, lo que incluye configurar sus puntos finales, establecer conexiones con el almacenamiento persistente y hacer que los miembros existentes lo conozcan.

• Haz una copia de seguridad de los datos y la configuración del clúster etcd.

• Actualiza el clúster etcd a las nuevas versiones de etcd.

El Operador etcd sabe cómo realizar esas tareas. Un Operador conoce el estado interno de su aplicación y realiza acciones regulares para alinear ese estado con el estado deseado expresado en la especificación de uno o varios recursos personalizados.

Como en el ejemplo anterior, los fragmentos de shell que siguen son ilustrativos, y no podrás ejecutarlos sin una configuración previa. Harás esa configuración y ejecutarás un Operador en el Capítulo 2.

El caso del miembro desaparecido

Como el Operador de etcd entiende el estado de etcd, puede recuperarse del fallo de un miembro del clúster de etcd del mismo modo que Kubernetes sustituyó el pod de servidor web sin estado eliminado en nuestro ejemplo anterior. Supongamos que hay un clúster etcd de tres miembros gestionado por el Operador etcd. El propio Operador y los miembros del clúster etcd se ejecutan como pods:

$ kubectl get pods
NAME                              READY     STATUS    RESTARTS   AGE
etcd-operator-6f44498865-lv7b9    1/1       Running   0          1h
example-etcd-cluster-cpnwr62qgl   1/1       Running   0          1h
example-etcd-cluster-fff78tmpxr   1/1       Running   0          1h
example-etcd-cluster-lrlk7xwb2k   1/1       Running   0          1h

Eliminar un pod etcd desencadena una reconciliación, y el Operador etcd sabe cómo recuperar el estado deseado de tres réplicas, algo que Kubernetes no puede hacer solo. Pero a diferencia del reinicio en blanco de un servidor web sin estado, el Operador tiene que organizar la pertenencia al clúster del nuevo pod de etcd, configurándolo para los endpoints existentes y estableciéndolo con los restantes miembros de etcd:

$ kubectl delete pod example-etcd-cluster-cpnwr62qgl
$ kubectl get pods
NAME                              READY     STATUS            RESTARTS  AGE
etcd-operator-6f44498865-lv7b9    1/1       Running           0         1h
example-etcd-cluster-fff78tmpxr   1/1       Running           0         1h
example-etcd-cluster-lrlk7xwb2k   1/1       Running           0         1h
example-etcd-cluster-r6cb8g2qqw   0/1       PodInitializing   0         4s  

La vaina de recambio está en el estado PodInitializing.

La API etcd permanece disponible para los clientes mientras el Operador repara el clúster etcd. En el Capítulo 2, desplegarás el Operador etcd y lo pondrás a prueba utilizando la API de etcd para leer y escribir datos. Por ahora, conviene recordar que añadir un miembro a un clúster etcd en ejecución no es tan sencillo como ejecutar un nuevo pod etcd, y el Operador etcd oculta esa complejidad y repara automáticamente el clúster etcd.

¿Para quién son los Operadores?

El patrón Operador surgió en respuesta a los ingenieros de infraestructuras y desarrolladores que querían ampliar Kubernetes para proporcionar funciones específicas a sus sitios y software. Los Operadores facilitan a los administradores de clústeres la habilitación, y a los desarrolladores el uso, de piezas de software básicas como bases de datos y sistemas de almacenamiento con menos sobrecarga de gestión. Si el servidor de base de datos "killernewdb" que es perfecto para el backend de tu aplicación tiene un Operador para gestionarlo, puedes implementar killernewdb sin necesidad de convertirte en un experto DBA de killernewdb.

Los desarrolladores de aplicaciones crean Operadores para gestionar las aplicaciones que entregan, simplificando la experiencia de implementación y gestión en los clústeres Kubernetes de sus clientes. Los ingenieros de infraestructuras crean Operadores para controlar los servicios y sistemas desplegados.

Adopción del Operador

Una gran variedad de desarrolladores y empresas han adoptado el patrón Operador, y ya hay muchos Operadores disponibles que facilitan el uso de servicios clave como componentes de tus aplicaciones. CrunchyData ha desarrollado un Operador que gestiona clusters de bases de datos PostgreSQL. Hay Operadores populares para MongoDB y Redis. Rook gestiona el almacenamiento Ceph en clústeres Kubernetes, mientras que otros Operadores proporcionan gestión en clúster de servicios de almacenamiento externos como Amazon S3.

Además, las distribuciones basadas en Kubernetes, como OpenShift de Red Hat, utilizan Operadores para crear funciones sobre un núcleo de Kubernetes, manteniendo la consola web de OpenShift disponible y actualizada, por ejemplo. Por lo que respecta al usuario, OpenShift ha añadido mecanismos para la instalación y uso de Operadores mediante "apuntar y hacer clic" en la consola web, y para que los desarrolladores de Operadores se conecten al OperatorHub.io, del que se habla en los Capítulos 8 y 10.

¡Pongámonos en marcha!

Los operadores necesitan un clúster de Kubernetes para funcionar. En el próximo capítulo te mostraremos diferentes formas de acceder a un clúster, ya sea un Kubernetes virtual local en tu portátil, una instalación completa en un cierto número de nodos o un servicio externo. Una vez que tengas acceso de administrador a un clúster Kubernetes, desplegarás el Operador etcd y verás cómo gestiona un clúster etcd en tu nombre.