Kubernetes klastrit on lihtne ja mugav seadistada? Tutvustame addon-operatorit

Järgneb shell-operator meie vanem vend — addon-operator. See on Open Source projekt, mida kasutatakse Kubernetes klastrisse süsteemikomponentide paigaldamiseks, mida võib üldiselt nimetada täiendusteks.

Miks on üldse vaja täiendusi?

Ei ole saladus, et Kubernetes ei ole valmis kõik-ühes toode ja 'täiskasvanud' klastrite ehitamiseks on vajalikud erinevad täiendused. Addon-operator aitab neid täiendusi paigaldada, konfigureerida ja hoida neid ajakohasena.

Täiendavate komponentide vajadus klastris on selgitatud ettekandes kolleegid driusha. Lühidalt öeldes, on hetkeolukord Kubernetes'es selline, et lihtsaks paigaldamiseks 'katsetamiseks' piisab välja toodud komponentidest, arendamise ja testimise jaoks võib lisada Ingress'i, kuid täieliku paigaldamise jaoks, millest võib öelda 'teie tootmine on valmis', on vajalik lisada peaaegu kümme erinevat täiendust: midagi jälgimiseks, midagi logide jaoks, mitte unustada ingress'i ja cert-manager'i, eraldada sõlmede gruppe, lisada võrgupoliitikaid, lisada sysctl'i seadistusi ja pod autoscaler…

Millised on nende tööspetsiifikad?

Kogemus näitab, et lihtsalt paigaldamine ei piisa. Klasteri mugavaks kasutamiseks tuleb täiendusi värskendada, välja lülitada (klastrist eemaldada) ja võib-olla on soovitud neid testida enne tootmisklastrisse installimist.

Nii et, võib-olla piisab sellest Ansible'st? Võib-olla. Kuid täielikud täiendused ei toimi tavaliselt ilma seadistusteta. Need seadistused võivad erineda sõltuvalt klastriversioonist (aws, gce, azure, bare-metal, do, …). Mõningaid seadistusi ei saa ette määrata — need tuleb klastrist hankida. Klaster ei ole staatiline: mõne seadistuse jaoks tuleb jälgida muudatusi. Ja siin ei piisa Ansible'st: on vajalik programm, mis elab klastris, st Kubernetes Operator.

Need, kes on proovinud tööl shell-operator, ütlevad, et täienduste paigaldamise ja värskendamise ning seadistuste jälgimise ülesandeid saab üsna hästi lahendada hookide paralleelseks täitmiseks. shell-operatori abil. Saame kirjutada skripti, mis teeb tingimuslikku kubectl apply ja jälgib näiteks ConfigMap'i, kus hoitakse seadistusi. Umbes selline on ka addon-operator'i rakendamine.

Kuidas on see korraldatud addon-operator'is?

Uue lahenduse loomisel lähenesime me järgmistele põhimõtetele:

• Täienduste paigaldaja peab toetama mallimist ja deklaratiivset konfiguratsiooni. Me ei tee võluvaid skripte, mis installivad lisaosasid. Addon-operator kasutab Helm'i lisaosade installimiseks. Installimiseks tuleb luua chart ja välja tuua väärtused, mida kasutatakse seadistamiseks.
• Seadeid on võimalik genereerida installimise käigus, neid on võimalik saada klastrist, või saada uuendusi, jälgides klastrite ressursse. Need toimingud on võimalikud läbi hook'ide.
• Seadeid on võimalik hoida klastris. Seadete hoidmiseks klastris luuakse ConfigMap/addon-operator ja Addon-operator jälgib selle ConfigMap'i muudatusi. Addon-operator võimaldab hook'idel seada seadetele lihtsate kokkulepete kaudu juurdepääsu.
• Lisaosa sõltub seadistustest. Kui seadeid muudetakse, siis Addon-operator väljastab Helm'i chart'i uute väärtustega. Helm'i chart'i, väärtuste ja hook'ide ühendamist oleme nimetanud mooduliks (lisainfot vt allpool).
• Etappide loomine. Pole võluvaid väljaandmis-skripte. Uuenduste mehhanism on sarnane tavalise rakendusega — koguda lisaosasid ja addon-operatorit pildiks, märgistada ja välja anda.
• Tulemuse kontrollimine. Addon-operator suudab edastada metrikat Prometheusele.

Mis on lisaosa addon-operator'is?

Lisaosaks võib pidada kõike, mis lisab klastrile uusi funktsioone. Näiteks, Ingress'i installimine — suurepärane näide lisaosast. See võib olla iga operaator või kontrollija oma CRD'ga: prometheus-operator, cert-manager, kube-controller-manager jne. Või midagi väikest, mis lihtsustab haldust — näiteks, secret copier, mis kopeerib registry-saladusi uutesse nimede ruumidesse, või sysctl tuner, mis seadistab sysctl parameetreid uutel sõlmedel.

Lisaosade rakendamiseks pakub Addon-operator mitmeid kontseptsioone:

• Helm'i chart kasutatakse erineva tarkvara installimiseks klastrisse — näiteks, Prometheus, Grafana, nginx-ingress. Kui vajalikul komponendil on Helm'i chart, siis on selle installimine Addon-operator'i kaudu väga lihtne.
• Väärtuste hoidla. Helm'i chart'idel on tavaliselt palju erinevaid seadeid, mis võivad aja jooksul muutuda. Addon-operator toetab nende seadete hoidmist ja suudab jälgida nende muudatusi, et uuesti installida Helm'i chart koos uute väärtustega.
• Hook'id — need on käivitatavad failid, mida Addon-operator käivitab sündmuste põhjal ja millel on juurdepääs values salvestusele. Hüpe võib jälgida muudatusi klastris ja värskendada väärtusi values salvestuses. See tähendab, et hüpikute abil saab teha avastamist, et koguda väärtusi klastrist käivitamisel või ajakava kohaselt, või kasutada pidevat avastamist, kogudes väärtusi klastrist muudatuste põhjal.
• Moodul — on Helm-chart, values salvestuse ja hüpikute kogum. Mooduleid saab sisse ja välja lülitada. Mooduli väljalülitamine tähendab kõigi Helm-chart'i väljaande eemaldamist. Moodulid saavad dünaamiliselt ise sisse lülituda, näiteks kui kõik vajalikud moodulid on sisse lülitatud või kui avastamine hüpikutes on leidnud vajalikud parameetrid — see toimub abistava enabled-skripti abil.
• Globaalne hüpe. Need on «iseseisvad» hüpikud, mis ei kuulu moodulitesse ja millel on juurdepääs globaalsetele values salvestusele, mille väärtused on kõikidele moodulite hüpikutele kergesti kätte saadavad.

Kuidas need osad koos töötavad? Vaatame dokumentatsioonist pilti:

On kaks tööstsenaariumi:

1. Globaalne hüpe käivitub sündmuse põhjal — näiteks, kui ressurssi klastris muudetakse. See hüpe töötleb muudatusi ja salvestab uued väärtused globaalsetesse values salvestustesse. Addon-operator märkab, et globaalne salvestus on muutunud ja käivitab kõik moodulid. Iga moodul määrab oma hüpikute abil, kas seda on vaja sisse lülitada, ning värskendab oma values salvestust. Kui moodul on sisse lülitatud, käivitab Addon-operator Helm-chart'i. Helm-chart'il on juurdepääs väärtustele mooduli salvestusest ja globaalsetest salvestustest.
2. Teine stsenaarium on lihtsam: mooduli hüpe käivitub sündmuse põhjal, muudab väärtusi mooduli values salvestuses. Addon-operator märkab seda ja käivitab Helm-chart'i värskendatud väärtustega.

Täiendust võib rakendada üheainsa hüpena või ühe Helm-chart'ina või isegi kui mitme sõltuva moodulina — see sõltub klastrisse installitava komponendi keerukusest ja vajalikust seadistuste paindlikkusest. Näiteks, repositooriumis (/examples) on sysctl-tuner täienduse, mis on rakendatud nii lihtsa moodulina, millel on hüpe ja Helm-chart, kui ka kasutades values salvestust, mis võimaldab seadeid lisada ConfigMap-i redigeerimise kaudu.

Uuenduste edastamine

Mõned sõnad komponentide värskendamise korraldamisest, mida paigaldab Addon-operator.

Addon-operatori käivitamiseks klastris on vaja koguda lisandite pilt nagu hook-failid ja Helm-chartid, lisada binaarfail addon-operator ja kõik, mis vajalik hookide jaoks: bash, kubectl, jq, python jne. Edasi võib seda pilti klastrisse välja anda nagu tavalist rakendust ning tõenäoliselt soovite korraldada mingit silti. Kui klastreid on vähe, võib sobida sama lähenemine nagu rakenduste puhul: uus versioon, uus versioon, minna kõikide klastrite juurde ja muuta Pod'ide image. Siiski, kui on palju klastreid, sobib meile rohkem enesetäiendamise kontseptsioon kanalist.

Meil on see korraldatud nii:

• Kanal on põhimõtteliselt identifitseerija, mille saate määrata igasuguseks (näiteks dev/stage/ea/stable).
• Kanali nimi on pildi silt. Kui on vaja värskendusi kanali jaoks välja anda, kogutakse uus pilt ja sildistatakse kanali nimega.
• Kui registry'sse ilmub uus pilt, taaskäivitub Addon-operator ja käivitatakse uue pildiga.

See ei ole parim praktika, millest on kirjutatud Kubernetes'e dokumentatsioonile. Sedasi toimimist ei soovitata, kuid jutt käib tavalisest rakendusest, mis elab ühes klastris. Addon-operatori puhul on rakendus hulk Deploymente, mis on laiali klastrite vahel, ja enesetäiendamine aitab väga ning lihtsustab elu.

Kanalid aitavad samuti testimisel: kui on abiklastr, saab selle kanali jaoks seadistada stage ja veenda värskendusi sinna, enne kui need kanalitesse välja antakse ea ja stable. Kui kanali klastriga ea tüübis esines viga, saab selle suunata stable, kuni sellega seotud probleemi uurimine toimub. Kui klaster on välja viidud aktiivsest toimest, lülitatakse see oma "külmutatud" kanalile — näiteks, freeze-2019-03-20.

Lisaks hookide ja Helm-chartide värskendamisele võib olla vajalik uuendada ka välist komponenti. Näiteks, kui leiate vean node-exporteris ja olete isegi mõelnud, kuidas seda patcheerida. Edasi avasite PR-i ja ootate uut väljaandmist, et minna üle kõikide klastrite ja suurendada pildi versiooni. Et mitte oodata määramata aega, saate koguda enda node-exporteri ja lülituda selle peale, kuni PR aktsepteeritakse.

Tegelikult saab seda teha ka ilma Addon-operatorita, kuid koos Addon-operatoriga on node-exporter'i installimise moodul ühes repostiivis nähtav, Dockerfile oma pildi loomisel saab hoida seal samas, kõigil osalistel on lihtsam mõista, mis toimub... Ja kui klastreid on mitu, siis on kergem nii testida oma PR-i kui ka uut versiooni paigaldada!

See komponentide värskendamise organisatsioon töötab meil edukalt, kuid võib rakendada ka mistahes muud sobivat skeemi — sest antud juhul on Addon-operator lihtne binaarfail.

Kokkuvõte

Addon-operatoris rakendatud põhimõtted võimaldavad luua läbipaistva protsessi lisandite loomisel, testimisel, paigaldamisel ja värskendamisel klastris, mis on sarnane tavaliste rakenduste arendusprotsessidega.

Addon-operatori lisandeid saab moodulite (Helm-chart + hookid) vormis avalikult jagada. Meie, Flanti ettevõte, plaanime suve jooksul jagada oma arendusi selliste lisandite näol. Liituge arendusega GitHubis (shell-operator, addon-operator), proovige luua oma lisandit põhinedes näidistele ja dokumentatsioon, ootake uudiseid Habrest ja meie YouTube'i kanalilt!

P.S.

Lugege ka meie blogist:

• «Täiendame ja täiustame Kubernetes’t (ülevaade ja videodoklad)»;
• «Tutvustame shell-operatorit: Kubernetes'e operaatorite loomine on veelgi lihtsamaks muutunud».

Allikas: habr.com