Die probleem met statige toepassings in Kubernetes
Konfigurasie, bekendstelling en verdere skaal van toepassings en dienste is maklik wanneer dit kom by gevalle wat as staatloos geklassifiseer word, m.a.w. sonder om data te stoor. Dit is gerieflik om sulke dienste in Kubernetes uit te voer met die standaard API's, want alles gebeur "buite die boks": volgens standaardkonfigurasies, sonder om enige besonderhede of magie te betrek.
Eenvoudig gestel, om nog vyf kopieë van die backend in PHP/Ruby/Python in 'n groep houers te begin, hoef jy net 'n nuwe bediener 5 keer op te stel en die bronne te kopieer. Aangesien beide die bronne en die init-skrif in die beeld is, word die skaal van 'n staatlose toepassing heeltemal elementêr. Soos aanhangers van houers en mikrodiensargitektuur goed weet, begin die moeilikheid by statige toepassings, d.w.s. met databestendigheid soos databasisse en kas (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra ...). Dit geld vir beide sagteware wat onafhanklik 'n kworumgroepering implementeer (byvoorbeeld Percona XtraDB en Cassandra), en sagteware wat afsonderlike bestuurshulpmiddels benodig (soos Redis, MySQL, PostgreSQL...).
Probleme ontstaan omdat die bronkode en die bekendstelling van die diens nie meer genoeg is nie - jy moet nog 'n paar stappe uitvoer. Kopieer ten minste die data en/of sluit aan by die groepering. Meer presies, hierdie dienste vereis 'n begrip van hoe om dit behoorlik te skaal, op te dateer en te herkonfigureer sonder dataverlies of tydelike onbeskikbaarheid. Om hierdie behoeftes in ag te neem, word "operasionele kennis" genoem.
CoreOS-operateurs
Ten einde operasionele kennis te "programmeer", laat verlede jaar die CoreOS-projek "'n nuwe klas sagteware" vir die Kubernetes-platform - Operateurs (van die Engelse "operation", d.w.s. "operation").
Operateurs wat die kernvermoëns van Kubernetes gebruik en uitbrei (insluitend. StatefulSets, sien die verskil hieronder) laat DevOps-spesialiste toe om operasionele kennis by toepassingskode te voeg.
Operator se doel - voorsien die gebruiker van 'n API wat jou in staat stel om verskeie statige toepassingsentiteite in 'n Kubernetes-groepering te bestuur, sonder om te dink oor wat onder die kap is (watter data en wat om daarmee te doen, watter opdragte nog uitgevoer moet word om die groepie in stand te hou ). Trouens, die Operator is ontwerp om die werk met die toepassing binne die cluster soveel as moontlik te vereenvoudig, en outomatiseer die uitvoering van operasionele take wat voorheen met die hand opgelos moes word.
Hoe operateurs werk
ReplikaSets Kubernetes laat jou toe om die verlangde aantal lopende peule te spesifiseer, en beheerders verseker dat hul nommer in stand gehou word (deur peule te skep en uit te vee). 'n Operator werk op 'n soortgelyke manier en voeg 'n stel operasionele kennis by 'n standaard Kubernetes-hulpbron en -beheerder wat jou toelaat om bykomende aksies uit te voer om die vereiste aantal toepassingsentiteite te ondersteun.
Hoe is dit anders as StatefulSets, ontwerp vir toepassings wat vereis dat die groepering hulle voorsien van statige hulpbronne soos databerging of statiese IP's? Vir sulke toepassings kan operateurs gebruik StatefulSets (in plaas van ReplikaSets) as basis, offer bykomende outomatisering: voer die nodige aksies uit in geval van ineenstortings, maak rugsteun, werk die konfigurasie op, ens.
So, hoe werk dit alles? Die operateur is 'n bestuurder daemon wat:
- teken in op die gebeurtenis API in Kubernetes;
- ontvang daaruit data oor die stelsel (oor sy ReplikaSets, peule, Dienste en so aan.);
- ontvang data oor Derdepartyhulpbronne (sien voorbeelde hieronder);
- reageer op voorkoms/verandering Derdepartyhulpbronne (byvoorbeeld om die grootte te verander, die weergawe te verander, ensovoorts);
- reageer op veranderinge in die toestand van die stelsel (omtrent sy ReplikaSets, peule, Dienste en so aan.);
- die belangrikste:
- doen 'n beroep op die Kubernetes API om alles te skep wat dit nodig het (weereens sy eie ReplikaSets, peule, Dienste...),
- voer 'n bietjie magie uit (om dit te vereenvoudig, kan jy dink dat die operateur self in die peule gaan en opdragte oproep, byvoorbeeld om by 'n groep aan te sluit of om die dataformaat op te gradeer wanneer 'n weergawe opgedateer word).
Trouens, soos op die foto gesien kan word, word 'n aparte toepassing eenvoudig by Kubernetes gevoeg ('n gereelde Ontplooiing с Replika Stel), wat die Operator genoem word. Dit leef in 'n gewone peul (gewoonlik net een) en is as 'n reël slegs verantwoordelik vir sy naamruimte. Hierdie operateur-toepassing implementeer sy API - hoewel nie direk nie, maar deur Derdepartyhulpbronne in Kubernetes.
Dus, nadat ons in geskep het naamruimte Operator, ons kan daarby voeg Derdepartyhulpbronne.
Voorbeeld vir ens (sien hieronder vir besonderhede):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Voorbeeld vir 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
Vereistes vir operateurs
CoreOS het die hoofpatrone geformuleer wat deur ingenieurs verkry is terwyl hulle aan Operateurs gewerk het. Ten spyte van die feit dat alle operateurs individueel is (geskep vir 'n spesifieke toepassing met sy eie kenmerke en behoeftes), moet hul skepping gebaseer wees op 'n soort raamwerk wat die volgende vereistes stel:
- Installasie moet deur 'n enkele gedoen word Ontplooiing: kubectl skep -f SOME_OPERATOR_URL/deployment.yaml - en vereis nie bykomende aksies nie.
- Wanneer 'n operateur in Kubernetes geïnstalleer word, moet 'n nuwe derdeparty-tipe geskep word (ThirdPartyResource). Om toepassinggevalle (klustergevalle) te begin en hulle verder te bestuur (weergawes by te werk, grootte te verander, ens.), sal die gebruiker hierdie tipe gebruik.
- Waar moontlik, moet jy die primitiewe gebruik wat in Kubernetes ingebou is, soos Dienste и ReplikaSetsom goed beproefde en verstaanbare kode te gebruik.
- Vereis terugwaartse verenigbaarheid van operateurs en ondersteuning vir ouer weergawes van gebruiker-geskepte hulpbronne.
- As die operateur verwyder word, behoort die toepassing self sonder veranderinge te funksioneer.
- Gebruikers moet in staat wees om die gewenste toepassingweergawe te definieer en toepassingsweergawe-opdaterings te orkestreer. Gebrek aan sagteware-opdaterings is 'n algemene bron van bedryfs- en sekuriteitsprobleme, dus moet operateurs gebruikers in hierdie saak bystaan.
- Operateurs moet getoets word met 'n instrument soos Chaos Monkey, wat potensiële foute in peule, konfigurasies en die netwerk identifiseer.
ens Operator
Operator Implementering Voorbeeld - ens Operator, op die dag van die aankondiging van hierdie konsep. Die ets-groeperingkonfigurasie kan kompleks wees as gevolg van die behoefte om kworum te handhaaf, die behoefte om groeplidmaatskap te herkonfigureer, rugsteun te skep, ens. Om byvoorbeeld 'n ens-groep met die hand te skaal, beteken dat jy 'n DNS-naam vir 'n nuwe groeplid moet skep, 'n nuwe ensd-entiteit moet begin en die groep oor die nuwe lid (etcdctl lid byvoeg). In die geval van die operateur sal die gebruiker net die groepgrootte moet verander - alles anders sal outomaties gebeur.
En aangesien etcd ook in CoreOS geskep is, was dit redelik logies om die Operator eerste te sien verskyn. Hoe werk hy? Operator logika ens word deur drie komponente bepaal:
- Neem waar. Die operateur monitor die toestand van die groepering met behulp van die Kubernetes API.
- Ontleding. Vind verskille tussen die huidige status en die gewenste een (gedefinieer deur die gebruikerkonfigurasie).
- Aksie. Los bespeurde verskille op met behulp van die etcd en/of Kubernetes diens API's.
Om hierdie logika te implementeer, is funksies in die Operator voorberei Skep/Vernietig (skep en verwyder ensd-groeplede) en grootte (verandering in die aantal groeplede). Die korrektheid van die werking daarvan is nagegaan met behulp van 'n hulpprogram wat geskep is in die gelykenis van Chaos Monkey van Netflix, d.w.s. doodmaak ens peule lukraak.
Vir volle werking van ens, bied die operateur addisionele kenmerke: Rugsteun (outomaties en onsigbaar vir gebruikers skep van rugsteunkopieë - in die konfigurasie is dit genoeg om te bepaal hoe gereeld om dit te maak en hoeveel om te stoor - en die daaropvolgende herstel van data van hulle) en opgradering (opdatering van ens installasies sonder stilstand).
Hoe lyk dit om met 'n operateur te werk?
$ 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
Die huidige status van etcd Operator is 'n beta-weergawe, wat Kubernetes 1.5.3+ en etcd 3.0+ vereis om te loop. Bronkode en dokumentasie (insluitend gebruiksinstruksies) is beskikbaar by .
Nog 'n voorbeeldimplementering vanaf CoreOS is geskep - , maar dit is steeds in alfa-weergawe (nie alle beplande kenmerke is geïmplementeer nie).
Status en vooruitsigte
5 maande het verloop sedert die aankondiging van Kubernetes Operators. Daar is nog net twee implementerings beskikbaar in die amptelike CoreOS-bewaarplek (vir etcd en Prometheus). Albei het nog nie hul stabiele weergawes bereik nie, maar commits word daagliks waargeneem.
Die ontwikkelaars stel 'n toekoms voor waarin gebruikers Postgres Operators, Cassandra Operators of Redis Operators op hul Kubernetes-klusters installeer en so maklik met die skaalbare entiteite van hierdie toepassings werk soos die implementering van replikas van staatlose webtoepassings vandag is. Eerstens Operateurs van derdeparty-ontwikkelaars het regtig begin verskyn:
- van UPMC Enterprises;
- van Crunchy Data (aangekondig laat Maart 2017);
- van die skrywers van 'n verspreide databergingstelsel gebaseer op Ceph (Rook is in alfa-status);
- van SAP CCloud.
By die grootste Europese gratis sagteware-konferensie FOSDEM, wat in Februarie 2017 in Brussel plaasgevind het, het Josh Wood van CoreOS Operateurs in ('n video is beskikbaar by die skakel!), wat behoort by te dra tot die groei van gewildheid van hierdie konsep in die breër Oopbron-gemeenskap.
PS Dankie vir jou belangstelling in die artikel! Teken in op ons spilpunt, om nie nuwe materiaal en resepte oor DevOps en GNU/Linux-stelseladministrasie te mis nie - ons sal dit gereeld publiseer!
Bron: will.com