O problema coas aplicacións con estado en Kubernetes
A configuración, o lanzamento e unha maior escala de aplicacións e servizos é fácil cando se trata de casos clasificados como sen estado, é dicir. sen gardar datos. É conveniente executar tales servizos en Kubernetes, utilizando as súas API estándar, porque todo ocorre "fóra da caixa": segundo configuracións estándar, sen implicar ningún detalle ou maxia.
Simplemente, para lanzar cinco copias máis do backend en PHP/Ruby/Python nun clúster de contedores, só precisa configurar un novo servidor 5 veces e copiar as fontes. Dado que tanto o código fonte como o script de inicio están na imaxe, escalar unha aplicación sen estado tórnase completamente elemental. Como saben ben os fans dos contedores e da arquitectura de microservizos, a dificultade comeza por aplicacións con estado, é dicir. con persistencia de datos como bases de datos e cachés (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Isto aplícase tanto ao software que implementa de forma independente un clúster de quórum (por exemplo, Percona XtraDB e Cassandra), como ao software que require utilidades de xestión separadas (como Redis, MySQL, PostgreSQL...).
As dificultades xorden porque o código fonte e o lanzamento do servizo xa non son suficientes; cómpre realizar algúns pasos máis. Como mínimo, copia os datos e/ou únete ao clúster. Máis precisamente, estes servizos requiren unha comprensión de como escalalos, actualizalos e reconfiguralos correctamente sen perda de datos nin indisponibilidade temporal. Ao ter en conta estas necesidades denomínase "coñecemento operativo".
Operadores CoreOS
Co fin de "programar" coñecementos operativos, a finais do ano pasado o proxecto CoreOS "unha nova clase de software" para a plataforma Kubernetes - Operadores (do inglés "operación", é dicir, "operación").
Operadores que utilizan e estenden as capacidades básicas de Kubernetes (incl. StatefulSets, vexa a diferenza a continuación) permite aos especialistas de DevOps engadir coñecementos operativos ao código da aplicación.
Finalidade do operador — proporcionar ao usuario unha API que lle permite xestionar varias entidades de aplicacións con estado nun clúster de Kubernetes, sen pensar no que hai baixo o capó (que datos e que facer con eles, que comandos aínda hai que executar para manter o clúster). ). De feito, o Operador está pensado para simplificar ao máximo o traballo coa aplicación dentro do clúster, automatizando a execución de tarefas operativas que antes había que resolver manualmente.
Como traballan os operadores
Conxuntos de réplicas Kubernetes permítelle especificar o número desexado de pods en execución e os controladores garanten que o seu número se manteña (creando e eliminando pods). Un operador funciona dun xeito similar, engadindo un conxunto de coñecementos operativos a un recurso e controlador estándar de Kubernetes que lle permite realizar accións adicionais para admitir o número necesario de entidades da aplicación.
Como é iso diferente de StatefulSets, deseñado para aplicacións que requiren que o clúster lles proporcione recursos con estado como almacenamento de datos ou IPs estáticas? Para tales aplicacións, os operadores poden usar StatefulSets (no seu lugar Conxuntos de réplicas) como base, oferta automatización adicional: realizar as accións necesarias en caso de fallos, facer copias de seguridade, actualizar a configuración, etc.
Así, como funciona todo isto? O operador é un daemon xestor que:
- subscríbese á API do evento en Kubernetes;
- recibe del datos sobre o sistema (sobre o seu Conxuntos de réplicas, vagens, servizos etcétera.);
- recibe datos sobre Recursos de terceiros (ver exemplos a continuación);
- reacciona á aparencia/cambio Recursos de terceiros (por exemplo, para cambiar o tamaño, cambiar a versión, etc.);
- reacciona aos cambios no estado do sistema (sobre o seu Conxuntos de réplicas, vagens, servizos etcétera.);
- o máis importante:
- pide á API de Kubernetes que cree todo o que necesita (de novo, o seu Conxuntos de réplicas, vagens, servizos...),
- realiza algo de maxia (para simplificar, pódese pensar que o Operador entra nas propias vainas e chama comandos, por exemplo, para unirse a un clúster ou para actualizar o formato de datos ao actualizar unha versión).
De feito, como se pode ver na imaxe, simplemente engádese unha aplicación separada a Kubernetes (unha aplicación habitual desenvolvemento с Conxunto de réplicas), que se chama Operador. Vive nunha vaina común (xeralmente só unha) e, por regra xeral, só é responsable da súa Espazo de nomes. Esta aplicación de operador implementa a súa API, aínda que non directamente, senón a través Recursos de terceiros en Kubernetes.
Así, despois de que creamos en Espazo de nomes Operador, podemos engadirlle Recursos de terceiros.
Exemplo para etcd (ver máis abaixo para máis detalles):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Exemplo para 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 dos operadores
CoreOS formulou os principais patróns obtidos polos enxeñeiros mentres traballaban en Operadores. A pesar de que todos os Operadores son individuais (creados para unha aplicación específica con características e necesidades propias), a súa creación debe basearse nunha especie de marco que impoña os seguintes requisitos:
- A instalación debe realizarse a través dun único desenvolvemento: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - e non requiren accións adicionais.
- Ao instalar un operador en Kubernetes, debe crearse un novo tipo de terceiros (Recurso de terceiros). Para lanzar instancias de aplicación (instancias de clúster) e xestionalas aínda máis (actualización de versións, redimensionamento, etc.), o usuario utilizará este tipo.
- Sempre que sexa posible, deberías usar as primitivas integradas en Kubernetes, como servizos и Conxuntos de réplicasutilizar un código ben probado e comprensible.
- Require compatibilidade con versións anteriores dos operadores e soporte para versións antigas dos recursos creados polo usuario.
- Se se elimina o operador, a propia aplicación debería seguir funcionando sen cambios.
- Os usuarios deberían poder definir a versión da aplicación desexada e organizar as actualizacións da versión da aplicación. A falta de actualizacións de software é unha fonte común de problemas operativos e de seguridade, polo que os operadores deben axudar aos usuarios neste asunto.
- Os operadores deberían ser probados cunha ferramenta como Chaos Monkey, que identifica posibles fallos en pods, configuracións e rede.
Operador etcd
Exemplo de implementación do operador - Operador etcd, o día do anuncio deste concepto. A configuración do clúster de etcd pode ser complexa debido á necesidade de manter o quórum, á necesidade de reconfigurar a pertenza ao clúster, crear copias de seguridade, etc. Por exemplo, escalar manualmente un clúster etcd significa que cómpre crear un nome DNS para un novo membro do clúster, iniciar unha nova entidade etcd e avisar o clúster sobre o novo membro (Engadir membro etcdctl). No caso do Operador, o usuario só terá que cambiar o tamaño do clúster; todo o demais ocorrerá automaticamente.
E como etcd tamén se creou en CoreOS, era bastante lóxico ver o seu operador aparecer primeiro. Como traballa? Lóxica do operador etcd está determinada por tres compoñentes:
- Observa. O operador supervisa o estado do clúster mediante a API de Kubernetes.
- Análise. Busca diferenzas entre o estado actual e o desexado (definido pola configuración do usuario).
- Acción. Resolve as diferenzas detectadas mediante as API do servizo etcd e/ou Kubernetes.
Para implementar esta lóxica, preparáronse funcións no Operador Crear/Destruír (creando e eliminando membros do clúster etcd) e Redimensionar (cambio no número de membros do cluster). A corrección do seu funcionamento comprobouse mediante unha utilidade creada a semellanza de Chaos Monkey de Netflix, é dicir. matando pods etcd aleatoriamente.
Para o funcionamento completo de etcd, o operador ofrece funcións adicionais: Backup (creación automática e invisible para os usuarios de copias de seguridade -na configuración é suficiente para determinar cantas veces hai que facer e cantas almacenar - e a posterior restauración dos datos delas) e Mellorar (actualizando instalacións etcd sen tempo de inactividade).
Como é traballar cun 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
O estado actual de etcd Operator é unha versión beta, que require Kubernetes 1.5.3+ e etcd 3.0+ para executarse. O código fonte e a documentación (incluídas as instrucións de uso) están dispoñibles en .
Creouse outro exemplo de implementación de CoreOS: , pero aínda está en versión alfa (non se implementaron todas as funcións previstas).
Estado e perspectivas
Pasaron 5 meses desde o anuncio de Operadores de Kubernetes. Aínda hai só dúas implementacións dispoñibles no repositorio oficial de CoreOS (para etcd e Prometheus). Ambos aínda non chegaron ás súas versións estables, pero os compromisos obsérvanse a diario.
Os desenvolvedores prevén "un futuro no que os usuarios instalen Operadores Postgres, Operadores Cassandra ou Operadores Redis nos seus clústeres de Kubernetes e traballen coas entidades escalables destas aplicacións tan facilmente como é hoxe a implantación de réplicas de aplicacións web sen estado". Primeira Operadores de desenvolvedores terceiros realmente comezou a aparecer:
- de UPMC Enterprises;
- de Crunchy Data (anunciado a finais de marzo de 2017);
- dos autores dun sistema de almacenamento de datos distribuído baseado en Ceph (Rook está en estado alfa);
- desde SAP CCloud.
Na maior conferencia europea de software libre FOSDEM, que tivo lugar en febreiro de 2017 en Bruxelas, Josh Wood de CoreOS anunciou Operators in (¡Hai un vídeo dispoñible na ligazón!), o que debería contribuír ao crecemento da popularidade deste concepto na comunidade de código aberto máis ampla.
PS Grazas polo teu interese no artigo! Subscríbete ao noso hub, para non perder novos materiais e receitas sobre DevOps e administración do sistema GNU/Linux - publicarémolos regularmente!
Fonte: www.habr.com