S distribuovanými systémy může být obtížné spravovat, protože obsahují mnoho pohyblivých, měnitelných prvků, které musí správně fungovat, aby byla zajištěna funkčnost systému. Pokud některý z prvků selže, systém ho musí detekovat, obejít a opravit, přičemž to vše musí probíhat automaticky. V této sérii „Nejlepší praktiky Kubernetes“ se dozvíme, jak nastavit testy Readiness a Liveness pro kontrolu životaschopnosti klastru Kubernetes.
Kontrola zdraví Health Check je jednoduchý způsob, jak nechat systém vědět, zda váš instance aplikace funguje, nebo ne. Pokud instance vaší aplikace nepracuje, jiné služby by se k ní neměly připojovat ani jí posílat žádosti. Místo toho by měl být požadavek zaslán jiné instanci aplikace, která je již spuštěna nebo bude spuštěna později. Kromě toho by systém měl vrátit vaší aplikaci ztracenou funkčnost.
Ve výchozím nastavení začne Kubernetes směrovat provoz do podu, když jsou všechny kontejnery uvnitř podů spuštěny, a restartovat kontejnery, když se selžou. Pro začátek může být toto chování systému v pořádku, ale můžete zvýšit spolehlivost nasazení svého produktu pomocí vlastních kontrol životaschopnosti.
Naštěstí Kubernetes umožňuje to provést docela jednoduše, takže neexistují žádné výmluvy pro ignorování takových kontrol. Kubernetes poskytuje dva typy testů Health Check, přičemž je důležité pochopit rozdíly v použití každého z nich.
Test připravenosti Readiness slouží k informování Kubernetes o připravenosti vaší aplikace obsluhovat provoz. Než povolí službě posílat provoz do podu, musí se Kubernetes ujistit, že test připravenosti proběhl úspěšně. Pokud test Readiness selže, Kubernetes přestane směrovat provoz do podu, dokud testování nebude úspěšné.
Test životaschopnosti Liveness informuje Kubernetes, zda je vaše aplikace živá nebo mrtvá. V prvním případě ji Kubernetes ponechá na pokoji, v druhém odstraní mrtvý pod a nahradí ho novým.
Představme si scénář, kde vaší aplikaci trvá 1 minutu, než se zahřeje a spustí. Vaše služba nebude fungovat, dokud se aplikace úplně nenačte a nespustí, ačkoli pracovní proces už začal. Navíc budete mít také problémy, pokud se rozhodnete škálovat toto nasazení na několik kopií, protože tyto kopie by neměly dostávat provoz, dokud nebudou úplně připravené. Nicméně, výchozí nastavení Kubernetes začne posílat provoz ihned po zahájení procesů uvnitř kontejneru.
Při použití readiness testu bude Kubernetes čekat, dokud aplikace nebude zcela spuštěna, a teprve poté povolí službě posílat provoz na novou kopii.
Představme si jiný scénář, kdy aplikace zamrzne na dlouhou dobu a přestane obsluhovat požadavky. Protože proces pokračuje v běhu, Kubernetes ve výchozím nastavení předpokládá, že je vše v pořádku, a bude nadále posílat požadavky na nefunkční pod. Při použití liveness testu však Kubernetes zjistí, že aplikace již neobsluhuje požadavky, a ve výchozím nastavení restartuje nefunkční pod.
Podívejme se, jak se testuje připravenost a životaschopnost. Existují tři způsoby testování – HTTP, Command a TCP. Pro kontrolu můžete použít kterýkoli z nich. Nejčastějším způsobem uživatelského testování je HTTP probe.
I když vaše aplikace není HTTP server, můžete si uvnitř aplikace vytvořit lehký HTTP server pro interakci s liveness testem. Poté Kubernetes začne pingovat pod, a pokud bude HTTP odpověď v rozmezí 200 nebo 300 ms, bude to znamenat, že pod je "zdravý". V opačném případě bude modul označen jako "nezdravý".
Pro testy pomocí Command Kubernetes vykoná příkaz uvnitř vašeho kontejneru. Pokud příkaz vrátí nulu jako exit code, pak bude kontejner označen jako zdravý, jinak, pokud se vrátí číslo exit status od 1 do 255, bude kontejner označen jako "nemocný". Tento způsob testování je užitečný, pokud nemůžete nebo nechcete spouštět HTTP server, ale můžete spustit příkaz, který zkontroluje "zdraví" vaší aplikace.
Poslední kontrolní mechanismus je TCP test. Kubernetes se pokusí navázat TCP spojení na určeném portu. Pokud se to podaří, kontejner je považován za zdravý; pokud ne, je považován za nefunkční. Tato metoda může být užitečná, pokud používáte scénář, ve kterém testování pomocí HTTP požadavku nebo provádění příkazu nefunguje příliš dobře. Například hlavními službami pro kontrolu pomocí TCP budou gRPC nebo FTP.
Testy lze nakonfigurovat několika způsoby s různými parametry. Můžete určit, jak často by se měly provádět, jaké jsou prahové hodnoty úspěchu a neúspěchu, jak dlouho čekat na odpovědi. Podrobnější informace jsou uvedeny v dokumentaci k testům Readiness a Liveness. Existuje však jeden velmi důležitý aspekt při nastavení Liveness testu – počáteční zpoždění testování initialDelaySeconds. Jak jsem již zmínil, neúspěšné provedení tohoto testu povede k restartování modulu. Proto se musíte ujistit, že testování nezačne, dokud aplikace nebude připravena k práci; jinak začne neustále restartovat. Doporučuji použít průměrný čas spuštění aplikace nebo P99 čas spuštění z vyrovnávací paměti. Nezapomeňte upravit tuto hodnotu, jak se čas spuštění vaší aplikace zrychluje nebo zpomaluje.
Většina odborníků potvrdí, že Health Check je povinnou kontrolou pro jakýkoli rozložený systém, a Kubernetes není výjimkou. Použití kontroly 'zdraví' služeb zajišťuje spolehlivý a bezporuchový provoz Kubernetes a pro uživatele to neznamená žádnou námahu.
Pokračování bude brzy…
Malá reklama 🙂
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ých materiálů? Podpořte nás objednávkou nebo doporučením známým, , unikátní alternativa entry-level serverů, kterou jsme pro vás vymysleli: (k dispozici varianty s RAID1 a RAID10, až 24 jader a až 40GB DDR4).
Dell R730xd je dvakrát levnější v datovém centru Equinix Tier IV v Amsterdamu? Jen u nás v Nizozemsku! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Čtěte o tom
Zdroj: habr.com
