Problem s aplikacijama sa statusom u Kubernetesu
Konfiguracija, pokretanje i daljnje skaliranje aplikacija i usluga je jednostavno kada su u pitanju slučajevi klasificirani kao stateless, tj. bez spremanja podataka. Prikladno je pokrenuti takve usluge u Kubernetesu, koristeći njegove standardne API-je, jer se sve događa izvan okvira: prema standardnim konfiguracijama, bez uključivanja bilo kakvih specifičnosti ili magije.
Jednostavno rečeno, da biste pokrenuli još pet kopija pozadine u PHP/Ruby/Python u klasteru spremnika, trebate samo 5 puta postaviti novi poslužitelj i kopirati izvore. Budući da su i izvorni kod i init skripta na slici, skaliranje aplikacije bez statusa postaje potpuno elementarno. Kao što ljubitelji kontejnera i mikroservisne arhitekture dobro znaju, poteškoće počinju s aplikacije sa statusom, tj. s postojanošću podataka kao što su baze podataka i predmemorije (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Ovo se odnosi i na softver koji neovisno implementira klaster kvoruma (na primjer, Percona XtraDB i Cassandra), i na softver koji zahtijeva zasebne alate za upravljanje (kao što su Redis, MySQL, PostgreSQL...).
Poteškoće nastaju jer izvorni kod i pokretanje usluge više nisu dovoljni – potrebno je napraviti još neke korake. Minimalno kopirajte podatke i/ili se pridružite klasteru. Preciznije, te usluge zahtijevaju razumijevanje kako ih ispravno skalirati, ažurirati i ponovno konfigurirati bez gubitka podataka ili privremene nedostupnosti. Uzimanje u obzir ovih potreba naziva se "operativno znanje".
Operatori CoreOS
Kako bi se "programiralo" operativno znanje, krajem prošle godine projekt CoreOS “nova klasa softvera” za Kubernetes platformu - Operatori (od engleskog “operation”, tj. “operacija”).
Operatori koji koriste i proširuju osnovne mogućnosti Kubernetesa (uklj. StatefulSets, pogledajte razliku u nastavku) omogućuju DevOps stručnjacima da dodaju operativno znanje kodu aplikacije.
Svrha operatera — pružite korisniku API koji vam omogućuje upravljanje višestrukim entitetima aplikacija s statusom u Kubernetes klasteru, bez razmišljanja o tome što je ispod haube (koji podaci i što učiniti s njima, koje se naredbe još moraju izvršiti za održavanje klastera ). Zapravo, Operator je dizajniran da maksimalno pojednostavi rad s aplikacijom unutar klastera, automatizirajući izvršavanje operativnih zadataka koji su se prethodno morali rješavati ručno.
Kako operateri rade
ReplikaSetovi Kubernetes vam omogućuje da odredite željeni broj pokrenutih podova, a kontroleri osiguravaju da se njihov broj održava (izradom i brisanjem podova). Operator radi na sličan način, dodajući skup operativnog znanja standardnom Kubernetes resursu i kontroleru koji vam omogućuje izvođenje dodatnih radnji za podršku potrebnog broja aplikativnih entiteta.
Kako se ovo razlikuje od StatefulSets, dizajniran za aplikacije koje zahtijevaju da im klaster pruži resurse s praćenjem stanja kao što su pohrana podataka ili statičke IP adrese? Za takve aplikacije operateri mogu koristiti StatefulSets (umjesto ReplikaSetovi) kao osnova, ponuda dodatna automatizacija: izvršite potrebne radnje u slučaju pada, napravite sigurnosne kopije, ažurirajte konfiguraciju itd.
Dakle, kako sve ovo funkcionira? Operater je upraviteljski demon koji:
- pretplaćuje se na API događaja u Kubernetesu;
- od njega prima podatke o sustavu (o svom ReplikaSetovi, mahuna, Usluge i tako dalje.);
- prima podatke o Resursi trećih strana (vidi primjere u nastavku);
- reagira na pojavu/promjenu Resursi trećih strana (na primjer, za promjenu veličine, promjenu verzije i tako dalje);
- reagira na promjene u stanju sustava (o svom ReplikaSetovi, mahuna, Usluge i tako dalje.);
- najvažnije:
- poziva Kubernetes API da stvori sve što treba (opet, vlastito ReplikaSetovi, mahuna, Usluge...),
- izvodi neku magiju (da pojednostavimo, možete zamisliti da Operator ulazi u same module i poziva naredbe, na primjer, za pridruživanje klasteru ili za nadogradnju formata podataka prilikom ažuriranja verzije).
Zapravo, kao što se može vidjeti na slici, Kubernetesu se jednostavno dodaje zasebna aplikacija (obična razvoj с ReplicaSet), koji se naziva Operator. Živi u običnoj mahuni (obično samo jednoj) i u pravilu je odgovoran samo za svoje Prostor. Ova operaterska aplikacija implementira svoj API - iako ne izravno, već putem Resursi trećih strana u Kubernetesu.
Dakle, nakon što smo stvorili in Prostor Operater, možemo mu dodati Resursi trećih strana.
Primjer za itd (vidi dolje za detalje):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Primjer za 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
Zahtjevi za operatere
CoreOS je formulirao glavne uzorke koje su inženjeri dobili tijekom rada na Operatorima. Unatoč činjenici da su svi Operatori individualni (kreirani za specifičnu aplikaciju sa svojim karakteristikama i potrebama), njihova izrada mora se temeljiti na svojevrsnom okviru koji nameće sljedeće zahtjeve:
- Instalacija se mora izvršiti kroz jedan razvoj: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - i ne zahtijevaju dodatne radnje.
- Kada instalirate Operator u Kubernetes, mora se stvoriti novi tip treće strane (ThirdPartyResource). Za pokretanje instanci aplikacije (instance klastera) i daljnje upravljanje njima (ažuriranje verzija, promjena veličine itd.), korisnik će koristiti ovu vrstu.
- Kad god je moguće, trebali biste koristiti primitive ugrađene u Kubernetes, kao što su Usluge и ReplikaSetovikoristiti dobro testiran i razumljiv kod.
- Zahtijeva unatrag kompatibilnost operatora i podršku za starije verzije resursa koje su izradili korisnici.
- Ako se operater ukloni, sama bi aplikacija trebala nastaviti funkcionirati bez promjena.
- Korisnici bi trebali moći definirati željenu verziju aplikacije i organizirati ažuriranja verzije aplikacije. Nedostatak ažuriranja softvera čest je izvor operativnih i sigurnosnih problema, pa operateri moraju pomoći korisnicima u ovom pitanju.
- Operatere treba testirati pomoću alata kao što je Chaos Monkey, koji identificira potencijalne kvarove u modulima, konfiguracijama i mreži.
etcd operater
Primjer implementacije operatora - etcd operater, na dan objave ovog koncepta. Konfiguracija etcd klastera može biti složena zbog potrebe za održavanjem kvoruma, potrebe za rekonfiguracijom članstva u klasteru, stvaranjem sigurnosnih kopija itd. Na primjer, ručno skaliranje etcd klastera znači da morate stvoriti DNS naziv za novog člana klastera, pokrenuti novi etcd entitet i upozoriti klaster o novom članu (etcdctl član dodati). U slučaju Operatora, korisnik će samo trebati promijeniti veličinu klastera - sve ostalo će se dogoditi automatski.
A budući da je etcd također stvoren u CoreOS-u, bilo je sasvim logično da se prvi pojavi njegov Operator. Kako on radi? Operatorska logika itd određuju tri komponente:
- Promatrati. Operater prati stanje klastera koristeći Kubernetes API.
- Analiza. Pronalazi razlike između trenutnog statusa i željenog (definirano korisničkom konfiguracijom).
- Akcijski. Rješava otkrivene razlike pomoću API-ja usluge etcd i/ili Kubernetes.
Za implementaciju ove logike, u Operatoru su pripremljene funkcije Stvori/Uništi (stvaranje i brisanje etcd članova klastera) i Promjena veličine (promjena broja članova klastera). Ispravnost njegovog rada provjerena je pomoću uslužnog programa stvorenog po uzoru na Chaos Monkey iz Netflixa, tj. ubijanje etcd mahuna nasumično.
Za potpuni rad etcd-a, operater pruža dodatne značajke: rezerva (automatsko i korisnicima nevidljivo stvaranje sigurnosnih kopija - u konfiguraciji je dovoljno odrediti koliko često ih raditi i koliko pohranjivati - te naknadno vraćanje podataka iz njih) i Nadogradnja (ažuriranje etcd instalacija bez zastoja).
Kako izgleda rad s Operaterom?
$ 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
Trenutačni status etcd Operatora je beta verzija, za rad su potrebni Kubernetes 1.5.3+ i etcd 3.0+. Izvorni kod i dokumentacija (uključujući upute za uporabu) dostupni su na .
Stvoren je još jedan primjer implementacije iz CoreOS-a - , ali je još uvijek u alfa verziji (nisu implementirane sve planirane značajke).
Stanje i izgledi
Prošlo je 5 mjeseci od objave Kubernetes Operators. Još uvijek su samo dvije dostupne implementacije u službenom CoreOS repozitoriju (za etcd i Prometheus). Obje još nisu dosegle svoje stabilne verzije, ali obveze se promatraju na dnevnoj bazi.
Razvojni programeri zamišljaju "budućnost u kojoj korisnici instaliraju Postgres Operators, Cassandra Operators ili Redis Operators na svoje Kubernetes klastere i rade sa skalabilnim entitetima tih aplikacija jednako lako kao što je danas implementacija replika web aplikacija bez stanja." Prvi Operatori programera trećih strana stvarno se počelo pojavljivati:
- od UPMC Enterprises;
- iz Crunchy Data (najavljen krajem ožujka 2017.);
- od autora distribuiranog sustava za pohranu podataka temeljenog na Cephu (Rook je u alfa statusu);
- iz SAP CClouda.
Na najvećoj europskoj konferenciji o slobodnom softveru FOSDEM, koja se održala u veljači 2017. u Bruxellesu, Josh Wood iz CoreOS-a najavio je Operatore u (video je dostupan na linku!), što bi trebalo doprinijeti rastu popularnosti ovog koncepta u široj Open Source zajednici.
PS Hvala na interesu za članak! Pretplatite se na naše središte, kako ne bismo propustili nove materijale i recepte o DevOps i GNU/Linux administraciji sustava - objavljivat ćemo ih redovito!
Izvor: www.habr.com