Operatori pentru Kubernetes: cum să rulați aplicații cu stare

Problema cu aplicațiile stateful din Kubernetes

Configurarea, lansarea și scalarea ulterioară a aplicațiilor și serviciilor este ușoară atunci când vine vorba de cazurile clasificate ca apatride, de exemplu. fără salvarea datelor. Este convenabil să rulați astfel de servicii în Kubernetes, folosind API-urile sale standard, deoarece totul se întâmplă „din cutie”: conform configurațiilor standard, fără a implica niciun fel de specific sau magie.

Mai simplu spus, pentru a lansa încă cinci copii ale backend-ului în PHP/Ruby/Python într-un cluster de containere, trebuie doar să configurați un nou server de 5 ori și să copiați sursele. Deoarece atât codul sursă, cât și scriptul init sunt în imagine, scalarea unei aplicații fără stat devine complet elementară. După cum știu bine fanii containerelor și arhitecturii microservicii, dificultatea începe cu aplicații cu stare, adică cu persistență de date precum baze de date și cache (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Acest lucru se aplică atât software-ului care implementează în mod independent un cluster de cvorum (de exemplu, Percona XtraDB și Cassandra), cât și software-ului care necesită utilități de management separate (cum ar fi Redis, MySQL, PostgreSQL...).

Apar dificultăți deoarece codul sursă și lansarea serviciului nu mai sunt suficiente - trebuie să mai efectuați câțiva pași. Copiați cel puțin datele și/sau alăturați-vă clusterului. Mai precis, aceste servicii necesită o înțelegere a modului de scalare, actualizare și reconfigurare corectă a acestora fără pierderi de date sau indisponibilitate temporară. Luarea în considerare a acestor nevoi se numește „cunoștințe operaționale”.

Operatori CoreOS

Pentru a „programa” cunoștințe operaționale, la sfârșitul anului trecut, proiectul CoreOS a prezentat „o nouă clasă de software” pentru platforma Kubernetes - Operatori (din engleză „operare”, adică „operare”).

Operatorii care folosesc și extind capacitățile de bază ale Kubernetes (incl. StatefulSets, vezi diferența de mai jos) permit specialiștilor DevOps să adauge cunoștințe operaționale codului aplicației.

Scopul operatorului — oferiți utilizatorului un API care vă permite să gestionați mai multe entități de aplicație cu stare într-un cluster Kubernetes, fără să vă gândiți la ce se află sub capotă (ce date și ce să faceți cu acestea, ce comenzi mai trebuie să fie executate pentru a menține clusterul) ). De fapt, Operatorul este conceput să simplifice cât mai mult lucrul cu aplicația din cluster, automatizând executarea sarcinilor operaționale care anterior trebuiau rezolvate manual.

Cum lucrează operatorii

ReplicaSets Kubernetes vă permite să specificați numărul dorit de poduri care rulează, iar controlerele se asigură că numărul acestora este menținut (prin crearea și ștergerea podurilor). Un Operator funcționează într-un mod similar, adăugând un set de cunoștințe operaționale la o resursă standard Kubernetes și un controler care vă permite să efectuați acțiuni suplimentare pentru a susține numărul necesar de entități de aplicație.

Cum este aceasta diferită de StatefulSets, conceput pentru aplicații care necesită cluster-ul să le furnizeze resurse de stat, cum ar fi stocarea de date sau IP-uri statice? Pentru astfel de aplicații, Operatorii pot folosi StatefulSets (în loc de ReplicaSets) ca bază, ofertă automatizare suplimentară: efectuați acțiunile necesare în caz de blocare, faceți copii de siguranță, actualizați configurația etc.

Astfel, cum funcționează toate astea? Operatorul este un daemon manager care:

1. se abonează la evenimentul API în Kubernetes;
2. primește de la acesta date despre sistem (despre acesta ReplicaSets, pods, Servicii și așa mai departe.);
3. primește date despre Resurse ale terților (vezi exemplele de mai jos);
4. reacționează la aspect/schimbare Resurse ale terților (de exemplu, pentru a schimba dimensiunea, a schimba versiunea și așa mai departe);
5. reacționează la modificările stării sistemului (despre acesta ReplicaSets, pods, Servicii și așa mai departe.);
6. cel mai important:
   1. solicită API-ul Kubernetes să creeze tot ce are nevoie (din nou, propriul său ReplicaSets, pods, Servicii...),
   2. efectuează ceva magie (pentru a simplifica, puteți crede că Operatorul intră în pod-uri și apelează comenzi, de exemplu, pentru a se alătura unui cluster sau pentru a actualiza formatul de date atunci când actualizați o versiune).

De fapt, așa cum se poate vedea din imagine, o aplicație separată este pur și simplu adăugată la Kubernetes (o aplicație obișnuită Implementare с ReplicaSet), care se numește Operator. Trăiește într-o păstă obișnuită (de obicei doar una) și, de regulă, este responsabilă doar pentru ea Spațiu de nume. Această aplicație de operator își implementează API-ul - deși nu direct, ci prin intermediul Resurse ale terților în Kubernetes.

Astfel, după ce am creat în Spațiu de nume Operator, putem adăuga la asta Resurse ale terților.

Exemplu pentru etcd (vezi mai jos pentru detalii):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

Exemplu pentru 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

Cerințe pentru operatori

CoreOS a formulat principalele modele obținute de ingineri în timp ce lucra pe Operatori. În ciuda faptului că toți Operatorii sunt individuali (creați pentru o aplicație specifică cu propriile caracteristici și nevoi), crearea lor trebuie să se bazeze pe un fel de cadru care impune următoarele cerințe:

1. Instalarea trebuie făcută printr-un singur Implementare: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - și nu necesită acțiuni suplimentare.
2. Când instalați un operator în Kubernetes, trebuie creat un nou tip terță parte (ThirdPartyResource). Pentru a lansa instanțe de aplicație (instanțele cluster) și a le gestiona în continuare (actualizarea versiunilor, redimensionarea etc.), utilizatorul va folosi acest tip.
3. Ori de câte ori este posibil, ar trebui să utilizați primitivele încorporate în Kubernetes, cum ar fi Servicii и ReplicaSetssă folosească cod bine testat și ușor de înțeles.
4. Necesită compatibilitatea anterioară a operatorilor și suport pentru versiunile mai vechi ale resurselor create de utilizator.
5. Dacă Operatorul este eliminat, aplicația în sine ar trebui să continue să funcționeze fără modificări.
6. Utilizatorii ar trebui să poată defini versiunea dorită a aplicației și să orchestreze actualizările versiunii aplicației. Lipsa actualizărilor software este o sursă comună de probleme operaționale și de securitate, așa că Operatorii trebuie să asiste utilizatorii în această problemă.
7. Operatorii ar trebui testați cu un instrument precum Chaos Monkey, care identifică potențiale defecțiuni în pod-uri, configurații și rețea.

etcd Operator

Exemplu de implementare a operatorului - operator etcd, pregătit în ziua anunţării acestui concept. Configurația clusterului etcd poate fi complexă din cauza necesității de a menține cvorumul, necesitatea de a reconfigura apartenența la cluster, de a crea copii de rezervă etc. De exemplu, scalarea manuală a unui cluster etcd înseamnă că trebuie să creați un nume DNS pentru un nou membru al clusterului, să începeți o nouă entitate etcd și să alertați clusterul despre noul membru (etcdctl membru add). În cazul Operatorului, utilizatorul va trebui doar să modifice dimensiunea clusterului - totul se va întâmpla automat.

Și din moment ce etcd a fost creat și în CoreOS, era destul de logic să-i vezi operatorul să apară primul. Cum lucrează? Logica operatorului etcd este determinat de trei componente:

1. Observa. Operatorul monitorizează starea cluster-ului folosind API-ul Kubernetes.
2. Analiză. Găsește diferențe între starea curentă și cea dorită (definită de configurația utilizatorului).
3. Acțiune. Rezolvă diferențele detectate folosind etcd și/sau API-urile de serviciu Kubernetes.

Pentru a implementa această logică, în Operator au fost pregătite funcții Creați/Distrugeți (crearea și ștergerea membrilor cluster etcd) și Redimensionarea (modificarea numărului de membri ai clusterului). Corectitudinea funcționării sale a fost verificată folosind un utilitar creat după asemănarea Chaos Monkey de la Netflix, adică. uciderea păstăilor etcd aleatoriu.

Pentru funcționarea completă a etcd, Operatorul oferă caracteristici suplimentare: Backup (crearea automată și invizibilă pentru utilizatori de copii de rezervă - în configurație este suficient să se determine cât de des să le facă și câte să stocheze - și restaurarea ulterioară a datelor din ele) și Actualizare (actualizarea instalațiilor etcd fără timp de nefuncționare).

Cum arată lucrul cu un Operator?

$ 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

Starea actuală a operatorului etcd este o versiune beta, care necesită Kubernetes 1.5.3+ și etcd 3.0+ pentru a rula. Codul sursă și documentația (inclusiv instrucțiunile de utilizare) sunt disponibile la GitHub.

Un alt exemplu de implementare de la CoreOS a fost creat - Operator Prometheus, dar este încă în versiune alfa (nu toate caracteristicile planificate au fost implementate).

Starea și perspectivele

Au trecut 5 luni de la anunțul Operatorilor Kubernetes. Există încă doar două implementări disponibile în depozitul oficial CoreOS (pentru etcd și Prometheus). Ambele nu au ajuns încă la versiunile lor stabile, dar commit-urile sunt observate zilnic.

Dezvoltatorii își imaginează „un viitor în care utilizatorii instalează Operatori Postgres, Operatori Cassandra sau Operatori Redis pe clusterele lor Kubernetes și lucrează cu entitățile scalabile ale acestor aplicații la fel de ușor ca implementarea replicilor aplicațiilor web fără stat.” Primul Operatori de la dezvoltatori terți chiar a inceput sa apara:

• Operator Elasticsearch de la UPMC Enterprises;
• Operator PostgreSQL de la Crunchy Data (anunțat la sfârșitul lunii martie 2017);
• Rook Operator de la autorii unui sistem distribuit de stocare a datelor bazat pe Ceph (Rook este în stare alfa);
• Operatori Openstack de la SAP CCloud.

La cea mai mare conferință europeană de software liber FOSDEM, care a avut loc în februarie 2017 la Bruxelles, Josh Wood de la CoreOS a anunțat Operatorii în raport (un videoclip este disponibil la link!), care ar trebui să contribuie la creșterea popularității acestui concept în comunitatea Open Source mai largă.

PS Vă mulțumim pentru interesul acordat articolului! Abonați-vă la hub-ul nostru, pentru a nu rata noi materiale și rețete despre DevOps și administrarea sistemului GNU/Linux - le vom publica în mod regulat!

Sursa: www.habr.com