Introduction to Kubernetes operators

Kubernetes se ha convertido, por merito propio, en el gestor de contenedores por excelencia de la actualidad, en el que organizaciones de distinta índole despliegan sus aplicativos con el objetivo de sacar el mayor partido a los ya conocidos beneficios que la plataforma provee.

Este modelo funciona a las mil maravillas con aplicaciones stateless, que no requieren mantener el estado, o con aplicativos stateful que sean capaces de sobrevivir a un reinicio simplemente con la ayuda de un Persistent Volumes. Pero, ¿qué ocurre con aquellas aplicaciones de analítica, machine learning o bases de datos que puedan requerir de una lógica adicional para su inicio, backup o alta disponibilidad? Como ya habréis deducido y a menos que se quieran emplear acciones manuales, la solución pasa por el uso de los operadores.

En el presente artículo se pretende realizar una breve introducción a los operadores en Kubernetes, así como destacar sus características más importantes.

¿Que son los operadores?

Los operadores fueron concebidos como el medio para que los desarrolladores pudieran proporcionar conocimientos específicos del dominio a aquellas aplicaciones que necesitasen mantener el estado, como por ejemplo, poder rebalancear los datos en una base de datos cuando se añade un nuevo nodo al cluster.

Pero rápidamente han evolucionado hasta convertirse en las herramientas en las que encapsular toda la lógica operativa necesaria para gestionar el ciclo de vida completo de los aplicativos: Configuración, despliegue, actualización, monitorización… Entonces, ¿no se limitan únicamente a apoyar en momentos concretos a aquellas aplicaciones que necesiten mantener el estado, tal y como se sugería en la introducción? Eso es.

Toda esta magia es posible gracias a los Custom Resource Definitions (CRDs) y Custom Controllers introducidos en la versión 1.7, que permiten añadir, extender o remplazar componentes del Kubernetes.

Por lo tanto, los operadores no son más que custom controllers con acceso a la API de Kubernetes, que apoyados en los CRDs para simplificar la instalación y/o configuración, permiten encapsular la lógica operativa con la que gestionar el ciclo de vida de las aplicaciones.

Operator Capability Level

Los operadores se clasifican en distintos niveles en función de las tareas que puedan llevar a cabo.

Phase 1: Basic Install

Se categoriza un operador como “Phase 1” cuando su cometido se limita a automatizar la configuración e instalación de la aplicación, como por ejemplo, el operador de grafana.

Gracias a los CRDs, el operador define objetos personalizados de Kubernetes en lo que especificar los parámetros de instalación y configuración del aplicativo.

En el caso de Grafana, el operador crea un CRD denominado “Grafana”, con el que el usuario puede definir las propiedades de seguridad, autenticación o nivel de trazas entre otros de forma simple y limpia.

apiVersion: integreatly.org/v1alpha1
kind: Grafana
metadata:
  name: example-grafanael 
spec:
  config:
    auth:
      disable_signout_menu: true
    auth.anonymous:
      enabled: true
    log:
      level: warn
      mode: console
    security:
      admin_password: secret
      admin_user: root
  dashboardLabelSelector:
    - matchExpressions:
        - key: app
          operator: In
          values:
            - grafana

Además, al tratarse de un fichero yaml, es posible almacenarlo en un repositorio GIT e incluirlo dentro del ciclo de CI/CD de la compañía.

Phase 2: Seamless Upgrades

Se categoriza un operador como “Phase 2” cuando también es capaz de actualizar las versiones minor y path de la aplicación, sin requerir de cambios en la configuración.

Un fantástico ejemplo de ello es el operador de istio de Banzai Cloud, con el que, tal y como relatan en su blog, es posible actualizar la versión Istio en dos sencillos pasos.

Desplegar una versión del operador que soporte la versión de istio a actualizar.
Definir en el Custom Resource de istio la nueva versión a la que actualizar.

Posteriormente el operador se encarga de actualizar de forma transparente los distintos componentes que conforman istio.

Phase 3: Full Lifecycle

Se categoriza un operador como “Phase 3” cuando, además de lo visto anteriormente, es capaz de ejecutar acciones asociadas a la lógica operativa de la aplicación en las situaciones que así lo requieran.

El ya clásico ejemplo de la base de datos entra en escena de la mano del operador de couchbase. Así de bien describen en su blog la gente de couchbase el comportamiento del operador cuando uno de los pods muere:

Cuando un pod muere, el operador compara el numero de instancias actual con el estado deseado. Al no coincidir, el operador solicita a la API de Kubernetes la creación de un nuevo pod, pero además lo añade al cluster de Couchbase y solicita un rebalanceo de los datos, algo que Kubernetes por sí solo no es capaz de efectuar. Esta es sin lugar a dudas, una de las características clave de los operadores.

Phase 4: Deep Insights

Se categoriza un operador como “Phase 4” cuando, además de lo visto anteriormente, es capaz de monitorizar la aplicación, permitiendo visualizar las métricas o logs mediante un dashboard o establecer alertas en base a los valores recogidos.

En el momento de escribir este artículo tan solo 3 operadores incorporan esta funcionalidad, según OperatorHub.

Phase 5: Auto Pilot

Se categoriza un operador como “Phase 5” cuando, además de lo visto anteriormente, es capaz de auto configurarse en función de la situación en la que se encuentra. Es decir, debe ser capaz de escalar vertical/horizontalmente, detectar anomalías en el funcionamiento y subsanarlas, “tunnear” la configuración de la aplicación de forma transparente…

En el momento de escribir este artículo tan solo el operador de Federator.ai logra esta calificación, lo cual indica la complejidad que requiere llevarlo a cabo.

Conclusiones

En conclusión y una vez listadas las posibilidades que los operadores pueden llegar ofrecer, todo hace indicar que están destinados a convertirse en el estándar para la instalación, configuración y gestión de aplicaciones complejas sobre Kubernetes.

A día de hoy la cantidad de operadores existentes es bastante limitada y la gran mayoría se encuentran en un estado de desarrollo temprano, pero aun así recomiendo encarecidamente estudiar cada caso antes de descartar su uso (Operatorhub será vuestro mejor aliado para ello).

A nivel personal, la experiencia con los operadores de Istio o Elastic Cloud ha sido francamente buena, facilitándome mucho todo el trabajo de instalación y configuración, sin llegar a perder la flexibilidad de una instalación manual. Con otros productos en cambio la experiencia ha sido menos satisfactoria, que no mala, principalmente por su temprano estado de desarrollo y su falta de documentación (En estos casos, la issues de GitHub serán vuestro mejor aliado).

Referencias

Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:

Introduction to Kubernetes operators

¿Que son los operadores?