Následující představujeme jeho starší verzi — . Jedná se o open source projekt, který se používá k instalaci systémových komponent v clusterech Kubernetes, které lze shromáždit pod společným názvem — doplňky.
Proč vůbec nějaké doplňky?
Není tajemstvím, že Kubernetes není hotový produkt vše v jednom, a pro vybudování "dospělého" clustera jsou potřeba různé doplňky. Addon-operator pomůže nainstalovat, nakonfigurovat a udržovat tyto doplňky aktuální.
Potřeba dodatečných komponent v clusterech je vysvětlena v kolegové . Stručně řečeno, současná situace s Kubernetes je taková, že pro jednoduchou instalaci "na hraní" lze použít komponenty z krabice, pro vývoj a testování lze přidat Ingress, ale pro plnohodnotnou instalaci, o které můžeme říci "váš production je připraven", je potřeba přidat několik různých doplňků: něco pro monitoring, něco pro logy, nezapomenout na ingress a cert-manager, vyčlenit skupiny uzlů, přidat síťové politiky, okořenit nastaveními sysctl a pod autoscalerem...
Jaká je specifika práce s nimi?
Jak ukazuje praxe, jednou instalací práce nekončí. Pro pohodlnou práci s clusterem bude třeba doplňky aktualizovat, vypínat (odstraňovat z clusteru), a něco bude chtít vyzkoušet před instalací do production clusteru.
Takže, možná stačí Ansible? Možná. Ale plnohodnotné doplňky v obvyklém případě nemohou existovat bez nastavení. Tato nastavení se mohou lišit v závislosti na variantě clusteru (aws, gce, azure, bare-metal, do, …). Některá nastavení nelze nastavit předem — je třeba je získat z clusteru. A cluster není statický: pro některá nastavení bude třeba sledovat změny. A zde už Ansible nestačí: potřebujete program, který žije v clusteru, t. j. Kubernetes Operator.
Ti, kdo vyzkoušeli v praxi , řeknou, že úkoly instalace a aktualizace doplňků a sledování nastavení lze zcela vyřešit pomocí pro shell-operator. Můžete napsat skript, který bude dělat hypotetický kubectl apply a sledovat například ConfigMap, kde budou uložena nastavení. Přibližně to je realizováno v addon-operator.
Jak je to organizováno v addon-operator?
Při vytváření nového řešení jsme vycházeli z následujících principů:
- Instalátor doplňků by měl podporovat šablonizaci a deklarativní konfiguraci. Neděláme žádné magické skripty, které instalují doplňky. Addon-operator používá Helm k instalaci doplňků. Pro instalaci je potřeba vytvořit chart a vyčlenit values, které budou použity pro konfiguraci.
- Nastavení lze generovat při instalaci, mohou být získána z klastru, nebo získávat aktualizace, sledující zdroje klastru. Tyto operace lze realizovat pomocí hooků.
- Nastavení lze uchovávat v klastru. Pro uchovávání nastavení v klastru se vytváří ConfigMap/addon-operator a Addon-operator sleduje změny tohoto ConfigMap. Addon-operator dává hookům přístup k nastavením prostřednictvím jednoduchých konvencí.
- Doplněk závisí na nastavení. Pokud se nastavení změní, Addon-operator provede nasazení Helm-chartu s novými values. Kombinaci Helm-chartu, values pro něj a hooků jsme nazvali modulem (více viz níže).
- Staging. Neexistují žádné magické skripty pro vydání. Mechanismus aktualizací je podobný jako u běžné aplikace — sestavit doplňky a addon-operator do obrazu, označit a nasadit.
- Kontrola výsledku. Addon-operator dokáže poskytovat metriky pro Prometheus.
Co je to doplněk v addon-operator?
Doplňkem lze považovat vše, co přidává do klastru nové funkce. Například instalace Ingress — skvělý příklad doplňku. Může to být jakýkoli operator nebo kontroler se svým CRD: prometheus-operator, cert-manager, kube-controller-manager atd. Nebo něco malého, ale usnadňujícího správu — například secret copier, který kopíruje registry-secret do nových jmenných prostorů, nebo sysctl tuner, který nastavuje parametry sysctl na nových uzlech.
Pro realizaci doplňků Addon-operator poskytuje několik konceptů:
- Helm chart používá se k instalaci různých aplikací do klastru — například Prometheus, Grafana, nginx-ingress. Pokud má potřebná komponenta Helm-chart, potom jej bude velmi snadné nainstalovat pomocí Addon-operator.
- Úložiště values. Helm-charty obvykle obsahují mnoho různých nastavení, která se mohou v průběhu času měnit. Addon-operator podporuje uchovávání těchto nastavení a dokáže sledovat jejich změny, aby přeinstaloval Helm-chart s novými hodnotami.
- Huky — to jsou spustitelné soubory, které Addon-operator spouští na základě událostí a mají přístup ke skladu values. Hook může sledovat změny v klastru a aktualizovat hodnoty ve skladu values. To znamená, že pomocí hooků je možné provést discovery, aby se shromažďovaly hodnoty z klastru při spuštění nebo na základě plánu, nebo také kontinuitní discovery, kdy se shromažďují hodnoty z klastru na základě změn v klastru.
- Modul — to je spojení Helm chartu, skladu values a hooků. Moduly lze zapínat a vypínat. Vypnutí modulu znamená odstranění všech vydání Helm chartu. Moduly se mohou dynamicky zahrnovat, například pokud jsou zapnuty všechny potřebné moduly, nebo pokud discovery v hookech našlo potřebné parametry — toto se provádí pomocí pomocného skriptu enabled.
- Globální hooky. To jsou hooky „samy o sobě“, nejsou zahrnuty v modulech a mají přístup k globálnímu skladu values, jehož hodnoty jsou dostupné všem hookům v modulech.
Jak tyto části fungují dohromady? Podívejme se na obrázek z dokumentace:
Existují dva scénáře fungování:
- Globální hook se spouští na základě události — například při změně zdroje v klastru. Tento hook zpracovává změny a zapisuje nové hodnoty do globálního skladu values. Addon-operator si všimne, že globální sklad se změnil a spouští všechny moduly. Každý modul pomocí svých hooků zjišťuje, zda se má zapnout, a aktualizuje svůj sklad values. Pokud je modul zapnut, Addon-operator spouští instalaci Helm chartu. Helm chartu jsou dostupné hodnoty jak ze skladu modulu, tak z globálního skladu.
- Druhý scénář je jednodušší: modulový hook se spouští na základě události a mění hodnoty ve skladu values modulu. Addon-operator si toho všimne a spouští Helm chart s aktualizovanými hodnotami.
Doplnění může být realizováno jako jediný hook, nebo jako jeden Helm chart, nebo dokonce jako několik závislých modulů — záleží na složitosti komponenty, která má být nainstalována v klastru, a na požadované úrovni flexibility nastavení. Například v repozitáři () existuje doplněk sysctl-tuner, který je realizován jak jako jednoduchý modul s hookem a Helm chartem, tak i s využitím skladu values, což umožňuje přidávat nastavení prostřednictvím úpravy ConfigMap.
Doručení aktualizací
Několik slov o organizaci aktualizací komponent, které instaluje Addon-operator.
Aby mohl Addon-operator běžet v klastru, je třeba sestavit obraz s dodatky ve formě hook souborů a Helm chartů, přidat binární soubor addon-operator a vše, co bude potřeba pro hooky: bash, kubectl, jq, python atd. Další obraz lze nasadit do klastru jako běžnou aplikaci a pravděpodobně si budete chtít nastavit nějaký systém tagování. Pokud je klastrů málo, může být použit přístup jako u aplikací: nové vydání, nová verze, projít všechny klastry a opravit image u Podů. Nicméně, v případě nasazení na výrazný počet klastrů nám více vyhovuje koncepce automatických aktualizací z kanálu.
U nás to funguje takto:
- Kanál je v podstatě identifikátor, který lze zadávat libovolně (například dev/stage/ea/stable).
- Název kanálu je tag obrazu. Když je třeba nasadit aktualizace do kanálu, sestaví se nový obraz a označí názvem kanálu.
- Když se v registru objeví nový obraz, Addon-operator se restartuje a spustí novým obrazem.
To není best practice, o čemž se píše v . Tak to nedoporučujeme, ale hovoříme o běžné aplikaci, která žije v jednom klastru.V případě Addon-operator je aplikace množství Deploymentů rozptýlených po klastrech a automatické aktualizace velmi výrazně pomáhají a usnadňují život.
Kanály pomáhají i při testování:pokud je k dispozici pomocný klastr, lze jej nastavit na kanál stage a testovat aktualizace v něm před nasazením do kanálů. ea a stablePokud dojde k chybě v klastru na kanálu ea , může být přepnut na stable, zatímco probíhá vyšetřování problému s tímto klastrem. Pokud je klastr vyřazen z aktivní podpory, přepíná se na svůj 'zmražený' kanál – například, freeze-2019-03-20..
Kromě aktualizací hooků a Helm chartů může být potřeba aktualizovat i třetí komponentu.Například, pokud jste si všimli chyby v příslušném node-exporteru a dokonce jste vymysleli, jak ho opravit. Pak jste otevřeli PR a čekáte na nové vydání, abyste mohli projít všechny klastry a zvýšit verzi obrazu. Abychom nečekali neurčitou dobu, můžeme sestavit svůj node-exporter a přepnout se na něj do přijetí PR.
Obecně platí, že to můžete udělat i bez Addon-operator, ale s Addon-operator je modul pro instalaci node-exporter viditelný v jednom repozitáři, Dockerfile pro sestavení vlastního obrazu lze mít také zde, všem účastníkům procesu je jednodušší chápat, co se děje… A pokud je několik klastrů, je snazší testovat svůj PR a nasadit novou verzi!
Tato organizace pro aktualizaci komponentů u nás úspěšně funguje, ale lze realizovat i jakýkoli jiný vhodný režim — vždyť v tomto případě je Addon-operator jednoduchý binární soubor..
Závěr
Principy implementované v Addon-operator umožňují vytvořit transparentní proces tvorby, testování, instalace a aktualizace doplňků v klastru, který je analogický procesům vývoje běžných aplikací.
Doplňky pro Addon-operator ve formátu modulů (Helm chart + hooky) mohou být zveřejněny široké veřejnosti. My, společnost Flant, plánujeme zveřejnit během léta naše výsledky ve formě těchto doplňků. Připojte se k vývoji na GitHub (, ), zkuste vytvořit svůj vlastní doplněk na základě a , čekejte na novinky na Habr a na našem !
P.S.
Přečtěte si také náš blog:
- «»;
- «».
Zdroj: habr.com
