Jmenuji se Dmitrij Sugrobov, jsem vývojář ve společnosti Leroy Merlin. V tomto článku vám řeknu, proč je Helm potřeba, jak zjednodušuje práci s Kubernetes, co se změnilo ve třetí verzi a jak ji použít k aktualizaci aplikací v produkci bez prostojů.
Toto je shrnutí založené na projevu na konferenci by - pokud nechcete číst, podívejte se na video.
Proč používáme Kubernetes ve výrobě
Leroy Merlin je lídrem na maloobchodním trhu pro kutily v Rusku a Evropě. Naše společnost má více než sto vývojářů, 33 000 interních zaměstnanců a obrovské množství lidí navštěvujících hypermarkety a web. Aby byli všichni spokojeni, rozhodli jsme se postupovat podle standardních přístupů. Vyvíjet nové aplikace pomocí architektury mikroslužeb; používat kontejnery k izolaci prostředí a zajištění správné dodávky; a použít Kubernetes pro orchestraci. Cena používání orchestrátorů se rychle zlevňuje: na trhu roste počet techniků zběhlých v této technologii a objevují se poskytovatelé nabízející Kubernetes jako službu.
Vše, co dělá Kubernetes, lze samozřejmě dělat i jinak, například překrytím některých Jenkinů a docker-compose skripty, ale proč si komplikovat život, když existuje hotové a spolehlivé řešení? Proto jsme přišli do Kubernetes a už rok ho používáme ve výrobě. V současné době máme dvacet čtyři clusterů Kubernetes, z nichž nejstarší je více než rok starý, s asi dvěma stovkami lusků.
Prokletí velkých souborů YAML v Kubernetes
Abychom mohli spustit mikroslužbu v Kubernetes, vytvoříme alespoň pět souborů YAML: pro nasazení, službu, vstup, ConfigMap, Secrets – a odešleme je do clusteru. Pro další aplikaci napíšeme stejný balíček džemů, se třetím napíšeme další a tak dále. Pokud vynásobíme počet dokumentů počtem prostředí, dostaneme již stovky souborů, a to ještě nebereme v úvahu dynamická prostředí.
Adam Reese, hlavní správce Helmu, představil koncept „“, který vypadá takto:
- Kopírovat YAML – zkopírujte soubor YAML.
- Vložit YAML – vložit.
- Fix Indents - oprava odsazení.
- Opakovat - opakovat znovu.
Tato možnost funguje, ale musíte soubory YAML zkopírovat mnohokrát. Aby se tento cyklus změnil, byl vynalezen Helm.
Co je Helm
Za prvé, Helm - správce balíčků, který vám pomůže najít a nainstalovat programy, které potřebujete. Chcete-li nainstalovat například MongoDB, nemusíte chodit na oficiální web a stahovat binární soubory, stačí spustit příkaz helm install stable/mongodb.
Za druhé, Helm - šablonový engine, pomáhá parametrizovat soubory. Vraťme se k situaci se soubory YAML v Kubernetes. Je jednodušší napsat stejný soubor YAML, přidat do něj nějaké zástupné symboly, do kterých Helm dosadí hodnoty. To znamená, že namísto velké sady lešení bude existovat sada šablon, do kterých budou ve správný čas nahrazeny požadované hodnoty.
Za třetí, Helm - master nasazení. S ním můžete instalovat, vracet a aktualizovat aplikace. Pojďme zjistit, jak to udělat.
Jak používat Helm k nasazení vlastních aplikací
Nainstalujme klienta Helm do vašeho počítače podle oficiálního . Dále vytvoříme sadu souborů YAML. Místo specifikování konkrétních hodnot ponecháme zástupné symboly, které Helm v budoucnu naplní informacemi. Sada takových souborů se nazývá Helmův diagram. Klientovi konzoly Helm jej lze odeslat třemi způsoby:
- označte složku se šablonami;
- zabalte archiv do .tar a ukažte na něj;
- vložte šablonu do vzdáleného úložiště a přidejte odkaz na úložiště v klientovi Helm.
Potřebujete také soubor s hodnotami - values.yaml. Data odtud budou vložena do šablony. Pojďme si ho také vytvořit.
Druhá verze Helmu má další serverovou aplikaci - Tiller. Visí mimo Kubernetes a čeká na požadavky od klienta Helm a po zavolání nahradí požadované hodnoty do šablony a odešle ji Kubernetes.
Helm 3 je jednodušší: namísto zpracování šablon na serveru jsou informace nyní zpracovávány výhradně na straně klienta Helm a odesílány přímo do Kubernetes API. Toto zjednodušení zlepšuje zabezpečení clusteru a usnadňuje schéma zavádění.
Jak to celé funguje
Spusťte příkaz helm install. Uveďme název vydání aplikace a uveďme cestu k values.yaml. Na konci uvedeme úložiště, ve kterém se graf nachází, a název grafu. V příkladu jsou to „lmru“ a „bestchart“.
helm install --name bestapp --values values.yaml lmru/bestchart
Příkaz lze provést pouze jednou, když se místo toho provede znovu install potřeba použít upgrade. Pro jednoduchost můžete místo dvou příkazů spustit příkaz upgrade s přídavným klíčem --install. Při prvním spuštění Helm odešle příkaz k instalaci vydání a v budoucnu jej aktualizuje.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Úskalí nasazení nových verzí aplikace s Helmem
V tomto bodě příběhu hraji s publikem Kdo chce být milionářem a vymýšlíme, jak přimět Helma, aby aktualizoval verzi aplikace. .
Když jsem se učil, jak Helm funguje, překvapilo mě podivné chování při pokusu o aktualizaci verzí běžících aplikací. Aktualizoval jsem kód aplikace, nahrál nový obrázek do registru Docker, odeslal příkaz k nasazení – a nic se nestalo. Níže jsou uvedeny některé ne zcela úspěšné způsoby aktualizace aplikací. Podrobnějším prostudováním každého z nich začnete chápat vnitřní strukturu nástroje a důvody tohoto nezřejmého chování.
Metoda 1. Neměňte informace od posledního spuštění
Jak přísloví praví Helm: "Grafy Kubernetes mohou být velké a složité, takže se Helm snaží ničeho příliš nedotýkat." Pokud tedy aktualizujete nejnovější verzi obrazu aplikace v registru dockeru a spustíte příkaz helm upgrade, tak se nic nestane. Helm si bude myslet, že se nic nezměnilo a není potřeba posílat příkaz Kubernetes k aktualizaci aplikace.
Zde a níže je nejnovější značka uvedena pouze jako příklad. Když zadáte tuto značku, Kubernetes stáhne obrázek z registru docker pokaždé, bez ohledu na parametr imagePullPolicy. Používání nejnovějších produktů ve výrobě je nežádoucí a způsobuje vedlejší účinky.
Metoda 2. Aktualizujte LABEL v obrázku
Jak je napsáno ve stejném "Helm aktualizuje aplikaci pouze v případě, že se od posledního vydání změnila." Logickou možností se zdá být aktualizace LABEL v samotném obrazu dockeru. Helm se však do obrázků aplikace nedívá a nemá ani ponětí o jejich změnách. Při aktualizaci štítků v obraze o nich Helm nebude vědět a příkaz aktualizace aplikace nebude odeslán do Kubernetes.
Metoda 3: Použijte klíč --force
Pojďme se podívat do manuálů a hledat požadovaný klíč. Klíč dává největší smysl --force. Navzdory zřejmému názvu se chování liší od očekávání. Namísto vynucení aktualizace aplikace je jejím skutečným účelem obnovení vydání, které je ve stavu FAILED. Pokud tento klíč nepoužíváte, musíte příkazy provádět postupně helm delete && helm install --replace. Místo toho se doporučuje použít klíč --force, který automatizuje sekvenční provádění těchto příkazů. Více informací v tomto . Aby bylo možné sdělit Helmu, aby aktualizoval verzi aplikace, bohužel tento klíč nebude fungovat.
Metoda 4. Změňte štítky přímo v Kubernetes
Aktualizace štítku přímo v clusteru pomocí příkazu kubectl edit - špatný nápad. Tato akce povede k nekonzistenci informací mezi spuštěnou aplikací a tou, která byla původně odeslána k nasazení. Chování Helmu během nasazení se v tomto případě liší od jeho verze: Helm 2 neudělá nic a Helm 3 nasadí novou verzi aplikace. Abyste pochopili proč, musíte pochopit, jak Helm funguje.
Jak Helm funguje?
K určení, zda se aplikace od posledního vydání změnila, může Helm použít:
- spuštění aplikace v Kubernetes;
- nové hodnoty.yaml a aktuální graf;
- Helmova interní informace o vydání.
Pro zvědavější: kde Helm ukládá interní informace o vydáních?Provedením příkazu helm history, získáme všechny informace o verzích nainstalovaných pomocí Helm.
Nechybí ani podrobné informace o odeslaných šablonách a hodnotách. Můžeme o to požádat:
Ve druhé verzi Helmu jsou tyto informace umístěny ve stejném jmenném prostoru, kde běží Tiller (ve výchozím nastavení systém kube), v ConfigMap, označeném štítkem „OWNER=TILLER“:
Když se objevila třetí verze Helmu, informace se přesunuly do tajů a do stejného jmenného prostoru, kde byla spuštěna aplikace. Díky tomu bylo možné spouštět několik aplikací současně v různých jmenných prostorech se stejným názvem vydání. Ve druhé verzi to byla vážná bolest hlavy, když jsou jmenné prostory izolované, ale mohou se navzájem ovlivňovat.
Druhý Helm, když se snaží pochopit, zda je potřeba aktualizace, používá pouze dva zdroje informací: to, co je mu poskytováno nyní, a interní informace o vydáních, které leží v ConfigMap.
Třetí Helm využívá třícestnou strategii slučování: kromě těchto informací bere v úvahu také aplikaci, která právě běží v Kubernetes.
Z tohoto důvodu stará verze Helmu nic neudělá, protože nebere v úvahu informace o aplikaci v clusteru, ale Helm 3 přijme změny a odešle novou aplikaci k nasazení.
Metoda 5. Použijte přepínač --recreate-pods
S klíčem --recreate-pods pomocí klíče můžete dosáhnout toho, čeho jste původně plánovali dosáhnout --force. Kontejnery se restartují a podle zásady imagePullPolicy: Always pro nejnovější značku (více o tom v poznámce pod čarou výše) Kubernetes stáhne a spustí novou verzi obrázku. To nebude provedeno nejlepším způsobem: bez zohlednění StrategyType nasazení dojde k náhlému vypnutí všech starých instancí aplikací a zahájení spouštění nových. Během restartu systém nebude fungovat, uživatelé budou trpět.
V samotném Kubernetes podobný problém také dlouho existoval. A nyní, 4 roky po otevření , problém byl opraven a počínaje verzí 1.15 Kubernetes se objevuje možnost roll-restart podů.
Helm jednoduše vypne všechny aplikace a spustí nové kontejnery poblíž. Nemůžete to udělat v produkci, abyste nezpůsobili prostoje aplikace. To je potřeba pouze pro potřeby vývoje a lze to provést pouze ve scénických prostředích.
Jak aktualizovat verzi aplikace pomocí Helm?
Změníme hodnoty odeslané do Helmu. Obvykle se jedná o hodnoty, které jsou nahrazeny místo značky obrázku. V případě nejnovějšího, který se často používá pro neproduktivní prostředí, je proměnlivou informací anotace, která je pro samotný Kubernetes k ničemu a pro Helmu bude fungovat jako signál pro nutnost aktualizace aplikace. Možnosti pro vyplnění hodnoty anotace:
- Náhodná hodnota pomocí standardní funkce -
{{ randAlphaNum 6 }}.
Existuje upozornění: po každém nasazení pomocí grafu s takovou proměnnou bude hodnota anotace jedinečná a Helm bude předpokládat, že došlo ke změnám. Ukazuje se, že aplikaci vždy restartujeme, i když jsme její verzi nezměnili. To není kritické, protože nedojde k prostojům, ale stále je to nepříjemné. - Vložit proud datum a čas -
{{ .Release.Date }}.
Varianta je podobná náhodné hodnotě s trvale jedinečnou proměnnou. - Správnějším způsobem je použití kontrolní součty. Toto je SHA obrázku nebo SHA posledního potvrzení v git -
{{ .Values.sha }}.
Bude potřeba je spočítat a odeslat klientovi Helm na straně volajícího, například v Jenkins. Pokud se aplikace změnila, změní se kontrolní součet. Proto Helm aktualizuje aplikaci pouze v případě potřeby.
Shrňme si naše pokusy
- Helm provádí změny co nejméně invazivním způsobem, takže jakákoli změna na úrovni obrazu aplikace v registru Docker nebude mít za následek aktualizaci: po provedení příkazu se nic nestane.
- Klíč
--forcepoužívá se k obnově problematických vydání a není spojen s vynucenými aktualizacemi. - Klíč
--recreate-podsnásilně aktualizuje aplikace, ale udělá to vandalským způsobem: náhle vypne všechny kontejnery. Uživatelé tím budou trpět; neměli byste to dělat ve výrobě. - Přímo proveďte změny v clusteru Kubernetes pomocí příkazu
kubectl editne: narušíme konzistenci a chování se bude lišit v závislosti na verzi Helmu. - S vydáním nové verze Helmu se objevilo mnoho nuancí. Problémy v úložišti Helm jsou popsány srozumitelným jazykem, pomohou vám porozumět detailům.
- Přidáním upravitelné poznámky do grafu bude graf flexibilnější. To vám umožní spustit aplikaci správně, bez prostojů.
Myšlenka „světového míru“, která funguje ve všech oblastech života: přečtěte si návod před použitím, ne po něm. Pouze s úplnými informacemi bude možné budovat spolehlivé systémy a dělat uživatelům radost.
Další související odkazy:
Tato zpráva byla poprvé prezentována na od Mail.ru Cloud Solutions. Dívej se další představení a přihlaste se k odběru oznámení o událostech na Telegramu .
Zdroj: www.habr.com