Jmenuji se Dmitrij Sugrobov, jsem vývojář ve společnosti "Leroy Merlin". V tomto článku vám povím, proč je Helm potřebný, jak usnadňuje práci s Kubernetes, co se změnilo ve třetí verzi a jak pomocí něj aktualizovat aplikace v produkci bez výpadků.
Toto je shrnutí na základě vystoupení na konferenci by — pokud nechcete číst, podívejte se na video.
Proč používáme Kubernetes v produkci
"Leroy Merlin" je lídrem na trhu DIY retailu v Rusku a Evropě. V naší společnosti je více než sto vývojářů, 33 000 interních zaměstnanců a obrovské množství lidí navštěvujících hypermarkety a webové stránky. Abychom je všechny učinili šťastnými, rozhodli jsme se držet standardních přístupů v průmyslu. Nové aplikace vyvíjíme pomocí mikroservisní architektury; pro izolaci prostředí a správnou dodávku používáme kontejnery; a pro orchestraci používáme Kubernetes. Cena používání orchestrátorů rychle klesá: na trhu roste počet inženýrů se znalostí této technologie, objevují se poskytovatelé nabízející Kubernetes jako službu.
Všechno, co Kubernetes dělá, lze samozřejmě udělat i jinými způsoby, například pomocí skriptů v Jenkins a docker-compose, ale proč si ztěžovat život, když existuje hotové a spolehlivé řešení? Proto jsme přešli k Kubernetes a už rok ho používáme v produkci. Nyní máme dvacet čtyři klastrů Kubernetes, nejstaršímu z nich je více než rok, obsahuje kolem dvou set podů.
Prokletí velkého počtu YAML souborů v Kubernetes
Pro spuštění mikroservisu v Kubernetes vytvoříme alespoň pět YAML souborů: pro Deployment, Service, Ingress, ConfigMap, Secrets — a odešleme je do klastru. Pro další aplikaci napíšeme stejný balíček YAML, pro třetí — další a tak dále. Vynásobíme počet dokumentů počtem prostředí a již získáme stovky souborů, a to ještě nezohledňujeme dynamická prostředí.
Adam Reese, klíčový udržovatel Helm, zavedl pojem „“, který vypadá takto:
- Kopírovat YAML — zkopírujte YAML soubor.
- Vložit YAML — vložte ho.
- Opravit odsazení — opravte odsazení.
- Opakujte — opakujte znovu.
Varianta funguje, ale musíte často kopírovat YAML soubory. Abychom tento cyklus změnili, byl vynalezen Helm.
Co je Helm
Za prvé, Helm — balíčkový manažer, který pomáhá vyhledávat a instalovat potřebné programy. Pro instalaci například MongoDB není potřeba navštěvovat oficiální stránku a stahovat binární soubory, stačí provést příkaz helm install stable/mongodb.
Za prvé, Helm — šablonovací nástroj, který pomáhá parametrizovat soubory. Vrátíme se k situaci s YAML soubory v Kubernetes. Je snazší napsat ten samý YAML soubor, přidat do něj některé placeholdery, do kterých Helm dosadí hodnoty. Takže místo velkého množství YAML souborů budeme mít sadu šablon, do kterých se v potřebný moment dosadí potřebné hodnoty.
Za druhé, Helm — mistr nasazování. Pomocí něj lze instalovat, vracet a aktualizovat aplikace. Pojďme se podívat, jak to udělat.
Jak používat Helm pro nasazení vlastních aplikací
Nainstalujeme klienta Helm na počítač podle oficiální . Pak vytvoříme sadu YAML souborů. Místo zadání konkrétních hodnot necháme placeholdery, které Helm v budoucnu vyplní informacemi. Sada těchto souborů se nazývá Helm chart. Do konzolového klienta Helm ji lze poslat třemi způsoby:
- uvést složku se šablonami;
- zabalit do .tar archivu a uvést na něj;
- umístit šablonu do vzdáleného repozitáře a přidat odkaz na repozitář do klienta Helm.
Ještě je potřeba soubor se hodnotami — values.yaml. Data z něj budou dosazena do šablony. Vytvoříme i ten.
Ve druhé verzi Helmu existuje další serverová aplikace — Tiller. Ta visí mimo Kubernetes a čeká na požadavky od klienta Helm, a když je vyvolána, dosadí potřebné hodnoty do šablony a odešle je do Kubernetes.
Helm 3 je jednodušší: místo zpracování šablon na serveru, se informace nyní zpracovávají celkově na straně klienta Helm a odesílají se přímo do Kubernetes API. Toto zjednodušení zvyšuje bezpečnost clusteru a usnadňuje schéma nasazování.
Jak to všechno funguje
Spustíme příkaz helm install. Uvedeme název releasu aplikace, dáme cestu k values.yaml. Na konci uvedeme repozitář, ve kterém leží chart a název chartu. V příkladu to je „lmru“ a „bestchart“, respektive.
helm install --name bestapp --values values.yaml lmru/bestchart
Provádění příkazu je možné pouze jednou, při opětovném provedení místo install je potřeba použít upgrade. Pro zjednodušení místo dvou příkazů je možné provést příkaz upgrade s dalším klíčem --install. Při prvním spuštění Helm odešle příkaz k instalaci relace a poté ji bude aktualizovat.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Úskalí nasazování nových verzí aplikace pomocí Helmu
V této části příběhu si hraji se sálem v „Kdo chce být milionářem“, a zjišťujeme, jak donutit Helm aktualizovat verzi aplikace. .
Když jsem zkoumal fungování Helmu, překvapilo mě podivné chování při pokusu o aktualizaci verzí spuštěných aplikací. Kód aplikace jsem aktualizoval, v docker registry nahrál nový obraz, odeslal příkaz k nasazení – a nic se nestalo. Níže uvádím několik méně úspěšných způsobů, jak aktualizovat aplikace. Při podrobnějším zkoumání každého z nich začnete chápat vnitřní fungování nástroje a důvody tak ne zcela zřejmého chování.
Způsob 1. Neměnit informace od posledního spuštění
Jak praví Helm, „Kubernetes chart může být velký a složitý, a proto se Helm snaží co nejméně zasahovat“. Proto, pokud aktualizujete latest-verzi obrazu aplikace v docker registry a provedete příkaz helm upgrade, nic se nestane. Helm bude myslet, že se nic nezměnilo, a že není potřeba posílat do Kubernetes příkaz k aktualizaci aplikace.
Zde a dále je tag latest uveden pouze jako příklad. Při použití tohoto tagu Kubernetes bude pokaždé stahovat obraz z docker registry, bez ohledu na parametr imagePullPolicy. Použití latest v produkci je nežádoucí a může způsobit vedlejší efekty.
Způsob 2. Aktualizovat LABEL v obraze
Jak je uvedeno ve stejném , „Helm bude aktualizovat aplikaci pouze tehdy, pokud se změnila od posledního vydání“. Logickým krokem pro to by se zdálo být aktualizace labelu LABEL v samotném docker obrazu. Nicméně Helm nenahlíží do obrazů aplikací a nemá ponětí o jakýchkoliv změnách v nich. Tudíž při aktualizaci labelů v obraze se o nich Helm nedozví a příkaz k aktualizaci aplikace v Kubernetes nebude odeslán.
Způsob 3. Použít klíč --force
Obraťme se na příručky a hledejme potřebný klíč. Nejvíce smysluplný klíč se zdá být --force. I když název naznačuje opak, chování se liší od očekávaného. Namísto vynuceného aktualizování aplikace je jeho skutečným cílem obnovení vydání, které je ve stavu FAILED. Pokud se tento klíč nepoužije, je potřeba postupně vykonat příkazy. helm delete && helm install --replace. Místo toho je navrženo použít klíč --force, který automatizuje postupné vykonávání těchto příkazů. Více informací v tomto . Abychom přinutili Helm přesto aktualizovat verzi aplikace, bohužel tento klíč nevyhovuje.
Způsob 4. Měnit labely přímo v Kubernetes.
Aktualizace labelu přímo v clusteru pomocí příkazu kubectl edit — špatný nápad. Tento krok povede k nekonzistenci informací mezi běžící aplikací a tím, co bylo původně poslano k nasazení. Chování Helmu při nasazování se v tomto případě liší podle verze: Helm 2 nic nedělá, zatímco Helm 3 nasadí novou verzi aplikace. Abychom pochopili důvod, musíme rozumět, jak Helm funguje.
Jak funguje Helm.
Aby zjistil, zda se aplikace od posledního vydání změnila, může Helm využít:
- běžící aplikaci v Kubernetes;
- nový values.yaml a aktuální chart;
- vnitřní informace Helmu o vydáních.
Pro nejzvědavější: kde Helm uchovává vnitřní informace o vydáních?Provedením příkazu helm history, získáme všechny informace o verzích nainstalovaných pomocí Helmu.
Je k dispozici také podrobná informace o zaslaných šablonách a hodnotách. Můžeme o ně požádat:
Ve druhé verzi Helmu tyto informace ležely ve stejném namespace, kde byl spuštěn Tiller (výchozí — kube-system), v ConfigMap označené štítkem „OWNER=TILLER“:
S příchodem třetí verze Helmu se informace přesunuly do tajemství, přičemž ve stejném namespace, kde byla aplikace spuštěna. Díky tomu lze spouštět současně několik aplikací v různých namespacech se stejným názvem vydání. Ve druhé verzi to byla velká bolest hlavy, když byly namespace izolované, ale mohly na sebe mít vliv.
Druhý Helm, když se snaží pochopit, zda je třeba aktualizace, používá pouze dva zdroje informací: to, co mu bylo nyní poskytnuto, a vnitřní informace o vydáních, které leží v ConfigMap.
Třetí Helm používá strategii three-way merge: kromě dříve získaných informací zohledňuje také aplikaci, která momentálně běží v Kubernetes.
Z tohoto důvodu stará verze Helmu nic nedělá, protože nebere v úvahu informace o aplikaci v klastru, zatímco Helm 3 změny zpracovává a nasazuje novou aplikaci.
Způsob 5. Použít klíč —recreate-pods
Pomocí klíče --recreate-pods je možné dosáhnout výsledku, který se dříve plánovalo získat pomocí klíče --force. Kontejnery se restartují a podle politiky imagePullPolicy: Always pro tag latest (o tom v poznámce výše) Kubernetes stáhne a spustí novou verzi obrazu. Neproběhne to však nejlepším způsobem: aniž by bral v úvahu StrategyType nasazení, náhle vypne všechny staré instance aplikace a začne spouštět nové. Během restartu nebude systém fungovat, uživatelé budou trpět.
V samotném Kubernetes podobný problém také existoval po dlouhou dobu. A teď, po 4 letech od jeho objevení , byla chyba opravena a od verze 1.15 Kubernetes se objevuje možnost rolling-restart podů.
Helm prostě vypíná všechny aplikace a spouští vedle nových kontejnerů. V produkčním prostředí to není možné, aby nedošlo k výpadku aplikace. To by mělo být používáno pouze pro vývojové potřeby, lze to provádět pouze v stagingových prostředích.
Jak aktualizovat verzi aplikace pomocí Helmu?
Budeme měnit hodnoty, zasílané do Helmu. Obecně to jsou hodnoty, které nahrazují tag obrazu. V případě latest, často používaného pro neproduktivní prostředí, se jako měnitelná informace používá anotace, která je pro samotné Kubernetes bezcenná, ale pro Helm bude signálem k nutnosti aktualizace aplikace. Možnosti vyplnění hodnoty anotace:
- Náhodná hodnota pomocí standardní funkce —
{{ randAlphaNum 6 }}.
Je tu jedna nuenda: po každém nasazení s použitím chartu s takovou proměnnou bude hodnota anotace unikátní a Helm bude předpokládat, že došlo ke změnám. To znamená, že vždy budeme restartovat aplikaci, i když jsme její verzi nezměnili. Není to kritické, protože nedochází k výpadkům, ale přece jen je to nepříjemné. - Vložit aktuální datum a čas —
{{ .Release.Date }}.
Tento způsob se podobá náhodné hodnotě s neustále unikátní proměnnou. - Správnější způsob — použít kontrolní součty. Toto je SHA obrazu nebo SHA posledního commitu v Gitu —
{{ .Values.sha }}.
Musí se spočítat a odeslat do klienta Helm na volající straně, například v Jenkinsu. Pokud se aplikace změní, změní se i kontrolní součet. Helm proto aktualizuje aplikaci pouze tehdy, když je to nutné.
Shrňme naše pokusy
- Helm provádí změny nejméně invazivním způsobem, proto jakákoli změna na úrovni obrazu aplikace v Docker Registry nepovede k aktualizaci: po vykonání příkazu se nic nestane.
- Klíč
--forcepoužívá se k obnovení problematických vydání a nesouvisí s nucenou aktualizací. - Klíč
--recreate-podsnuceně aktualizuje aplikace, ale udělá to drsným způsobem: náhle vypne všechny kontejnery. Uživatelé tím trpí, takto to na produkci dělat nelze. - Přímo provádět změny v klastru Kubernetes pomocí příkazu
kubectl editnení třeba: narušíme konzistenci a chování se bude lišit v závislosti na verzi Helm. - S vydáním nové verze Helm se objevilo mnoho nuancí. Problémy v repozitáři Helm jsou popsány srozumitelným jazykem a pomohou objasnit detaily.
- Přidání změnitelné anotace do chartu ho učiní flexibilnějším. To umožní zavádět aplikaci správně, bez prostoje.
Myšlenka z kategorie "míru na celém světě", fungující ve všech oblastech života: čtěte návod před použitím, nikoli po něm. Teprve s úplnými informacemi můžete stavět spolehlivé systémy a dělat uživatele šťastné.
Další odkazy na téma:
Tento referát byl poprvé představen na by Mail.ru Cloud Solutions. Podívejte se další vystoupení a přihlaste se k oznámením akcí na Telegramu .
Zdroj: habr.com
