El problema de las aplicaciones con estado en Kubernetes
La configuración, el lanzamiento y una mayor ampliación de aplicaciones y servicios es fácil cuando se trata de casos clasificados como sin estado, es decir. sin guardar datos. Es conveniente ejecutar dichos servicios en Kubernetes, utilizando sus API estándar, porque todo sucede "listo para usar": de acuerdo con configuraciones estándar, sin involucrar ningún detalle o magia.
En pocas palabras, para lanzar cinco copias más del backend en PHP/Ruby/Python en un grupo de contenedores, sólo necesita configurar un nuevo servidor 5 veces y copiar las fuentes. Dado que tanto el código fuente como el script de inicio están en la imagen, escalar una aplicación sin estado se vuelve completamente elemental. Como bien saben los fanáticos de los contenedores y la arquitectura de microservicios, la dificultad comienza con aplicaciones con estado, es decir. con persistencia de datos como bases de datos y cachés (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Esto se aplica tanto al software que implementa de forma independiente un clúster de quórum (por ejemplo, Percona XtraDB y Cassandra) como al software que requiere utilidades de administración independientes (como Redis, MySQL, PostgreSQL...).
Las dificultades surgen porque el código fuente y el inicio del servicio ya no son suficientes; es necesario realizar algunos pasos más. Como mínimo, copie los datos y/o únase al clúster. Más precisamente, estos servicios requieren comprender cómo escalarlos, actualizarlos y reconfigurarlos adecuadamente sin pérdida de datos o indisponibilidad temporal. Tener en cuenta estas necesidades se denomina “conocimiento operativo”.
Operadores de CoreOS
Para "programar" el conocimiento operativo, a finales del año pasado el proyecto CoreOS "una nueva clase de software" para la plataforma Kubernetes: operadores (del inglés "operación", es decir, "operación").
Los operadores que utilizan y amplían las capacidades principales de Kubernetes (incl. Conjuntos con estado, vea la diferencia a continuación) permiten a los especialistas de DevOps agregar conocimiento operativo al código de la aplicación.
Propósito del operador — proporcionar al usuario una API que le permite administrar múltiples entidades de aplicaciones con estado en un clúster de Kubernetes, sin pensar en lo que hay debajo del capó (qué datos y qué hacer con ellos, qué comandos aún deben ejecutarse para mantener el clúster ). De hecho, el Operador está diseñado para simplificar al máximo el trabajo con la aplicación dentro del clúster, automatizando la ejecución de tareas operativas que antes debían resolverse manualmente.
Cómo trabajan los operadores
ReplicaSets Kubernetes le permite especificar la cantidad deseada de pods en ejecución y los controladores garantizan que se mantenga su número (mediante la creación y eliminación de pods). Un operador funciona de manera similar, agregando un conjunto de conocimientos operativos a un recurso y controlador estándar de Kubernetes que le permite realizar acciones adicionales para admitir la cantidad requerida de entidades de aplicación.
¿En qué se diferencia esto de Conjuntos con estado, diseñado para aplicaciones que requieren que el clúster les proporcione recursos con estado, como almacenamiento de datos o IP estáticas? Para tales aplicaciones, los operadores pueden utilizar Conjuntos con estado (en lugar de ReplicaSets) como base, ofreciendo automatización adicional: realizar las acciones necesarias en caso de fallos, realizar copias de seguridad, actualizar la configuración, etc.
Por lo tanto, ¿Cómo funciona todo esto? El operador es un demonio administrador que:
- se suscribe a la API de eventos en Kubernetes;
- recibe de él datos sobre el sistema (sobre su ReplicaSets, Vainas, Servicios etcétera.);
- recibe datos sobre Recursos de terceros (ver ejemplos a continuación);
- reacciona a la apariencia/cambio Recursos de terceros (por ejemplo, para cambiar el tamaño, cambiar la versión, etc.);
- reacciona a cambios en el estado del sistema (sobre su ReplicaSets, Vainas, Servicios etcétera.);
- lo más importante:
- llama a la API de Kubernetes para crear todo lo que necesita (nuevamente, su propio ReplicaSets, Vainas, Servicios...),
- realiza algo de magia (para simplificar, puede pensar que el Operador ingresa a los pods y llama comandos, por ejemplo, para unirse a un clúster o para actualizar el formato de datos al actualizar una versión).
De hecho, como se puede ver en la imagen, simplemente se agrega una aplicación separada a Kubernetes (una aplicación normal Despliegue с conjunto de réplicas), que se llama Operador. Vive en una manada común (generalmente solo una) y, por regla general, es responsable únicamente de su Espacio de nombres. Esta aplicación de operador implementa su API, aunque no directamente, sino a través de Recursos de terceros en Kubernetes.
Así, después de haber creado en Espacio de nombres Operador, podemos agregarle Recursos de terceros.
Ejemplo para etc. (ver más abajo para más detalles):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Ejemplo de Elasticsearch:
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Requisitos para operadores
CoreOS formuló los patrones principales obtenidos por los ingenieros mientras trabajaban en los Operadores. A pesar de que todos los Operadores son individuales (creados para una aplicación específica con características y necesidades propias), su creación debe basarse en una especie de marco que impone los siguientes requisitos:
- La instalación debe realizarse mediante un único Despliegue: kubectl crear -f SOME_OPERATOR_URL/deployment.yaml - y no requieren acciones adicionales.
- Al instalar un Operador en Kubernetes, se debe crear un nuevo tipo de tercero (Recurso de terceros). Para iniciar instancias de aplicaciones (instancias de clúster) y administrarlas aún más (actualizar versiones, cambiar el tamaño, etc.), el usuario utilizará este tipo.
- Siempre que sea posible, debe utilizar las primitivas integradas en Kubernetes, como Servicios и ReplicaSetsutilizar código bien probado y comprensible.
- Requiere compatibilidad con versiones anteriores de los operadores y soporte para versiones anteriores de recursos creados por el usuario.
- Si se elimina el Operador, la aplicación en sí debería seguir funcionando sin cambios.
- Los usuarios deberían poder definir la versión de la aplicación deseada y organizar las actualizaciones de la versión de la aplicación. La falta de actualizaciones de software es una fuente común de problemas operativos y de seguridad, por lo que los Operadores deben ayudar a los usuarios en este asunto.
- Los operadores deben ser evaluados con una herramienta como Chaos Monkey, que identifica fallas potenciales en los pods, las configuraciones y la red.
Operador etcd
Ejemplo de implementación del operador - Operador etcd, el día del anuncio de este concepto. La configuración del clúster etcd puede ser compleja debido a la necesidad de mantener el quórum, la necesidad de reconfigurar la membresía del clúster, crear copias de seguridad, etc. Por ejemplo, escalar manualmente un clúster etcd significa que debe crear un nombre DNS para un nuevo miembro del clúster, iniciar una nueva entidad etcd y alertar al clúster sobre el nuevo miembro (agregar miembro etcdctl). En el caso del Operador, el usuario sólo necesitará cambiar el tamaño del clúster; todo lo demás sucederá automáticamente.
Y dado que etcd también se creó en CoreOS, era bastante lógico ver aparecer primero a su Operador. ¿Cómo trabaja? Lógica del operador, etc. está determinada por tres componentes:
- Observar. El operador monitorea el estado del clúster utilizando la API de Kubernetes.
- Análisis. Encuentra diferencias entre el estado actual y el deseado (definido por la configuración del usuario).
- Acción. Resuelve las diferencias detectadas utilizando las API del servicio etcd y/o Kubernetes.
Para implementar esta lógica se han preparado funciones en el Operador Crear/Destruir (creación y eliminación de miembros del clúster etcd) y Cambiar el tamaño de (cambio en el número de miembros del clúster). La exactitud de su funcionamiento se comprobó utilizando una utilidad creada a imagen de Chaos Monkey de Netflix, es decir. matando vainas etcd al azar.
Para el funcionamiento completo de etcd, el Operador proporciona funciones adicionales: Backup (creación automática e invisible para los usuarios de copias de seguridad; en la configuración es suficiente determinar con qué frecuencia realizarlas y cuántas almacenar, y posterior restauración de los datos a partir de ellas) y Actualizar (actualización de instalaciones de etcd sin tiempo de inactividad).
¿Cómo es trabajar con un operador?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
El estado actual de etcd Operador es una versión beta, que requiere Kubernetes 1.5.3+ y etcd 3.0+ para ejecutarse. El código fuente y la documentación (incluidas las instrucciones de uso) están disponibles en .
Se ha creado otra implementación de ejemplo de CoreOS: , pero todavía está en la versión alfa (no se han implementado todas las funciones planificadas).
Estado y perspectivas
Han pasado 5 meses desde el anuncio de los Operadores de Kubernetes. Todavía hay sólo dos implementaciones disponibles en el repositorio oficial de CoreOS (para etcd y Prometheus). Ambos aún no han alcanzado sus versiones estables, pero se observan compromisos a diario.
Los desarrolladores visualizan "un futuro en el que los usuarios instalen operadores Postgres, operadores Cassandra u operadores Redis en sus clústeres Kubernetes y trabajen con las entidades escalables de estas aplicaciones tan fácilmente como lo es hoy implementar réplicas de aplicaciones web sin estado". Primero Operadores de desarrolladores externos realmente empezó a aparecer:
- de Empresas UPMC;
- de Crunchy Data (anunciado a finales de marzo de 2017);
- de los autores de un sistema de almacenamiento de datos distribuido basado en Ceph (Rook está en estado alfa);
- de SAP CCloud.
En la mayor conferencia europea sobre software libre, FOSDEM, que tuvo lugar en febrero de 2017 en Bruselas, Josh Wood de CoreOS anunció Operadores en (¡hay un vídeo disponible en el enlace!), lo que debería contribuir al crecimiento de la popularidad de este concepto en la comunidad de código abierto en general.
PS ¡Gracias por tu interés en el artículo! Suscríbete a nuestro centro, para no perderse nuevos materiales y recetas sobre la administración de sistemas DevOps y GNU/Linux: ¡los publicaremos periódicamente!
Fuente: habr.com