Problema su būseną nustatančiomis programomis „Kubernetes“.
Programų ir paslaugų konfigūravimas, paleidimas ir tolesnis mastelio keitimas yra paprastas, kai kalbama apie atvejus, klasifikuojamus kaip be būsenos, t.y. neišsaugant duomenų. Tokias paslaugas patogu paleisti Kubernetes, naudojant jo standartines API, nes viskas vyksta „out of the box“: pagal standartines konfigūracijas, neįtraukiant jokios specifikos ar magijos.
Paprasčiau tariant, norint paleisti dar penkias PHP/Ruby/Python fono kopijas konteinerių grupėje, tereikia 5 kartus nustatyti naują serverį ir nukopijuoti šaltinius. Kadangi vaizde yra ir šaltinio kodas, ir inicijavimo scenarijus, programos be būsenos mastelio keitimas tampa visiškai elementarus. Kaip gerai žino konteinerių ir mikro paslaugų architektūros gerbėjai, sunkumai prasideda nuo to valstybinės programos, t.y. su duomenų išlikimu, pvz., duomenų bazėmis ir talpyklomis (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Tai taikoma ir programinei įrangai, kuri savarankiškai įdiegia kvorumo grupę (pvz., Percona XtraDB ir Cassandra), ir programinei įrangai, kuriai reikalingos atskiros valdymo priemonės (pvz., Redis, MySQL, PostgreSQL...).
Sunkumai kyla dėl to, kad šaltinio kodo ir paslaugos paleidimo nebeužtenka – reikia atlikti dar kelis veiksmus. Bent jau nukopijuokite duomenis ir (arba) prisijunkite prie grupės. Tiksliau, šios paslaugos reikalauja supratimo, kaip tinkamai jas keisti, atnaujinti ir perkonfigūruoti neprarandant duomenų ar laikinai nepasiekiant. Atsižvelgimas į šiuos poreikius vadinamas „operacinėmis žiniomis“.
CoreOS operatoriai
Siekiant „užprogramuoti“ veiklos žinias, praėjusių metų pabaigoje CoreOS projektas „nauja programinės įrangos klasė“, skirta Kubernetes platformai – operatoriai (iš anglų kalbos „operation“, t. y. „operation“).
Operatoriai, naudojantys ir plečiantys pagrindines Kubernetes galimybes (įskaitant. StatefulSets, žr. skirtumą žemiau) leidžia „DevOps“ specialistams pridėti operatyvinių žinių prie programos kodo.
Operatoriaus tikslas — suteikti vartotojui API, leidžiančią valdyti kelis būseną nustačiusius taikomųjų programų objektus Kubernetes klasteryje, negalvojant apie tai, kas yra po gaubtu (kokius duomenis ir ką su jais daryti, kokias komandas dar reikia vykdyti, kad būtų išlaikytas klasteris ). Tiesą sakant, operatorius sukurtas taip, kad kiek įmanoma supaprastintų darbą su programa klasteryje, automatizuodamas operatyvinių užduočių, kurios anksčiau turėjo būti sprendžiamos rankiniu būdu, vykdymą.
Kaip dirba operatoriai
ReplicaSets Kubernetes leidžia nurodyti norimą veikiančių podų skaičių, o valdikliai užtikrina, kad jų skaičius būtų palaikomas (kurdami ir ištrindami podelius). Panašiai veikia ir operatorius, pridėdamas operatyvinių žinių rinkinį prie standartinio Kubernetes šaltinio ir valdiklio, leidžiančio atlikti papildomus veiksmus, kad būtų palaikomas reikiamas programos objektų skaičius.
Kuo tai skiriasi nuo StatefulSets, skirtas programoms, kurioms reikia, kad klasteris suteiktų joms būsenos išteklius, pvz., duomenų saugyklą arba statinius IP? Tokioms programoms operatoriai gali naudoti StatefulSets (vietoj ReplicaSets) kaip pagrindas, siūlymas papildoma automatika: atlikti reikiamus veiksmus gedimų atveju, daryti atsargines kopijas, atnaujinti konfigūraciją ir pan.
tokiu būdu, kaip visa tai veikia? Operatorius yra valdymo demonas, kuris:
- užsiprenumeruoja renginio API Kubernetes;
- iš jos gauna duomenis apie sistemą (apie jos ReplicaSets, ankštys, Paslaugos ir taip toliau.);
- gauna duomenis apie Trečiųjų šalių ištekliai (žr. pavyzdžius žemiau);
- reaguoja į išvaizdą/pokytį Trečiųjų šalių ištekliai (pavyzdžiui, norint pakeisti dydį, pakeisti versiją ir pan.);
- reaguoja į sistemos būklės pokyčius (apie jos ReplicaSets, ankštys, Paslaugos ir taip toliau.);
- svarbiausia:
- ragina Kubernetes API sukurti viską, ko jai reikia (vėlgi savo ReplicaSets, ankštys, Paslaugos...),
- atlieka tam tikrą magiją (supaprastindami galite manyti, kad operatorius pats įeina į blokus ir iškviečia komandas, pavyzdžiui, norint prisijungti prie klasterio arba atnaujinti duomenų formatą atnaujinant versiją).
Tiesą sakant, kaip matyti iš paveikslėlio, prie Kubernetes tiesiog pridedama atskira programa (įprasta diegimo с „ReplicaSet“), kuris vadinamas operatoriumi. Jis gyvena paprastoje ankštyje (dažniausiai tik vienoje) ir, kaip taisyklė, yra atsakingas tik už ją Vardų sritis. Ši operatoriaus programa įgyvendina savo API – nors ir ne tiesiogiai, bet per Trečiųjų šalių ištekliai Kubernetes mieste.
Taigi, po to, kai sukūrėme Vardų sritis Operatore, galime pridėti Trečiųjų šalių ištekliai.
Pavyzdys etcd (daugiau informacijos rasite žemiau):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Elasticsearch pavyzdys:
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
Reikalavimai operatoriams
„CoreOS“ suformulavo pagrindinius modelius, kuriuos inžinieriai gavo dirbdami su operatoriais. Nepaisant to, kad visi operatoriai yra individualūs (sukurti konkrečiai programai, turinčiai savo ypatybes ir poreikius), jų kūrimas turi būti pagrįstas tam tikra sistema, kuri kelia šiuos reikalavimus:
- Montavimas turi būti atliekamas per vieną diegimo: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - ir nereikalauja papildomų veiksmų.
- Diegiant operatorių Kubernetes, turi būti sukurtas naujas trečiosios šalies tipas (Trečiosios šalies šaltinis). Norėdami paleisti programos egzempliorius (klasterių egzempliorius) ir toliau juos valdyti (atnaujinti versijas, keisti dydį ir pan.), vartotojas naudos šį tipą.
- Jei įmanoma, turėtumėte naudoti „Kubernetes“ įmontuotus primityvus, pvz Paslaugos и ReplicaSetsnaudoti gerai patikrintą ir suprantamą kodą.
- Reikalingas atgalinis operatorių suderinamumas ir palaikymas senesnėms vartotojo sukurtų išteklių versijoms.
- Jei operatorius pašalinamas, pati programa turėtų toliau veikti be pakeitimų.
- Vartotojai turėtų turėti galimybę nustatyti pageidaujamą programos versiją ir organizuoti programos versijos naujinimus. Programinės įrangos atnaujinimų trūkumas yra dažnas veikimo ir saugumo problemų šaltinis, todėl operatoriai turi padėti vartotojams šiuo klausimu.
- Operatoriai turėtų būti išbandyti naudojant tokį įrankį kaip „Chaos Monkey“, kuris nustato galimus blokų, konfigūracijų ir tinklo gedimus.
etcd operatorius
Operatoriaus įgyvendinimo pavyzdys - etcd operatorius, šios koncepcijos paskelbimo dieną. etcd klasterio konfigūracija gali būti sudėtinga, nes reikia išlaikyti kvorumą, iš naujo sukonfigūruoti klasterio narystę, kurti atsargines kopijas ir pan. Pavyzdžiui, rankinis etcd klasterio mastelio keitimas reiškia, kad reikia sukurti DNS pavadinimą naujam grupės nariui, pradėti naują etcd objektą ir įspėti klasterį apie naują narį (etcdctl narys pridėti). Operatoriaus atveju vartotojui tereikės pakeisti klasterio dydį – visa kita vyks automatiškai.
Ir kadangi etcd taip pat buvo sukurtas CoreOS, buvo gana logiška, kad pirmiausia pasirodė jo operatorius. Kaip jis dirba? Operatoriaus logika ir kt yra nulemtas trijų komponentų:
- Stebėti. Operatorius stebi klasterio būseną naudodamas Kubernetes API.
- Analizė. Suranda skirtumus tarp esamos ir norimos būsenos (apibrėžia vartotojo konfigūracija).
- Veiksmas. Išsprendžia aptiktus skirtumus naudojant etcd ir (arba) Kubernetes paslaugų API.
Šiai logikai įgyvendinti Operatoriuje paruoštos funkcijos Sukurti / sunaikinti (kurti ir ištrinti etcd klasterio narius) ir Resize (klasterio narių skaičiaus pasikeitimas). Jo veikimo teisingumas buvo patikrintas naudojant „Netflix“ Chaos Monkey panašumą sukurtą įrankį, t.y. atsitiktinai žudo etcd ankštis.
Norint visapusiškai veikti etcd, operatorius suteikia papildomų funkcijų: atsarginės (automatinis ir vartotojams nematomas atsarginių kopijų kūrimas - konfigūracijoje pakanka nustatyti, kaip dažnai jas daryti ir kiek saugoti - ir vėlesnis duomenų atkūrimas iš jų) ir patobulinti (atnaujinti etcd įrenginius be prastovų).
Kaip atrodo darbas su operatoriumi?
$ 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
Dabartinė „etcd Operator“ būsena yra beta versija, kuriai veikti reikalinga „Kubernetes 1.5.3+“ ir „etcd 3.0+“. Šaltinio kodą ir dokumentus (įskaitant naudojimo instrukcijas) rasite adresu .
Sukurtas dar vienas „CoreOS“ diegimo pavyzdys - , bet vis dar yra alfa versija (ne visos suplanuotos funkcijos buvo įdiegtos).
Statusas ir perspektyvos
5 mėnesiai praėjo nuo Kubernetes operatorių paskelbimo. Oficialioje „CoreOS“ saugykloje vis dar yra tik du diegimai (skirta etcd ir Prometheus). Abu dar nepasiekė savo stabilių versijų, tačiau įsipareigojimai stebimi kasdien.
Kūrėjai numato „ateitį, kurioje vartotojai įdiegs „Postgres Operators“, „Cassandra Operators“ arba „Redis Operators“ savo „Kubernetes“ klasteriuose ir dirbs su keičiamais šių programų objektais taip pat lengvai, kaip šiandien yra diegti žiniatinklio programų be būsenos kopijas. Pirmas Operatoriai iš trečiųjų šalių kūrėjų tikrai pradėjo pasirodyti:
- iš UPMC Enterprises;
- iš „Crunchy Data“ (paskelbta 2017 m. kovo pabaigoje);
- iš paskirstytos duomenų saugojimo sistemos Ceph pagrindu autorių (Rook yra alfa būsenoje);
- iš SAP CCloud.
Didžiausioje Europoje nemokamos programinės įrangos konferencijoje FOSDEM, kuri vyko 2017 m. vasario mėn. Briuselyje, Joshas Woodas iš CoreOS paskelbė Operatorius m. (nuorodoje rasite vaizdo įrašą!), kuris turėtų prisidėti prie šios koncepcijos populiarumo augimo platesnėje Atvirojo kodo bendruomenėje.
PS Dėkojame, kad domitės straipsniu! Prenumeruokite mūsų centrą, kad nepraleistumėte naujos medžiagos ir receptų apie DevOps ir GNU/Linux sistemos administravimą – juos skelbsime reguliariai!
Šaltinis: www.habr.com