El problema amb les aplicacions amb estat a Kubernetes
La configuració, el llançament i l'escalat addicional d'aplicacions i serveis és fàcil quan es tracta de casos classificats com a sense estat, és a dir. sense desar dades. És convenient executar aquest tipus de serveis a Kubernetes, utilitzant les seves API estàndard, perquè tot passa "fora de la caixa": segons configuracions estàndard, sense implicar cap especificitat ni màgia.
En poques paraules, per llançar cinc còpies més del backend en PHP/Ruby/Python en un clúster de contenidors, només cal que configureu un nou servidor 5 vegades i copieu les fonts. Com que tant el codi font com l'script d'inici es troben a la imatge, escalar una aplicació sense estat esdevé completament elemental. Com saben bé els aficionats als contenidors i l'arquitectura de microserveis, la dificultat comença amb aplicacions amb estat, és a dir amb persistència de dades com bases de dades i memòria cau (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Això s'aplica tant al programari que implementa de manera independent un clúster de quòrum (per exemple, Percona XtraDB i Cassandra), com al programari que requereix utilitats de gestió separades (com Redis, MySQL, PostgreSQL...).
Les dificultats sorgeixen perquè el codi font i el llançament del servei ja no són suficients; cal fer alguns passos més. Com a mínim, copieu les dades i/o uniu-vos al clúster. Més precisament, aquests serveis requereixen una comprensió de com escalar-los, actualitzar-los i reconfigurar-los correctament sense pèrdua de dades o indisponibilitat temporal. Tenir en compte aquestes necessitats s'anomena "coneixement operacional".
Operadors CoreOS
Per tal de "programar" coneixements operatius, a finals de l'any passat el projecte CoreOS "una nova classe de programari" per a la plataforma Kubernetes - Operadors (de l'anglès "operació", és a dir, "operació").
Operadors que utilitzen i amplien les capacitats bàsiques de Kubernetes (incl. StatefulSets, vegeu la diferència a continuació) permeten als especialistes de DevOps afegir coneixements operatius al codi de l'aplicació.
Propòsit de l'operador — Proporcioneu a l'usuari una API que us permeti gestionar diverses entitats d'aplicació amb estat en un clúster de Kubernetes, sense pensar en què hi ha sota el capó (quines dades i què fer-hi, quines ordres encara s'han d'executar per mantenir el clúster). ). De fet, l'Operador està dissenyat per simplificar al màxim el treball amb l'aplicació dins del clúster, automatitzant l'execució de tasques operatives que abans s'havien de resoldre manualment.
Com treballen els operadors
Conjunts de rèpliques Kubernetes us permet especificar el nombre desitjat de pods en execució i els controladors asseguren que es mantingui el seu nombre (creant i suprimint pods). Un operador funciona de manera similar, afegint un conjunt de coneixements operatius a un recurs i un controlador estàndard de Kubernetes que us permeten realitzar accions addicionals per donar suport al nombre necessari d'entitats d'aplicació.
Com és diferent això de StatefulSets, dissenyat per a aplicacions que requereixen que el clúster els proporcioni recursos amb estat com ara emmagatzematge de dades o IP estàtiques? Per a aquestes aplicacions, els operadors poden utilitzar StatefulSets (en lloc de Conjunts de rèpliques) com a base, oferint automatització addicional: realitzar les accions necessàries en cas de fallades, fer còpies de seguretat, actualitzar la configuració, etc.
Per tant, com funciona tot això? L'operador és un dimoni gestor que:
- es subscriu a l'API d'esdeveniments a Kubernetes;
- rep d'ell dades sobre el sistema (sobre el seu Conjunts de rèpliques, Pods, Serveis etcètera.);
- rep dades sobre Recursos de tercers (vegeu exemples a continuació);
- reacciona a l'aparença/al canvi Recursos de tercers (per exemple, per canviar la mida, canviar la versió, etc.);
- reacciona als canvis en l'estat del sistema (sobre el seu Conjunts de rèpliques, Pods, Serveis etcètera.);
- el més important:
- demana a l'API de Kubernetes que creï tot el que necessita (de nou, el seu Conjunts de rèpliques, Pods, Serveis...),
- fa una mica de màgia (per simplificar, es pot pensar que l'operador entra als propis pods i crida ordres, per exemple, per unir-se a un clúster o per actualitzar el format de dades en actualitzar una versió).
De fet, com es pot veure a la imatge, simplement s'afegeix una aplicació separada a Kubernetes (una aplicació habitual Desplegament с Conjunt de rèpliques), que s'anomena Operador. Viu en una beina normal (normalment només una) i, per regla general, només és responsable de la seva Espai de noms. Aquesta aplicació d'operador implementa la seva API, encara que no directament, sinó a través Recursos de tercers a Kubernetes.
Així, després d'haver creat en Espai de noms Operador, podem afegir-hi Recursos de tercers.
Exemple per etcd (vegeu més avall per a més detalls):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Exemple per a 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
Requisits per als operadors
CoreOS va formular els principals patrons obtinguts pels enginyers mentre treballaven en Operadors. Tot i que tots els Operadors són individuals (creats per a una aplicació concreta amb característiques i necessitats pròpies), la seva creació s'ha de basar en una mena de marc que imposa els requisits següents:
- La instal·lació s'ha de fer mitjançant un únic Desplegament: kubectl crea -f SOME_OPERATOR_URL/deployment.yaml - i no requereixen accions addicionals.
- Quan instal·leu un operador a Kubernetes, s'ha de crear un nou tipus de tercers (Recurs de tercers). Per llançar instàncies d'aplicació (instàncies de clúster) i gestionar-les encara més (actualització de versions, redimensionament, etc.), l'usuari utilitzarà aquest tipus.
- Sempre que sigui possible, hauríeu d'utilitzar les primitives integrades a Kubernetes, com ara Serveis и Conjunts de rèpliquesutilitzar un codi ben provat i comprensible.
- Requereix compatibilitat enrere dels operadors i suport per a versions anteriors dels recursos creats per l'usuari.
- Si s'elimina l'operador, l'aplicació mateixa hauria de continuar funcionant sense canvis.
- Els usuaris haurien de poder definir la versió de l'aplicació desitjada i orquestrar les actualitzacions de la versió de l'aplicació. La manca d'actualitzacions de programari és una font habitual de problemes operatius i de seguretat, de manera que els operadors han d'ajudar els usuaris en aquest assumpte.
- Els operadors s'han de provar amb una eina com Chaos Monkey que identifiqui possibles errors en pods, configuracions i la xarxa.
Operador etcd
Exemple d'implementació de l'operador - Operador etcd, el dia de l'anunci d'aquest concepte. La configuració del clúster etcd pot ser complexa a causa de la necessitat de mantenir el quòrum, la necessitat de reconfigurar la pertinença al clúster, crear còpies de seguretat, etc. Per exemple, escalar manualment un clúster etcd significa que heu de crear un nom DNS per a un nou membre del clúster, iniciar una nova entitat etcd i avisar el clúster sobre el nou membre (Addició de membres etcdctl). En el cas de l'operador, l'usuari només haurà de canviar la mida del clúster; tota la resta passarà automàticament.
I com que etcd també es va crear a CoreOS, era bastant lògic veure que el seu operador aparegués primer. Com treballa? Lògica de l'operador, etcd està determinat per tres components:
- Observa. L'operador supervisa l'estat del clúster mitjançant l'API de Kubernetes.
- Anàlisi. Troba diferències entre l'estat actual i el desitjat (definit per la configuració de l'usuari).
- Acció. Resol les diferències detectades mitjançant les API de servei etcd i/o Kubernetes.
Per implementar aquesta lògica, s'han preparat funcions a l'operador Crear/Destruir (creació i eliminació de membres del clúster etcd) i Canviar la mida (canvi en el nombre de membres del clúster). La correcció del seu funcionament es va comprovar mitjançant una utilitat creada a semblança de Chaos Monkey de Netflix, és a dir. matant beines etcd aleatòriament.
Per al funcionament complet de etcd, l'operador ofereix funcions addicionals: reserva (creació automàtica i invisible per als usuaris de còpies de seguretat - a la configuració n'hi ha prou per determinar amb quina freqüència fer-les i quantes emmagatzemar - i posterior restauració de les dades d'elles) i modernització (Actualització de les instal·lacions etcd sense temps d'inactivitat).
Com és treballar amb 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
L'estat actual de l'operador etcd és una versió beta, que requereix Kubernetes 1.5.3+ i etcd 3.0+ per executar-se. El codi font i la documentació (incloses les instruccions d'ús) estan disponibles a .
S'ha creat un altre exemple d'implementació de CoreOS: , però encara està en versió alfa (no s'han implementat totes les funcions previstes).
Estat i perspectives
Han passat 5 mesos des de l'anunci dels operadors de Kubernetes. Encara hi ha només dues implementacions disponibles al dipòsit oficial de CoreOS (per a etcd i Prometheus). Tots dos encara no han arribat a les seves versions estables, però els compromisos s'observen diàriament.
Els desenvolupadors preveuen "un futur en què els usuaris instal·lin els operadors Postgres, els operadors Cassandra o els operadors Redis als seus clústers Kubernetes i treballin amb les entitats escalables d'aquestes aplicacions amb la mateixa facilitat que el desplegament de rèpliques d'aplicacions web sense estat és avui". Primer Operadors de tercers desenvolupadors realment va començar a aparèixer:
- d'UPMC Enterprises;
- de Crunchy Data (anunciat a finals de març de 2017);
- dels autors d'un sistema d'emmagatzematge de dades distribuït basat en Ceph (Rook està en estat alfa);
- de SAP CCloud.
A la conferència europea de programari lliure més gran FOSDEM, que va tenir lloc el febrer de 2017 a Brussel·les, Josh Wood de CoreOS va anunciar Operators en (hi ha un vídeo disponible a l'enllaç!), que hauria de contribuir al creixement de la popularitat d'aquest concepte a la comunitat de codi obert més àmplia.
PS Gràcies pel teu interès en l'article! Subscriu-te al nostre hub, per no perdre's nous materials i receptes sobre DevOps i administració de sistemes GNU/Linux: els publicarem regularment!
Font: www.habr.com