Důležitým bodem při provozu distribuovaných systémů je řešení poruch. Kubernetes s tím pomáhá pomocí řadičů, které monitorují stav vašeho systému a restartují služby, které přestaly fungovat. Kubernetes však může násilně zastavit vaše aplikace, aby zajistil celkové zdraví systému. V této sérii se podíváme na to, jak můžete pomoci Kubernetes dělat jeho práci efektivněji a snížit prostoje aplikací.
Před kontejnery běžela většina aplikací na virtuálních nebo fyzických počítačích. Pokud aplikace spadla nebo zamrzla, trvalo dlouho, než byla zrušena probíhající úloha a znovu nahrán program. V nejhorším případě musel někdo tento problém řešit ručně v noci, v nejméně vhodnou hodinu. Pokud důležitý úkol plnily pouze 1-2 pracovní stroje, bylo takové narušení naprosto nepřijatelné.
Místo ručních restartů proto začali používat monitorování na úrovni procesu k automatickému restartování aplikace v případě abnormálního ukončení. Pokud program selže, proces monitorování zachytí ukončovací kód a restartuje server. S příchodem systémů jako Kubernetes byl tento typ reakce na selhání systému jednoduše integrován do infrastruktury.
Kubernetes používá smyčku událostí pozorovat-rozdíl-provádět akci, aby zajistila, že zdroje zůstanou zdravé, když putují z kontejnerů do samotných uzlů.
To znamená, že již nemusíte ručně spouštět monitorování procesů. Pokud zdroj neprojde kontrolou stavu, Kubernetes mu jednoduše automaticky poskytne náhradu. Kubernetes však dělá mnohem víc, než jen monitoruje selhání vaší aplikace. Může vytvořit více kopií aplikace pro spuštění na více počítačích, aktualizovat aplikaci nebo spustit více verzí vaší aplikace současně.
Existuje tedy mnoho důvodů, proč může Kubernetes ukončit dokonale zdravý kontejner. Pokud například upgradujete své nasazení, Kubernetes pomalu zastaví staré moduly a zároveň spustí nové. Pokud vypnete uzel, Kubernetes přestane spouštět všechny pody na tomto uzlu. A konečně, pokud uzlu dojdou prostředky, Kubernetes vypne všechny pody, aby tyto prostředky uvolnil.
Proto je důležité, aby se vaše aplikace ukončila s minimálním dopadem na koncového uživatele a minimální dobou obnovy. To znamená, že před vypnutím musí uložit všechna data, která je třeba uložit, uzavřít všechna síťová připojení, dokončit zbývající práci a zvládnout další naléhavé úkoly.
V praxi to znamená, že vaše aplikace musí být schopna zpracovat zprávu SIGTERM, signál ukončení procesu, který je výchozím signálem pro utilitu kill v operačních systémech Unix. Po obdržení této zprávy by se aplikace měla vypnout.
Jakmile se Kubernetes rozhodne ukončit modul, dojde k řadě událostí. Podívejme se na každý krok, který Kubernetes podnikne při vypínání kontejneru nebo podu.
Řekněme, že chceme ukončit jeden z modulů. V tomto okamžiku přestane přijímat nový provoz – kontejnery běžící v podu nebudou ovlivněny, ale veškerý nový provoz bude zablokován.
Podívejme se na hák preStop, což je speciální příkaz nebo požadavek HTTP, který se posílá do kontejnerů v podu. Pokud se vaše aplikace nevypne správně při příjmu SIGTERM, můžete použít preStop ke správnému vypnutí.
Většina programů se elegantně ukončí, když obdrží signál SIGTERM, ale pokud používáte kód třetí strany nebo nějaký systém, který plně neovládáte, je preStop hook skvělý způsob, jak si vynutit elegantní vypnutí beze změny aplikace.
Po provedení tohoto háku odešle Kubernetes do kontejnerů v podu signál SIGTERM, který jim dá vědět, že budou brzy odpojeny. Po přijetí tohoto signálu váš kód přejde k procesu vypnutí. Tento proces může zahrnovat zastavení jakýchkoli dlouhodobých připojení, jako je připojení k databázi nebo stream WebSocket, uložení aktuálního stavu a podobně.
I když používáte preStop hook, je velmi důležité zkontrolovat, co přesně se stane s vaší aplikací, když jí pošlete signál SIGTERM, a jak se chová, aby události nebo změny v provozu systému způsobené vypnutím modulu nenastaly jako překvapení pro tebe.
V tomto okamžiku bude Kubernetes čekat po určitou dobu, která se nazývá terminationGracePeriodSecond, nebo doba, po kterou se řádně vypne, když obdrží signál SIGTERM, než podnikne další akci.
Ve výchozím nastavení je tato doba 30 sekund. Je důležité si uvědomit, že běží paralelně s preStop hákem a signálem SIGTERM. Kubernetes nebude čekat na ukončení preStop hook a SIGTERM – pokud vaše aplikace skončí před ukončením TerminationGracePeriod, Kubernetes okamžitě přejde k dalšímu kroku. Proto zkontrolujte, zda hodnota této periody v sekundách není kratší než doba potřebná ke správnému vypnutí modulu, a pokud překročí 30 s, zvyšte periodu na požadovanou hodnotu v YAML. V uvedeném příkladu je to 60. léta.
A konečně posledním krokem je, že pokud kontejnery stále běží i po ukončeníGracePeriod, pošlou signál SIGKILL a budou násilně smazány. V tomto okamžiku Kubernetes také vyčistí všechny ostatní objekty pod.
Kubernetes ukončuje moduly z mnoha důvodů, takže se ujistěte, že se vaše aplikace v každém případě řádně ukončí, abyste zajistili stabilní službu.
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com