Po představujeme jeho staršího bratra - . Toto je projekt Open Source, který se používá k instalaci systémových komponent do clusteru Kubernetes, který lze nazvat doplňky.
Proč vůbec nějaké doplňky?
Není žádným tajemstvím, že Kubernetes není hotový all-in-one produkt a k sestavení „dospělého“ clusteru budete potřebovat různé doplňky. Addon-operator vám pomůže nainstalovat, nakonfigurovat a udržovat tyto doplňky aktuální.
Potřeba dalších komponent v clusteru je popsána v kolegové . Stručně řečeno, situace s Kubernetes je v tuto chvíli taková, že pro jednoduchou instalaci „play around“ si vystačíte s komponentami po vybalení, pro vývojáře a testování můžete přidat Ingress, ale pro plnou instalaci, o které můžete říci „vaše produkce je připravena“, musíte přidat tucet různých doplňků: něco pro monitorování, něco pro protokolování, nezapomeňte na ingress a cert-manager, vyberte skupiny uzlů, přidejte zásady sítě, sezónu s nastavením sysctl a pod autoscaler...
Jaká jsou specifika práce s nimi?
Jak ukazuje praxe, záležitost není omezena na jednu instalaci. Aby bylo možné s clusterem pohodlně pracovat, bude nutné doplňky aktualizovat, zakázat (odebrat z clusteru) a některé budete chtít otestovat, než je nainstalujete do produkčního clusteru.
Takže tady Ansible možná bude stačit? Možná. Ale Obecně platí, že plnohodnotné doplňky se neobejdou bez nastavení. Tato nastavení se mohou lišit v závislosti na variantě clusteru (aws, gce, azure, bare-metal, do, ...). Některá nastavení nelze zadat předem, je nutné je získat z clusteru. A cluster není statický: pro některá nastavení budete muset sledovat změny. A tady už Ansible chybí: potřebujete program, který žije v clusteru, tzn. Operátor Kubernetes.
Ti, co to zkusili v práci řeknou, že úlohy instalace a aktualizace doplňků a nastavení monitorování lze zcela vyřešit pomocí pro operátora shellu. Můžete napsat skript, který provede podmínku kubectl apply a sledovat např. ConfigMap, kde se nastavení uloží. To je přibližně to, co je implementováno v addon-operator.
Jak je to organizováno v addon-operátoru?
Při tvorbě nového řešení jsme vycházeli z následujících zásad:
- Instalační program doplňku musí podporovat šablonová a deklarativní konfigurace. Nevytváříme magické skripty, které instalují doplňky. Addon-operátor používá Helm k instalaci doplňků. Chcete-li nainstalovat, musíte vytvořit graf a vybrat hodnoty, které budou použity pro konfiguraci.
- Nastavení může být vygenerovat při instalaci, oni mohou získat z clusteruNebo přijímat aktualizace, sledování zdrojů clusteru. Tyto operace lze provádět pomocí háčků.
- Nastavení může být uložit do clusteru. Chcete-li uložit nastavení do clusteru, vytvoří se ConfigMap/operátor addonu a operátor addonu sleduje změny této ConfigMap. Addon-operátor poskytuje hákům přístup k nastavení pomocí jednoduchých konvencí.
- Přidání závisí na nastavení. Pokud se nastavení změnilo, operátor Addon rozbalí tabulku Helm s novými hodnotami. Kombinaci Helm diagramu, jeho hodnot a háků jsme nazvali modul (podrobnosti viz níže).
- Inscenace. Neexistují žádné magické skripty. Mechanismus aktualizace je podobný běžné aplikaci – shromážděte doplňky a operátory doplňků do obrázku, označte je a rozbalte.
- Kontrola výsledku. Operátor addonu může poskytnout metriky pro Prometheus.
Co je to padding v addon-operátoru?
Za přídavek lze považovat cokoli, co přidává do clusteru nové funkce. Například instalace Ingress je skvělým příkladem doplňku. Může to být jakýkoli operátor nebo kontrolor s vlastním CRD: prometheus-operator, cert-manager, kube-controller-manager atd. Nebo něco malého, ale snáze použitelného – například tajná kopírka, která zkopíruje tajné klíče registru do nových jmenných prostorů, nebo sysctl tuner, který konfiguruje parametry sysctl na nových uzlech.
Pro implementaci doplňků nabízí Addon-operator několik konceptů:
- Tabulka kormidla slouží k instalaci různého softwaru do clusteru - například Prometheus, Grafana, nginx-ingress. Pokud má požadovaný komponent Helmův diagram, bude jeho instalace pomocí Addon-operator velmi jednoduchá.
- Ukládání hodnot. Grafy kormidla mají obvykle mnoho různých nastavení, která se mohou v průběhu času měnit. Addon-operator podporuje ukládání těchto nastavení a může sledovat jejich změny, aby mohl přeinstalovat Helmův diagram s novými hodnotami.
- Háčky jsou spustitelné soubory, které operátor Addon spouští při událostech a které přistupují k úložišti hodnot. Hák může sledovat změny v clusteru a aktualizovat hodnoty v úložišti hodnot. Tito. Pomocí háčků můžete provádět zjišťování a shromažďovat hodnoty z clusteru při spuštění nebo podle plánu, nebo můžete provádět nepřetržité zjišťování, kdy shromažďujete hodnoty z clusteru na základě změn v clusteru.
- Modul je kombinací Helmova diagramu, úložiště hodnot a háčků. Moduly lze povolit nebo zakázat. Deaktivace modulu znamená smazání všech vydání mapy Helm. Moduly se mohou aktivovat dynamicky, například pokud jsou povoleny všechny moduly, které potřebuje, nebo pokud discovery nalezlo potřebné parametry v hácích – to se provádí pomocí pomocného povoleného skriptu.
- Globální háčky. Jedná se o háčky „samotné“, nejsou součástí modulů a mají přístup ke globálnímu úložišti hodnot, jehož hodnoty jsou dostupné všem hákům v modulech.
Jak tyto části spolupracují? Podívejme se na obrázek z dokumentace:
Existují dva pracovní scénáře:
- Globální hák je spuštěn událostí – například když se změní zdroj v clusteru. Tento hák zpracuje změny a zapíše nové hodnoty do úložiště globálních hodnot. Operátor addonu si všimne, že se globální úložiště změnilo a spustí všechny moduly. Každý modul pomocí svých háčků určí, zda je třeba jej povolit, a aktualizuje své úložiště hodnot. Pokud je modul povolen, operátor Addon zahájí instalaci tabulky Helm. V tomto případě má Helmův diagram přístup k hodnotám z úložiště modulu az globálního úložiště.
- Druhý scénář je jednodušší: háček modulu je spuštěn událostí a mění hodnoty v úložišti hodnot modulu. Operátor addonu si toho všimne a spustí graf Helm s aktualizovanými hodnotami.
Doplnění může být realizováno jako jeden jediný hák, nebo jako jeden Helm chart, popř i jako několik závislých modulů - to závisí na složitosti komponenty instalované v clusteru a na požadované úrovni flexibility konfigurace. Například v úložišti () existuje doplněk sysctl-tuner, který je implementován jak jako jednoduchý modul s háčkem a Helm diagramem, tak pomocí úložiště hodnot, což umožňuje přidávat nastavení úpravou ConfigMap.
Doručování aktualizací
Několik slov o organizaci aktualizací komponent, které instaluje operátor Addon.
Chcete-li spustit Addon-operator v clusteru, potřebujete vytvořit image s doplňky ve formě souborů hákových a Helmových grafů přidejte binární soubor addon-operator a vše, co potřebujete pro háčky: bash, kubectl, jq, python atd. Poté lze tento obrázek zavést do clusteru jako běžnou aplikaci a s největší pravděpodobností budete chtít uspořádat jedno nebo druhé schéma značkování. Pokud je clusterů málo, může být vhodný stejný přístup jako u aplikací: nové vydání, nová verze, přejděte na všechny clustery a opravte obraz Podů. V případě zavedení do značného počtu clusterů nám však více vyhovoval koncept vlastní aktualizace z kanálu.
Děláme to takto:
- Kanál je v podstatě identifikátor, který lze nastavit na cokoli (například dev/stage/ea/stable).
- Název kanálu je značka obrázku. Když potřebujete zavést aktualizace kanálu, sestaví se nový obrázek a označí se názvem kanálu.
- Když se v registru objeví nový obraz, Addon-operator se restartuje a spustí s novým obrazem.
Toto není nejlepší postup, jak je napsáno v . Nedoporučuje se to dělat, ale mluvíme o tom běžná aplikace, která žije ve stejném clusteru. V případě Addon-operator je aplikace spoustou Deploymentů roztroušených po clusterech a vlastní aktualizace hodně pomáhá a usnadňuje život.
Kanály pomáhají a v testování: pokud existuje pomocný cluster, můžete jej nakonfigurovat na kanál stage a před zavedením do kanálů do něj vložit aktualizace ea и stable. Pokud s clusterem na kanálu ea došlo k chybě, můžete ji přepnout na stable, zatímco se problém s tímto clusterem vyšetřuje. Pokud je cluster vyřazen z aktivní podpory, přepne se na svůj „zmrazený“ kanál – např. freeze-2019-03-20.
Kromě aktualizace háčků a map kormidla možná budete potřebovat aktualizace a součást třetí strany. Všimli jste si například chyby v podmíněném exportéru uzlů a dokonce jste přišli na to, jak ji opravit. Dále jste otevřeli PR a čekáte, až nové vydání projde všemi clustery a zvýší verzi obrázku. Abyste nečekali donekonečna, můžete si sestavit svůj exportér uzlů a přejít na něj před přijetím PR.
Obecně to lze provést bez Addon-operator, ale s Addon-operátorem bude modul pro instalaci node-exporter viditelný v jednom úložišti, Dockerfile pro vytvoření vašeho image lze uchovat přímo tam, bude to jednodušší pro všechny účastníky proces pochopit, co se stane... A pokud existuje několik klastrů, pak bude snazší otestovat vaše PR a zavést novou verzi!
Tato organizace aktualizace komponent nám úspěšně funguje, ale lze - koneckonců - implementovat jakékoli jiné vhodné schéma v tomto případě je Addon-operator jednoduchý binární soubor.
Závěr
Principy implementované v Addon-operator vám umožňují vybudovat transparentní proces vytváření, testování, instalace a aktualizace doplňků v clusteru, podobný vývojovým procesům běžných aplikací.
Doplňky pro Addon-operator ve formátu modulu (Helm chart + háčky) mohou být veřejně dostupné. My, společnost Flant, plánujeme zveřejnit náš vývoj v podobě takových doplňků během léta. Připojte se k vývoji na GitHubu (, ), zkuste vytvořit svůj vlastní doplněk na základě и , čekejte novinky na Habré a na našem !
PS
Přečtěte si také na našem blogu:
- «";
- «".
Zdroj: www.habr.com