Järgnevalt esitleme tema vanemat venda — . See on Open Source projekt, mida kasutatakse süsteemikomponentide installimiseks Kubernetes'i klastrisse, mida võib kutsuda üldiselt — lisanditeks.
Miks üldse mingid lisandid?
Ei ole saladus, et Kubernetes ei ole valmis toode, mis sisaldab kõike-ühes, ja täiskasvanud klastri ehitamiseks on vajalikud erinevad lisandid. Addon-operator aitab neid lisandeid installida, konfigureerida ja hoida need ajakohasena.
Lisaelementide vajadus klastris on esitatud kolleegid . Lühidalt, olukord Kubernetes'ega on praegu selline, et lihtsaks 'katsetamiseks' piisab karbist saadud komponentidest, arendajate ja testimise jaoks saab lisada Ingress'i, kuid täielikuks installatsiooniks, mida võiks nimetada 'teie tootmine on valmis', on vajalik lisada tosin erinevat lisandit: midagi monitoorimiseks, midagi logide jaoks, ära unusta ingress'i ja cert-manager'it, eralda sõlmede gruppe, lisa võrgupoliitikaid, maitsesta sysctl'i ja pod autoscaler'i seadistustega...
Mis on nende töö eripära?
Kogemused näitavad, et ühe installatsiooniga asi ei piirdu. Mugavaks töötamiseks klastriga tuleb laiendusi uuendada, välja lülitada (klastrist eemaldada) ja mõningaid soovitakse testida enne tootmisclustersse installimist.
Nii et võib-olla Ansible piisab? Võib-olla. Kuid täielikud laiendused ei toimi tavaliselt ilma seadistuseta.Need seadistused võivad erineda sõltuvalt klastrivariandist (aws, gce, azure, bare-metal, do, …). Mõningaid seadistusi ei saa ette kirjutada - need tuleb saada klastrist. Ja klaster pole staatiline: teatud seadistuste jaoks tuleb jälgida muudatusi. Siin ei piisa enam Ansible'ist: vajalik on programm, mis elab klastris, s.t. Kubernetes Operator.
Need, kes on seda töös proovinud , ütlevad, et laienduste installimise ja uuendamise ülesanded ning seadistuste jälgimine on täiesti võimalik lahendada shell-operatoriga. Saab kirjutada skripti, mis teeb tingimuslikku kubectl apply ja jälgib näiteks ConfigMap'i, kus seadistused salvestatakse. Ligikaudu see ongi addon-operator'is rakendatud.
Kuidas see addon-operator'is korraldatud on?
Uue lahenduse loomisel lähtusime järgmistest põhimõtetest:
- Täienduste paigaldaja peab toetama mallimist ja deklaratiivset konfiguratsiooni. Me ei loo maagilisi skripte, mis paigaldavad täiendusi. Addon-operator kasutab täienduste paigaldamiseks Helmi. Paigaldamiseks tuleb luua chart ja määrata values, mis kasutatakse seadistamiseks.
- Seadeid saab genereerida paigaldamise käigus, neid saab saada klastrist, või saada uuendusi, jälgides klastri ressursse. Need toimingud saab teostada hookide abil.
- Seadeid saab hoida klastris. Seadeid klastris hoitakse ConfigMap/addon-operator, ja Addon-operator jälgib selle ConfigMapi muudatusi. Addon-operator annab hookidele ligipääsu seadistustele lihtsalt kokkulepitud viiside kaudu.
- Täiendamine sõltub seadistustest. Kui seaded muutuvad, siis Addon-operator väljastab Helm-chart koos uusimate values'itega. Helm-charti, value'ide ja hookide ühendamist nimetame mooduliks (lisainfot vt allpool).
- Etappimine. Ei ole maagilisi väljalaske skripte. Uuenduse mehhanism on sarnane tavapärasele rakendusele — koguda täiendusi ja addon-operatorit pildiks, tähistada ja väljastada.
- Tulemuse kontroll. Addon-operator suudab edastada metrikat Prometheusele.
Mis on addon-operatori lisand?
Lisandina võib pidada kõike, mis lisab klastrisse uusi funktsioone. Näiteks on Ingress'i installimine suurepärane näide lisandist. See võib olla ükskõik milline operaator või kontroller koos oma CRD-ga: prometheus-operator, cert-manager, kube-controller-manager jne. Või midagi väikest, kuid kasutuse lihtsustamiseks — näiteks salajaste andmete kopeerija, mis kopeerib registri saladusi uutesse nimesüsteemidesse, või sysctl tuner, mis seadistab sysctl parameetreid uutel sõlmedel.
Lisandite rakendamiseks pakub Addon-operator mitmeid kontseptsioone:
- Helm-chart kasutatakse erineva tarkvara installimiseks klastrisse — näiteks Prometheus, Grafana, nginx-ingress. Kui vajaliku komponendi jaoks on olemas Helm-chart, on selle Installimine Addon-operatoriga väga lihtne.
- Values'i hoidla. Helm-chartidel on tavaliselt palju erinevaid seadistusi, mis võivad aja jooksul muutuda. Addon-operator toetab nende seadistuste salvestamist ja oskab jälgida nende muutusi, et uuesti installida Helm-chart koos uute väärtustega.
- Haanikud — need to be executed files, which the Addon-operator triggers based on events and gains access to the values storage. The hook can monitor changes in the cluster and update values in the values storage. This means that hooks can perform discovery to gather values from the cluster at startup or on a schedule, or even continuous discovery by collecting values from the cluster based on changes within it.
- Modul — это Helm-чарт, хранилище значений и хуки. Модули можно включать и отключать. Отключение модуля означает удаление всех релизов Helm-чарта. Модули могут динамически включать сами себя, например, если все необходимые модули активированы или если discovery в хуках нашел необходимые параметры — это делается путем использования вспомогательного скрипта enabled.
- Globaalne hüüded. Need on hüüded, mis toimivad iseseisvalt, nad ei kuulu moodulitesse ja neil on ligipääs globaalsetele väärtuste ladudele, mille väärtused on kergesti kätte saadavad kõigile moodulites olevatele hüuetele.
Kuidas need osad koos töötavad? Vaadake dokumentatsioonist pilti:
Tööprotsesside stsenaariume on kaks:
- Globaalne hulk käivitub sündmuse korral — näiteks klastris ressursi muutmisel. See hulk töötleb muudatusi ja salvestab uued väärtused globaalsesse väärtuste hoiuruumi. Addon-operator märgib, et globaalne hoiuruum on muutunud ja käivitab kõik moodulid. Iga moodul määrab oma hakkide abil, kas ta peab sisse lülituma, ja värskendab oma väärtuste hoiuruumi. Kui moodul on sisse lülitatud, käivitab Addon-operator Helm-chart'i paigaldamise. Helm-chartil on juurdepääs väärtustele mooduli hoiuruumist ja globaalsest hoiuruumist.
- Teine stsenaarium on lihtsam: mooduli hulk käivitub sündmuse korral, muudab väärtusi mooduli väärtuste hoiuruumis. Addon-operator märkab seda ja käivitab Helm-chart'i värskendatud väärtustega.
Lisa võib olla realiseeritud kas üheainsa hulgana või ühe Helm-chart'ina, või isegi mitme sõltuva moodulina — see sõltub klastrisse paigaldatava komponendi keerukusest ja vajalikust seadistuste paindlikkuse tasemest. Näiteks hoidlas () on sysctl-tuner, which is implemented both as a simple module with a hook and Helm chart, as well as using a values repository, allowing settings to be added by editing the ConfigMap.
Updates delivery
A few words about organizing updates for the components installed by the Addon operator.
To run the Addon operator in the cluster, you need to build an image with addons in the form of hook files and Helm charts, add the binary file addon-operator and everything needed for the hooks: bash, kubectl, jq, python etc. After that, this image can be deployed to the cluster like a regular application, and you will likely want to establish some tagging scheme. If there are only a few clusters, the same approach as with applications may work: new release, new version, go through all clusters and update the image in the Pods. However, when deploying to a significant number of clusters, the concept of self-updating from a channel is more suitable for us.
We have it set up like this:
- A channel is essentially an identifier that you can set to anything (for example, dev/stage/ea/stable).
- Kanali nimi on pildi silt. Kui on vaja kanali uuendusi välja viia, kogutakse uus pilt ja märgistatakse kanali nimega.
- Kui registris ilmub uus pilt, taaskäivitub Addon-operator ja käivitub uue pildiga.
See ei ole parim praktika, millest on kirjutatud . Nii teha ei soovitata, kuid jutt on tavalisest rakendusest, mis elab ühes klastris. Addon-operatori puhul on rakendus hulgaliselt paigaldusi, mis on hajutatud klastrite vahel, ja iseuuendamine aitab tõeliselt palju ning lihtsustab elu.
Kanali tasemed aitavad samuti testimisel: kui on olemas abiklastr, saab selle seadistada etapi kanaliks ja katsetada uuendusi selles, enne kui need viiakse välja ees ja stabiilseks. Kui klastris, millel on kanal, esineb viga, saab selle lülitada ees , kuni uurimine käib selle klastriga seotud probleemi osas. Kui klaster elimineeritakse aktiivselt, lülitatakse see tema "külmutatud" kanali juurde — näiteks, stabiilseks, kuni uurimine selle klastriga seotud probleemide osas on käimas. Kui klaster on aktiivsest toest väljas, lülitub see oma „külmutatud” kanalile — näiteks, freeze-2019-03-20.
. Uuenduste üle vaalude ja Helm-chartide puhul võib osutuda vajalikuks uuendada ka kolmanda osapoole komponenti.. Näiteks olete märganud viga node-exporteris ja isegi leiutanud, kuidas seda patcheda. Siis avasite PR-i ja ootate uut väljalaset, et kõiki klastreid külastada ja pildi versiooni täiustada. Et mitte oodata ebamugavat aega, võite oma node-exporteri üles ehitada ja sellele üle minna, kuni PR on vastu võetud.
Üldiselt saab seda teha ka ilma Addon-operatorita, kuid Addon-operatori puhul on node-exporteri installimismoodul ühes repos nähtav, Dockerfile oma pildi ehitamiseks saab hoida samuti seal, ning kõik osalised saavad kergemini aru, mis toimub... Ja kui on mitu klastrit, siis on lihtsam nii oma PR-i testida kui ka uut versiooni rakendada!
See komponentide värskendamise korraldus töötab meil edukalt, kuid on võimalik rakendada ka mõnda muud sobivat skeemi — sest sellel juhul on Addon-operator lihtne binaarfail.
Kokkuvõte
Addon-operatoris rakendatud põhimõtted võimaldavad luua läbipaistva protsessi täienduste loomisel, testimisel, installimisel ja värskendamisel klastris, sarnase tavaliste rakenduste arendusprotsessidega.
Addon-operatorile moodulite vormingus (Helm-chart + hookid) saab avalikuks muuta. Meie, ettevõte Flant, plaanime suve jooksul jagada oma arendustöid selliste lisandite kujul. Liitu arendusega GitHubis (, ), proovi luua oma lisand ja , oota uudiseid Habrilt ja meie !
P.S.
Lugege ka meie blogist:
- «»;
- «».
Allikas: habr.com
