Po predstavljamo njegovog starijeg brata — . Ovo je Open Source projekt koji se koristi za instalaciju sistemskih komponenti u Kubernetes klaster, koje možemo nazvati zajedničkim pojmom — dodaci.
Zašto uopšte dodaci?
Nije tajna da Kubernetes nije gotov proizvod svega-u-jednom i da su za izgradnju „zrelog“ klastera potrebni različiti dodaci. Addon-operator pomaže u instalaciji, podešavanju i održavanju tih dodataka u aktuelnom stanju.
Potrebno je dodatne komponente u klasteru razraditi u kolege . Ukratko, situacija sa Kubernetesom trenutno je takva da za jednostavnu instalaciju „za igru“ možemo se poslužiti komponentama iz kutije, za developere i testiranje možemo dodati Ingress, ali za punu instalaciju, o kojoj možemo reći „vaš produkcijski sistem je spreman“, potrebno je dodati desetak različitih dodataka: nešto za monitoring, nešto za logove, ne zaboraviti ingress i cert-manager, odrediti grupe nodova, dodati mrežne politike, pripremiti podešavanja sysctl i pod autoscaler…
Koja je specifičnost rada s njima?
Kao što praksa pokazuje, sama instalacija nije dovoljna. Za ugodno funkcionisanje klastera, dodaci će se morati ažurirati, isključivati (uklanjati iz klastera), a nešto će možda biti potrebno testirati pre instalacije u produkcijskom klasteru.
Pa, možda je ovde dovoljan i Ansible? Moguće. Ali puni dodaci u opštem slučaju ne funkcionišu bez podešavanja. Ova podešavanja mogu se razlikovati u zavisnosti od vrste klastera (aws, gce, azure, bare-metal, do, …). Neka podešavanja nije moguće unapred postaviti — treba ih dobiti iz klastera. A klaster nije statičan: za neka podešavanja treba pratiti promene. I tu Ansible ne pomaže: potrebna je aplikacija koja živi u klasteru, tj. Kubernetes Operator.
Oni koji su probali u praksi , reći će da se zadaci instalacije i ažuriranja dodataka te praćenja podešavanja mogu potpuno rešiti uz za shell-operator. Moguće je napisati skript koji će raditi uslovni kubectl apply i pratiti, na primer, ConfigMap gde će se čuvati podešavanja. Otprilike ovo je realizovano u addon-operatoru.
Kako je to organizovano u addon-operatoru?
Kreirajući novo rešenje, vodili smo se sledećim principima:
- Instalater dodataka mora podržavati templatizaciju i deklarativnu konfiguraciju. Ne delamo čarobnih skriptov, ki nameščajo dodatke. Addon-operator uporablja Helm za namestitev dodatkov. Za namestitev je potrebno ustvariti chart in izpostaviti values, ki bodo uporabljeni za prilagoditev.
- Nastavitve je mogoče generirati ob namestitvi, te je mogoče dobiti iz klasterja, ali prejemati posodobitve, s spremljanjem virov klasterja. Te operacije je mogoče izvesti s pomočjo hook-ov.
- Nastavitve je mogoče shraniti v klasterju. Za shranjevanje nastavitev v klasterju se ustvari ConfigMap/addon-operator in Addon-operator spremlja spremembe tega ConfigMap-a. Addon-operator daje hook-om dostop do nastavitev prek preprostih dogovorov.
- Dodatki so odvisni od nastavitev. Če se nastavitev spremeni, Addon-operator naloži Helm-chart z novimi values. Združitev Helm-charta, values zanj in hook-ov smo poimenovali modul (več o tem spodaj).
- Staging. Brez čarobnih skriptov za izdajo. Mekanizem posodobitev je podoben običajni aplikaciji — zbrati dodatke in addon-operator v sliko, označiti in izdati.
- Nadzor rezultata. Addon-operator zna zagotavljati metrike za Prometheus.
Kaj je dodatek v addon-operatorju?
Dodatku lahko štejemo vse, kar dodaja nove funkcionalnosti v klaster. Na primer, namestitev Ingress — odličen primer dodatka. To je lahko vsak operator ali kontroler s svojim CRD: prometheus-operator, cert-manager, kube-controller-manager itd. Ali kaj manjšega, a poenostavi delovanje — na primer, secret copier, ki kopira registry skrivnosti v nova imenska prostora, ali sysctl tuner, ki nastavi sysctl parametre na novih vozlih.
Za izvajanje dodatkov Addon-operator ponuja več konceptov:
- Helm-chart se uporablja za namestitev raznolike programske opreme v klaster — na primer, Prometheus, Grafana, nginx-ingress. Če ima želeni komponent Helm-chart, bo namestitev preko Addon-operatorja zelo preprosta.
- Shramba values. Helm-charti običajno vsebujejo mnogo različnih nastavitev, ki se lahko sčasoma spreminjajo. Addon-operator podpira shranjevanje teh nastavitev in ve, kako spremljati njihove spremembe, da ponovno namesti Helm-chart z novimi vrednostmi.
- Hooki — to so izvršni datoteki, ki jih Addon-operator zažene ob dogodkih in ki dostopajo do shrambe values. Hook lahko spremlja spremembe v grozdu in posodablja vrednosti v shrambi values. To pomeni, da lahko s pomočjo hookov izvedemo odkrivanje, da zbiramo vrednosti iz grozda ob zagonu ali po urniku, ali pa neprekinjeno odkrivanje, pri čemer zbiramo vrednosti iz grozda ob spremembah v grozdu.
- Modul — je združenje Helm-diagrama, shramba values in hookov. Module je mogoče vklopiti in izklopiti. Izklop modula pomeni odstranitev vseh izdaj Helm-diagrama. Moduli se lahko dinamično vključujejo sami, na primer, če so vključeni vsi potrebni moduli ali če je odkrivanje v hookih našlo potrebne parametre — to se doseže s pomočjo pomožnega enabled-skripte.
- Globalni hooki. So to hooki »samostojno«, niso vključeni v module in imajo dostop do globalne shrambe values, katere vrednosti so dostopne vsem hookom v modulih.
Kako te dele delujejo skupaj? Oglejmo si sliko iz dokumentacije:
Obstoje sta dva scenarija delovanja:
- Globalni hook se sproži ob dogodku — na primer, ob spremembi virov v grozdu. Ta hook obdeluje spremembe in zapisuje nove vrednosti v globalno shrambo values. Addon-operator opazi, da se je globalna shramba spremenila, in zažene vse module. Vsak modul s pomočjo svojih hookov ugotovi, ali se mora vključiti, in posodobi svojo shramba values. Če je modul vklopljen, Addon-operator zažene namestitev Helm-diagrama. Helm-diagramu so dostopne vrednosti iz shrambe modula in iz globalne shrambe.
- Drugi scenarij je enostavnejši: modularni hook se sproži ob dogodku, spremeni vrednosti v shrambi values modula. Addon-operator to opazi in zažene Helm-diagram z posodobljenimi values.
Dopolnitev je lahko realizirana kot en sam hook ali kot en Helm-diagram, ali tudi kot več odvisnih modulov — to je odvisno od zapletenosti komponente, ki se namešča v grozd, in od potrebne ravni prilagodljivosti nastavitev. Na primer, v repozitoriju () je dopolnitev sysctl-tuner, ki je realizirana tako kot preprost modul s hookom in Helm-diagramom, kot tudi z uporabo shrambe values, kar omogoča dodajanje nastavitev preko urejanja ConfigMap.
Dostava posodobitev
Nekaj besed o organizaciji posodobitev komponent, ki jih namesti Addon-operator.
Za zagon Addon-operatorja v klastru je potrebno pripraviti sliko z dodatki v obliki hook datotek in Helm grafik, dodati binarno datoteko addon-operator in vse, kar potrebujete za hook-e: bash, kubectl, jq, python itd. Nato lahko to sliko implementirate v klaster kot običajno aplikacijo in verjetno boste želeli organizirati to ali ono shemo označevanja. Če imate malo klastrskih enot, morda velja isti pristop kot pri aplikacijah: nova različica, nova verzija, pojdite po vseh klastrih in spremenite sliko pri Pod-ih. Vendar pa, če gre za implementacijo na opazno število klastrskih enot, nam bolj ustreza koncept samoposodabljanja iz kanala.
Pri nas je to urejeno tako,
- kanal je v bistvu identifikator, ki ga lahko nastavite katerikoli (na primer, dev/stage/ea/stable).
- Ime kanala je oznaka slike. Ko je treba izvesti posodobitve v kanalu, se pripravi nova slika in se oznaka nastavi na ime kanala.
- Ko v registry pojavi nova slika, se Addon-operator ponovno zažene in se zažene s novo sliko.
To ni najboljša praksa, o čemur piše . Tako se ne priporoča, a gre za običajno aplikacijo, ki živi v enem klastru. Pri Addon-operatorju je aplikacija množica Deployment-ov, razpršenih po klastri, in samoposodabljanje zelo močno pomaga in poenostavi življenje.
Kanali pomagajo tudi pri testiranju: če je na voljo pomožni klaster, ga lahko nastavite na kanal stage in izvajate posodobitve v njega pred implementacijo v kanale. ea in stable. Če se je s klastrskim omrežjem na kanalu ea zgodila napaka, ga lahko preklopite na stable, medtem ko poteka preiskava težave s tem klasterjem. Če je klaster izključen iz aktivne podpore, se preklopi na svoj 'zamrznjen' kanal - na primer, freeze-2019-03-20.
Poleg posodobitev hook-ov in Helm grafik boste morda morali posodobiti tudi zunanje komponente. Na primer, opazili ste napako v hipotetičnem node-exporterju in ste celo našli način, kako ga popraviti. Nato ste odprli PR in čakate na novo različico, da prehitevate skozi vse klastre in povečate različico slike. Da ne bi čakali neomejeno časa, lahko pripravite svoj node-exporter in se preklopite nanj do sprejetja PR.
Na splošno to lahko storimo tudi brez Addon-operatorja, vendar bo z Addon-operatorjem modul za namestitev node-exporterja na voljo v eni repozitoriju, Dockerfile za sestavljanje lastne slike lahko hranimo kar tukaj, vsem udeležencem procesa pa je lažje razumeti, kaj se dogaja... In če je več oblikovnih, je lažje tako testirati svoj PR kot tudi namestiti novo različico!
Ta organizacija za posodabljanje komponent uspešno deluje pri nas, vendar lahko uresničimo tudi katerikoli drug ustrezen sistem — saj v tem primeru Addon-operator predstavlja preprost binarni datoteka.
Zaključek
Načela, implementirana v Addon-operatorju, omogočajo vzpostavitev preglednega procesa za izdelavo, testiranje, namestitev in posodabljanje dodatkov v klastru, kar je podobno procesom razvoja običajnih aplikacij.
Dodatke za Addon-operator v obliki modulov (Helm chart + hooki) lahko objavimo v široko dostopnost. Mi, podjetje Flant, načrtujemo, da bomo v poletnih mesecih objavili naše dosežke v obliki takih dodatkov. Pridružite se razvoju na GitHubu (, ), poskusite izdelati svoj dodatek na osnovi in , spremljajte novosti na Habré in na našem !
P.S.
Preberite tudi na našem blogu:
- «»;
- «».
Izvor: habr.com
