It probleem mei stateful applikaasjes yn Kubernetes
Konfiguraasje, lansearring en fierdere skaalfergrutting fan applikaasjes en tsjinsten is maklik as it giet om gefallen klassifisearre as steatleaze, d.w.s. sûnder gegevens te bewarjen. It is handich om sokke tsjinsten yn Kubernetes út te fieren, mei syn standert API's, om't alles "út 'e doaze" bart: neffens standert konfiguraasjes, sûnder spesifiken of magy te belûken.
Simply sette, om fiif mear kopyen fan 'e backend yn PHP / Ruby / Python te lansearjen yn in kluster fan konteners, moatte jo allinich in nije server 5 kear ynstelle en de boarnen kopiearje. Om't sawol de boarnekoade as it init-skript yn 'e ôfbylding binne, wurdt it skaalfergrutting fan in steatleaze applikaasje folslein elemintêr. As fans fan konteners en mikroservicearsjitektuer goed witte, begjint de muoite mei steatlike apps, d.w.s. mei gegevenspersistinsje lykas databases en caches (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra ...). Dit jildt foar sawol software dy't selsstannich in quorumcluster ymplementearret (bygelyks Percona XtraDB en Cassandra), en software dy't aparte behearprogramma's fereasket (lykas Redis, MySQL, PostgreSQL ...).
Swierrichheden ûntsteane om't de boarnekoade en it starten fan 'e tsjinst net mear genôch binne - jo moatte wat mear stappen útfiere. Kopiearje op syn minst de gegevens en / of doch mei oan it kluster. Krekter, dizze tsjinsten fereaskje in begryp fan hoe't jo se goed skaalje, bywurkje en opnij konfigurearje sûnder gegevensferlies of tydlike ûnbeskikberens. It rekkenjen fan dizze behoeften wurdt "operasjonele kennis" neamd.
CoreOS-operators
Om operasjonele kennis te "programmearjen", ein ferline jier it CoreOS-projekt "in nije klasse fan software" foar it Kubernetes-platfoarm - Operators (fan it Ingelske "operaasje", dus "operaasje").
Operators dy't de kearnmooglikheden fan Kubernetes brûke en útwreidzje (ynkl. StatefulSets, sjoch it ferskil hjirûnder) tastean DevOps-spesjalisten om operasjonele kennis ta te foegjen oan applikaasjekoade.
Doel fan de operator - biede de brûker in API wêrmei jo meardere steatlike applikaasje-entiteiten yn in Kubernetes-kluster kinne beheare, sûnder te tinken oer wat der ûnder de kap is (hokker gegevens en wat dermei te dwaan, hokker kommando's noch moatte wurde útfierd om it kluster te behâlden ). Yn feite is de Operator ûntworpen om it wurk mei de applikaasje binnen it kluster safolle mooglik te ferienfâldigjen, it automatisearjen fan de útfiering fan operasjonele taken dy't earder mei de hân oplost wurde moasten.
Hoe operators wurkje
ReplikaSets Kubernetes kinne jo opjaan it winske oantal rinnende pods, en controllers soargje dat harren oantal wurdt hanthavene (troch it meitsjen en wiskjen fan pods). In operator wurket op in fergelykbere manier, en heakket in set fan operasjonele kennis ta oan in standert Kubernetes-boarne en controller wêrmei jo ekstra aksjes kinne útfiere om it fereaske oantal applikaasje-entiteiten te stypjen.
Hoe is dit oars as StatefulSets, ûntworpen foar applikaasjes dy't it kluster fereaskje om har steatlike boarnen te leverjen lykas gegevensopslach of statyske IP's? Foar sokke applikaasjes kinne operators brûke StatefulSets (ynstee fan ReplikaSets) as basis, oanbod ekstra automatisearring: útfiere de nedige aksjes yn gefal fan crashes, meitsje backups, bywurkje de konfiguraasje, ensfh.
En sa, hoe wurket dit alles? De operator is in manager daemon dat:
- abonnearret op it evenemint API yn Kubernetes;
- ûntfangt derfan gegevens oer it systeem (oer syn ReplikaSets, pods, Tsjinsten ensafuorthinne.);
- krijt gegevens oer Tredde Partij Resources (sjoch foarbylden hjirûnder);
- reagearret op uterlik / feroaring Tredde Partij Resources (bygelyks om de grutte te feroarjen, de ferzje te feroarjen, ensfh.);
- reageart op feroaringen yn 'e steat fan it systeem (oer syn ReplikaSets, pods, Tsjinsten ensafuorthinne.);
- it wichtichste:
- ropt de Kubernetes API op om alles te meitsjen dat it nedich is (wer, syn eigen ReplikaSets, pods, Tsjinsten...),
- docht wat magy (om te ferienfâldigjen, kinne jo tinke dat de Operator giet yn 'e pods sels en ropt kommando's, bygelyks, om mei te dwaan in kluster of te upgrade it gegevensformaat by it bywurkjen fan in ferzje).
Yn feite, lykas kin sjoen wurde út de foto, in aparte applikaasje wurdt gewoan tafoege oan Kubernetes (in gewoane Deployment с ReplicaSet), dy't de Operator neamd wurdt. It libbet yn in gewoane pod (meastentiids mar ien) en is yn 'e regel allinich ferantwurdlik foar har Namespace. Dizze operatorapplikaasje ymplementearret har API - hoewol net direkt, mar troch Tredde Partij Resources yn Kubernetes.
Sa, neidat wy hawwe makke yn Namespace Operator, wy kinne it tafoegje Tredde Partij Resources.
Foarbyld foar etcd (sjoch hjirûnder foar details):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Foarbyld foar 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
Easken foar operators
CoreOS formulearre de wichtichste patroanen krigen troch yngenieurs by it wurkjen oan operators. Nettsjinsteande it feit dat alle operators yndividueel binne (makke foar in spesifike applikaasje mei har eigen skaaimerken en behoeften), moat har skepping basearre wurde op in soarte fan ramt dat de folgjende easken stelt:
- Ynstallaasje moat dien wurde troch ien Deployment: kubectl meitsje -f SOME_OPERATOR_URL/deployment.yaml - en net nedich ekstra aksjes.
- By it ynstallearjen fan in operator yn Kubernetes, moat in nij type fan tredden oanmakke wurde (ThirdPartyResource). Om applikaasje-eksimplaren (kluster-ynstânsjes) te starten en se fierder te behearjen (ferzjes bywurkje, grutte feroarje, ensfh.), sil de brûker dit type brûke.
- As it mooglik is, moatte jo de yn Kubernetes ynboude primitives brûke, lykas Tsjinsten и ReplikaSetsom goed teste en begryplike koade te brûken.
- Fereasket efterútkompatibiliteit fan operators en stipe foar âldere ferzjes fan troch brûkers oanmakke boarnen.
- As de operator is fuortsmiten, soe de applikaasje sels sûnder feroaringen moatte wurkje.
- Brûkers moatte yn steat wêze om de winske applikaasjeferzje te definiearjen en updates foar applikaasjeferzje te orkestrearjen. Gebrek oan software-updates is in mienskiplike boarne fan operasjonele en feiligensproblemen, dus operators moatte brûkers bystean yn dizze saak.
- Operators moatte wurde hifke mei in ark lykas Chaos Monkey, dat potinsjele flaters identifisearret yn pods, konfiguraasjes en it netwurk.
etcd Operator
Operator ymplemintaasje Foarbyld - etcd Operator, op de dei fan 'e oankundiging fan dit konsept. De etcd-klusterkonfiguraasje kin kompleks wêze fanwege de needsaak om it kworum te behâlden, de needsaak om klusterlidmaatskip opnij te konfigurearjen, backups te meitsjen, ensfh. Bygelyks, it manuell skaaljen fan in etcd-kluster betsjut dat jo in DNS-namme moatte oanmeitsje foar in nij klusterlid, in nije etcd-entiteit begjinne, en it kluster warskôgje oer it nije lid (etcdctl lid tafoegje). Yn it gefal fan de operator sil de brûker allinich de klustergrutte hoege te feroarjen - al it oare sil automatysk barre.
En om't etcd ek waard makke yn CoreOS, wie it frij logysk om syn Operator earst te sjen. Hoe wurket hy? Operator logika ensfh wurdt bepaald troch trije komponinten:
- Observearje. De operator kontrolearret de steat fan it kluster mei de Kubernetes API.
- Analyse. Fynt ferskillen tusken de hjoeddeistige status en de winske (definieare troch de brûkerskonfiguraasje).
- Aksje. Lost ûntdutsen ferskillen op mei de etcd- en/of Kubernetes-tsjinst-API's.
Om dizze logika út te fieren, binne funksjes taret yn 'e Operator Meitsje / ferneatigje (meitsje en wiskje etcd kluster leden) en Resize (feroaring yn it tal klusterleden). De krektens fan syn wurking waard kontrolearre mei in hulpprogramma makke yn 'e likenis fan Chaos Monkey fan Netflix, d.w.s. killing etcd pods willekeurich.
Foar folsleine wurking fan etcd biedt de operator ekstra funksjes: reservekopy (automatysk en ûnsichtber foar brûkers oanmeitsjen fan reservekopyen - yn 'e konfiguraasje is it genôch om te bepalen hoe faak se meitsje en hoefolle te bewarjen - en dêropfolgjende restauraasje fan gegevens fan har) en upgrade (update etcd ynstallaasjes sûnder downtime).
Hoe sjocht it wurkjen mei in operator der út?
$ 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
De hjoeddeistige status fan etcd Operator is in beta-ferzje, dy't Kubernetes 1.5.3+ en etcd 3.0+ fereasket om te rinnen. Boarnekoade en dokumintaasje (ynklusyf ynstruksjes foar gebrûk) binne beskikber op .
In oar foarbyld ymplemintaasje fan CoreOS is makke - , mar it is noch yn alpha ferzje (net alle plande funksjes binne ymplementearre).
Status en perspektiven
5 moannen binne ferrûn sûnt de oankundiging fan Kubernetes Operators. D'r binne noch mar twa ymplemintaasjes beskikber yn it offisjele CoreOS-repository (foar etcd en Prometheus). Beide hawwe har stabile ferzjes noch net berikt, mar commits wurde op deistige basis waarnommen.
De ûntwikkelders sjogge "in takomst wêryn brûkers Postgres Operators, Cassandra Operators of Redis Operators ynstallearje op har Kubernetes-klusters en wurkje mei de skalbere entiteiten fan dizze applikaasjes sa maklik as it ynsetten fan replika's fan steatleaze webapplikaasjes hjoed is." Earste Operators fan ûntwikkelders fan tredden echt begon te ferskinen:
- fan UPMC Enterprises;
- út Crunchy Data (oankundige ein maart 2017);
- fan de skriuwers fan in ferspraat gegevens opslach systeem basearre op Ceph (Rook is yn alpha status);
- fan SAP CCloud.
Op de grutste Jeropeeske frije softwarekonferinsje FOSDEM, dy't yn febrewaris 2017 plakfûn yn Brussel, kundige Josh Wood fan CoreOS Operators yn (in fideo is te krijen by de keppeling!), Wat moat bydrage oan de groei fan populariteit fan dit konsept yn 'e bredere Open Source-mienskip.
PS Tank foar jo belangstelling foar it artikel! Abonnearje op ús hub, om nije materialen en resepten net te missen oer DevOps en GNU/Linux systeembehear - wy sille se regelmjittich publisearje!
Boarne: www.habr.com