Problem sa aplikacijama sa stanjem u Kubernetesu
Konfiguracija, pokretanje i dalje skaliranje aplikacija i servisa je jednostavno kada su u pitanju slučajevi klasifikovani kao bez državljanstva, tj. bez čuvanja podataka. Pogodno je pokretati takve servise u Kubernetesu, koristeći njegove standardne API-je, jer se sve događa „iz kutije“: prema standardnim konfiguracijama, bez ikakvih specifičnosti ili magije.
Jednostavno rečeno, da biste pokrenuli još pet kopija backend-a u PHP/Ruby/Python-u u grupi kontejnera, trebate samo 5 puta postaviti novi server i kopirati izvore. Pošto su i izvorni kod i init skripta na slici, skaliranje aplikacije bez stanja postaje potpuno elementarno. Kao što ljubitelji kontejnera i mikroservisne arhitekture dobro znaju, poteškoće počinju s aplikacije sa stanjem, tj. sa postojanošću podataka kao što su baze podataka i keš memorije (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Ovo se odnosi i na softver koji nezavisno implementira kvorum klaster (na primjer, Percona XtraDB i Cassandra), i na softver koji zahtijeva odvojene uslužne programe za upravljanje (kao što su Redis, MySQL, PostgreSQL...).
Poteškoće nastaju jer izvorni kod i pokretanje servisa više nisu dovoljni - potrebno je izvršiti još nekoliko koraka. U najmanju ruku, kopirajte podatke i/ili se pridružite klasteru. Preciznije, ove usluge zahtijevaju razumijevanje kako ih pravilno skalirati, ažurirati i rekonfigurirati bez gubitka podataka ili privremene nedostupnosti. Uzimanje u obzir ovih potreba naziva se „operativno znanje“.
CoreOS Operatori
U cilju "programiranja" operativnog znanja, krajem prošle godine pokrenut je CoreOS projekat “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) dozvolite stručnjacima za DevOps da dodaju operativno znanje kodu aplikacije.
Svrha operatera — pružite korisniku API koji vam omogućava da upravljate višestrukim entitetima aplikacije u Kubernetes klasteru, bez razmišljanja o tome šta je ispod haube (koji podaci i šta da se radi s njima, koje komande još treba da se izvrše da bi se klaster održao ). Zapravo, Operator je dizajniran da maksimalno pojednostavi rad sa aplikacijom unutar klastera, automatizujući izvršavanje operativnih zadataka koji su se prethodno morali rešavati ručno.
Kako Operatori rade
ReplicaSets Kubernetes vam omogućava da odredite željeni broj pokrenutih podova, a kontroleri osiguravaju da se njihov broj održava (kreiranjem i brisanjem podova). Operator radi na sličan način, dodajući skup operativnog znanja standardnom Kubernetes resursu i kontroleru koji vam omogućava da izvršite dodatne radnje za podršku potrebnom broju entiteta aplikacije.
Po čemu se ovo razlikuje od StatefulSets, dizajniran za aplikacije koje zahtijevaju da im klaster obezbijedi resurse sa stanjem kao što su skladištenje podataka ili statičke IP adrese? Za takve aplikacije, Operatori mogu koristiti StatefulSets (umesto ReplicaSets) kao osnova, ponuda dodatna automatizacija: izvršite potrebne radnje u slučaju pada, napravite sigurnosne kopije, ažurirajte konfiguraciju itd.
Tako kako sve ovo funkcionira? Operator je upraviteljski demon koji:
- pretplati se na API događaja u Kubernetesu;
- prima od njega podatke o sistemu (o njegovom ReplicaSets, pods, usluge itd.);
- prima podatke o Resursi trećih strana (vidi primjere u nastavku);
- reaguje na izgled/promenu Resursi trećih strana (na primjer, da promijenite veličinu, promijenite verziju i tako dalje);
- reaguje na promjene u stanju sistema (o njegovom ReplicaSets, pods, usluge itd.);
- najvažnije:
- poziva Kubernetes API da kreira sve što mu je potrebno (opet, svoje ReplicaSets, pods, usluge...),
- izvodi neku magiju (da pojednostavimo, možete misliti da Operator ulazi u same podove i poziva komande, na primjer, za pridruživanje klasteru ili za nadogradnju formata podataka prilikom ažuriranja verzije).
Zapravo, kao što se može vidjeti sa slike, Kubernetes se jednostavno dodaje posebna aplikacija (obična razvoj с ReplicaSet), koji se naziva Operator. Živi u običnoj mahuni (obično samo jednoj) i u pravilu je odgovorna samo za svoje Prostor imena. Ova operaterska aplikacija implementira svoj API - iako ne direktno, već putem Resursi trećih strana Kubernetes.
Dakle, nakon što smo kreirali u Prostor imena Operater, možemo mu dodati Resursi trećih strana.
Primjer za etcd (pogledajte ispod 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 formulisao glavne obrasce koje su dobili inženjeri radeći na Operatorima. Uprkos činjenici da su svi Operateri individualni (kreirani za određenu aplikaciju sa svojim karakteristikama i potrebama), njihovo kreiranje mora biti zasnovano na svojevrsnom okviru koji nameće sljedeće zahtjeve:
- Instalacija se mora obaviti preko jednog razvoj: kubectl kreirati -f SOME_OPERATOR_URL/deployment.yaml - i ne zahtijevaju dodatne radnje.
- Kada instalirate Operator u Kubernetes, mora se kreirati novi tip treće strane (ThirdPartyResource). Za pokretanje instanci aplikacije (instance klastera) i dalje upravljanje njima (ažuriranje verzija, promjena veličine, itd.), korisnik će koristiti ovaj tip.
- Kad god je moguće, trebali biste koristiti primitive ugrađene u Kubernetes, kao što su usluge и ReplicaSetskoristiti dobro testiran i razumljiv kod.
- Zahtijeva kompatibilnost operatera unatrag i podršku za starije verzije resursa koje kreiraju korisnici.
- Ako se Operator ukloni, sama aplikacija bi trebala nastaviti funkcionirati bez promjena.
- Korisnici bi trebali biti u mogućnosti definirati željenu verziju aplikacije i orkestrirati ažuriranja verzije aplikacije. Nedostatak ažuriranja softvera je čest izvor operativnih i sigurnosnih problema, tako da operateri moraju pomoći korisnicima u ovom pitanju.
- Operatere treba testirati pomoću alata kao što je Chaos Monkey, koji identificira potencijalne kvarove u podovima, konfiguracijama i mreži.
etcd Operator
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, kreiranjem rezervnih kopija itd. Na primjer, ručno skaliranje etcd klastera znači da trebate kreirati DNS ime za novog člana klastera, pokrenuti novi etcd entitet i upozoriti klaster o novom članu (etcdctl član add). U slučaju Operatora, korisnik će morati samo promijeniti veličinu klastera - sve ostalo će se dogoditi automatski.
A pošto je etcd također kreiran u CoreOS-u, bilo je sasvim logično vidjeti da se njegov Operator pojavljuje prvi. Kako on radi? Operatorska logika itd određuju tri komponente:
- Posmatrajte. Operator prati stanje klastera koristeći Kubernetes API.
- Analiza. Pronalazi razlike između trenutnog statusa i željenog (definiranog konfiguracijom korisnika).
- Akcija. Rješava otkrivene razlike pomoću etcd i/ili Kubernetes servisnih API-ja.
Za implementaciju ove logike, funkcije su pripremljene u Operatoru Kreiraj/uništi (kreiranje i brisanje etcd članova klastera) i Promijenite veličinu (promjena broja članova klastera). Ispravnost njegovog rada provjerena je pomoću uslužnog programa kreiranog po uzoru na Chaos Monkey iz Netflixa, tj. ubijanje etcd mahuna nasumično.
Za potpuni rad etcd-a, Operator nudi dodatne funkcije: rezerva (automatsko i korisnicima nevidljivo kreiranje rezervnih kopija - u konfiguraciji je dovoljno odrediti koliko često ih praviti i koliko ih pohraniti - i naknadno obnavljanje podataka iz njih) i nadogradnja (ažuriranje etcd instalacija bez zastoja).
Kako izgleda rad sa Operatorom?
$ 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
Trenutni status etcd Operatora je beta verzija, koja zahtijeva Kubernetes 1.5.3+ i etcd 3.0+ za pokretanje. Izvorni kod i dokumentacija (uključujući uputstva za upotrebu) dostupni su na .
Kreiran je još jedan primjer implementacije iz CoreOS-a - , ali je još uvijek u alfa verziji (nisu implementirane sve planirane funkcije).
Status i izgledi
Prošlo je 5 mjeseci od objave Kubernetes Operatora. Još uvijek postoje samo dvije implementacije dostupne u službenom CoreOS spremištu (za etcd i Prometheus). Oba još nisu dostigla svoje stabilne verzije, ali urezivanja se prate na dnevnoj bazi.
Programeri zamišljaju “budućnost u kojoj korisnici instaliraju Postgres Operatore, Cassandra Operatore ili Redis Operatore na svoje Kubernetes klastere i rade sa skalabilnim entitetima ovih aplikacija jednako lako kao što je danas postavljanje replika web aplikacija bez stanja.” Prvo Operateri od strane programera trećih strana stvarno se počelo pojavljivati:
- od UPMC Enterprises;
- iz Crunchy Data (najavljeno krajem marta 2017.);
- od autora distribuiranog sistema za skladištenje podataka baziranog na Cephu (Rook je u alfa statusu);
- iz SAP CCloud.
Na najvećoj evropskoj konferenciji o slobodnom softveru FOSDEM, koja je održana u februaru 2017. u Briselu, Josh Wood iz CoreOS-a najavio je Operators in (video je dostupan na linku!), što bi trebalo da doprinese rastu popularnosti ovog koncepta u široj Open Source zajednici.
PS Hvala na interesovanju za članak! Pretplatite se na naš centar, kako ne biste propustili nove materijale i recepte o DevOps i GNU/Linux sistemskoj administraciji - redovno ćemo ih objavljivati!
izvor: www.habr.com