Probleem olekuga rakendustega Kubernetesis
Rakenduste ja teenuste konfigureerimine, käivitamine ja edasine skaleerimine on lihtne, kui tegemist on kodakondsuseta liigitatud juhtumitega, s.t. andmeid salvestamata. Selliseid teenuseid on mugav käivitada Kubernetes, kasutades selle standardseid API-sid, sest kõik toimub "kastist väljas": vastavalt standardsetele konfiguratsioonidele, ilma spetsiifikat või maagiat kaasamata.
Lihtsamalt öeldes, et käivitada veel viis PHP/Ruby/Pythoni taustprogrammi koopiat konteinerite klastris, peate uue serveri seadistama vaid viis korda ja kopeerima allikad. Kuna pildil on nii lähtekood kui ka init-skript, muutub olekuta rakenduse skaleerimine täiesti elementaarseks. Nagu konteinerite ja mikroteenuste arhitektuuri fännid hästi teavad, saavad raskused alguse olekupõhised rakendused, st. andmete püsivusega, nagu andmebaasid ja vahemälud (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). See kehtib nii tarkvara kohta, mis juurutab iseseisvalt kvoorumiklastri (näiteks Percona XtraDB ja Cassandra), kui ka tarkvara kohta, mis nõuab eraldi haldusutiliite (nt Redis, MySQL, PostgreSQL...).
Raskused tekivad seetõttu, et lähtekoodist ja teenuse käivitamisest enam ei piisa – tuleb teha veel mõned sammud. Vähemalt kopeerige andmed ja/või liituge klastriga. Täpsemalt nõuavad need teenused arusaamist, kuidas neid õigesti skaleerida, värskendada ja ümber konfigureerida ilma andmete kadumise või ajutise kättesaamatuseta. Nende vajadustega arvestamist nimetatakse tegevusteadmisteks.
CoreOS-i operaatorid
Operatiivteadmiste "programmeerimiseks" eelmise aasta lõpus CoreOS-i projekt “uus tarkvaraklass” Kubernetese platvormile – operaatorid (inglise keelest “operation”, st “operation”).
Operaatorid, kes kasutavad ja laiendavad Kubernetese põhivõimalusi (sh. StatefulSets, vaadake allpool olevat erinevust) võimaldavad DevOpsi spetsialistidel lisada rakenduse koodile operatiivteadmisi.
Operaatori eesmärk — pakkuda kasutajale API, mis võimaldab hallata mitut olekuga rakenduse olemit Kubernetese klastris, mõtlemata sellele, mis on katte all (millised andmed ja mida nendega teha, milliseid käske tuleb klastri hooldamiseks veel täita ). Tegelikult on Operaator loodud selleks, et lihtsustada võimalikult palju tööd klastrisisese rakendusega, automatiseerides varem käsitsi lahendatud tööülesannete täitmist.
Kuidas operaatorid töötavad
ReplicaSets Kubernetes võimaldab määrata soovitud arvu töötavaid kassasid ja kontrollerid tagavad nende arvu säilimise (luues ja kustutades). Operaator töötab sarnaselt, lisades tavapärasele Kubernetese ressursile ja kontrollerile tööalaste teadmiste kogumi, mis võimaldab teil teha täiendavaid toiminguid vajaliku arvu rakendusüksuste toetamiseks.
Mille poolest see erineb StatefulSets, mis on mõeldud rakenduste jaoks, mis nõuavad, et klaster annaks neile olekupõhiseid ressursse, nagu andmesalvestus või staatilised IP-d? Selliste rakenduste jaoks saavad operaatorid kasutada StatefulSets (asemel ReplicaSets) aluseks, pakkumine täiendav automatiseerimine: tehke krahhide korral vajalikke toiminguid, tehke varukoopiaid, värskendage konfiguratsiooni jne.
Niisiis, kuidas see kõik töötab? Operaator on haldurdeemon, mis:
- tellib Kubernetesis ürituse API;
- saab sellelt andmeid süsteemi kohta (selle kohta ReplicaSets, Podid, Teenused ja nii edasi.);
- kohta saab andmeid Kolmanda osapoole ressursid (vt näiteid allpool);
- reageerib välimusele/muutusele Kolmanda osapoole ressursid (näiteks suuruse muutmiseks, versiooni muutmiseks jne);
- reageerib muutustele süsteemi olekus (selle kohta ReplicaSets, Podid, Teenused ja nii edasi.);
- kõige tähtsam:
- kutsub Kubernetes API-d üles looma kõike, mida ta vajab (jällegi oma ReplicaSets, Podid, Teenused...),
- teeb maagiat (lihtsustamiseks võib arvata, et Operaator läheb ise kaustadesse ja kutsub välja käsklusi, näiteks klastriga liitumiseks või versiooni värskendamisel andmevormingu uuendamiseks).
Tegelikult, nagu pildilt näha, lisatakse Kubernetesesse lihtsalt eraldi rakendus (tavaline Deployment с ReplicaSet), mida nimetatakse operaatoriks. Ta elab tavalises kaunas (tavaliselt ainult ühes) ja vastutab reeglina ainult selle eest Nimeruum. See operaatorirakendus rakendab oma API-d – kuigi mitte otse, vaid läbi Kolmanda osapoole ressursid Kubernetesis.
Seega, pärast seda, kui oleme loonud Nimeruum Operaator, saame selle lisada Kolmanda osapoole ressursid.
Näide jne (üksikasju vaata altpoolt):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Elasticsearchi näide:
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
Nõuded operaatoritele
CoreOS sõnastas peamised mustrid, mille insenerid said operaatoritega töötades. Hoolimata asjaolust, et kõik operaatorid on individuaalsed (loodud konkreetse rakenduse jaoks, millel on oma omadused ja vajadused), peab nende loomine põhinema teatud tüüpi raamistikul, mis seab järgmised nõuded:
- Paigaldamine tuleb teha läbi ühe Deployment: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - ja ei nõua lisatoiminguid.
- Operatori installimisel Kubernetesesse tuleb luua uus kolmanda osapoole tüüp (Kolmanda osapoole ressurss). Rakenduse eksemplaride (klastri eksemplarid) käivitamiseks ja nende edasiseks haldamiseks (versioonide värskendamine, suuruse muutmine jne) kasutab kasutaja seda tüüpi.
- Kui vähegi võimalik, tuleks kasutada Kubernetesesse sisseehitatud primitiive, nt Teenused и ReplicaSetskasutada hästi testitud ja arusaadavat koodi.
- Nõuab operaatorite tagasiühilduvust ja kasutaja loodud ressursside vanemate versioonide tuge.
- Kui operaator eemaldatakse, peaks rakendus ise ilma muudatusteta töötama.
- Kasutajad peaksid saama määrata soovitud rakenduse versiooni ja korraldada rakenduse versiooni värskendusi. Tarkvaravärskenduste puudumine on tavaline töö- ja turvaprobleemide allikas, mistõttu peavad operaatorid kasutajaid selles küsimuses abistama.
- Operaatoreid tuleks testida sellise tööriistaga nagu Chaos Monkey, mis tuvastab võimalikud tõrked kaustades, konfiguratsioonides ja võrgus.
etcd Operaator
Operaatori rakendamise näide - etcd operaator, selle kontseptsiooni väljakuulutamise päeval. Etdd-klastri konfiguratsioon võib olla keeruline, kuna on vaja säilitada kvoorum, klastri liikmelisus ümber konfigureerida, varukoopiaid luua jne. Näiteks etcd klastri käsitsi skaleerimine tähendab, et peate looma uuele klastri liikmele DNS-nime, käivitama uue etcd olemi ja teavitama klastrit uuest liikmest (etcdctl liikme lisamine). Operaatori puhul peab kasutaja muutma vaid klastri suurust – kõik muu toimub automaatselt.
Ja kuna etcd loodi ka CoreOS-is, siis oli üsna loogiline, et selle Operaator ilmus esimesena. Kuidas ta töötab? Operaatori loogika jne määratakse kolme komponendiga:
- Jälgige. Operaator jälgib klastri olekut Kubernetes API abil.
- Analüüs. Leiab erinevused praeguse ja soovitud oleku vahel (määratletud kasutaja konfiguratsiooniga).
- Tegevus. Lahendab tuvastatud erinevused etcd ja/või Kubernetese teenuse API-de abil.
Selle loogika rakendamiseks on Operaatoris funktsioonid ette valmistatud Loo/hävita (etcd klastri liikmete loomine ja kustutamine) ja Resize (klastri liikmete arvu muutus). Selle töö õigsust kontrolliti Netflixi Chaos Monkey sarnasuses loodud utiliidi abil, s.o. tapavad etcd kaunad juhuslikult.
Etdd täielikuks kasutamiseks pakub operaator lisafunktsioone: Varundamine (automaatne ja kasutajatele nähtamatu varukoopiate loomine - konfiguratsioonis piisab, kui määrata, kui sageli neid teha ja kui palju salvestada - ning sellele järgnev andmete taastamine neist) ja upgrade (värskendada etcd installatsioone ilma seisakuta).
Kuidas näeb välja operaatoriga töötamine?
$ 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
Etdd Operatori praegune olek on beetaversioon, mille käitamiseks on vaja Kubernetes 1.5.3+ ja etcd 3.0+. Lähtekood ja dokumentatsioon (sh kasutusjuhised) on saadaval aadressil .
Veel üks näide CoreOS-ist on loodud - , kuid see on endiselt alfaversioonis (kõiki kavandatud funktsioone pole rakendatud).
Seis ja väljavaated
5 kuud on möödunud Kubernetes Operatorsi väljakuulutamisest. Ametlikus CoreOS-i hoidlas on endiselt saadaval ainult kaks rakendust (etcd ja Prometheuse jaoks). Mõlemad pole veel oma stabiilse versioonini jõudnud, kuid kohustusi jälgitakse igapäevaselt.
Arendajad näevad ette "tulevikku, kus kasutajad installivad oma Kubernetese klastritesse Postgresi operaatorid, Cassandra operaatorid või Redise operaatorid ja töötavad nende rakenduste skaleeritavate üksustega sama lihtsalt kui praegu on olekuta veebirakenduste koopiate juurutamine." Esiteks Kolmandate osapoolte arendajate operaatorid hakkas tõesti paistma:
- ettevõttelt UPMC Enterprises;
- alates Crunchy Data (teatatud märtsi lõpus 2017);
- Cephil põhineva hajutatud andmesalvestussüsteemi autoritelt (Rook on alfa staatuses);
- SAP CCloudist.
2017. aasta veebruaris Brüsselis toimunud Euroopa suurimal vabatarkvara konverentsil FOSDEM teatas Josh Wood CoreOS-ist operaatoritest aastal. (video on saadaval lingil!), mis peaks kaasa aitama selle kontseptsiooni populaarsuse kasvule laiemas avatud lähtekoodiga kogukonnas.
PS Täname huvi eest artikli vastu! Tellige meie keskus, et mitte ilma jääda uutest materjalidest ja retseptidest DevOpsi ja GNU/Linuxi süsteemihalduse kohta – avaldame neid regulaarselt!
Allikas: www.habr.com