Distribuované systémy může být obtížné spravovat, protože obsahují mnoho pohyblivých a měnících se prvků, které musí všechny správně fungovat, aby systém fungoval. Pokud některý z prvků selže, systém to musí detekovat, obejít a opravit, a to vše musí být provedeno automaticky. V této sérii Kubernetes Best Practices se naučíme, jak nastavit testy připravenosti a živosti pro testování stavu clusteru Kubernetes.
Kontrola stavu je jednoduchý způsob, jak dát systému vědět, zda je instance vaší aplikace spuštěna nebo ne. Pokud je instance vaší aplikace mimo provoz, neměly by k ní ostatní služby přistupovat ani na ni odesílat požadavky. Místo toho musí být požadavek odeslán do jiné instance aplikace, která již běží nebo bude spuštěna později. Kromě toho by měl systém obnovit ztracenou funkčnost vaší aplikace.
Ve výchozím nastavení začne Kubernetes odesílat provoz do podu, když jsou spuštěny všechny kontejnery v podech, a restartuje kontejnery, když se zhroutí. Toto výchozí chování systému může být pro začátek dost dobré, ale spolehlivost nasazení vašeho produktu můžete zlepšit pomocí vlastních kontrol zdravého rozumu.
Naštěstí to Kubernetes dělá docela snadno, takže neexistuje žádná omluva pro ignorování těchto kontrol. Kubernetes poskytuje dva typy kontrol stavu a je důležité pochopit rozdíly v tom, jak se každý používá.
Test připravenosti je navržen tak, aby řekl Kubernetes, že vaše aplikace je připravena zvládnout provoz. Než službě povolíte odesílání provozu do podu, musí Kubernetes ověřit, zda je kontrola připravenosti úspěšná. Pokud test připravenosti selže, Kubernetes přestane odesílat provoz do podu, dokud test neprojde.
Test životnosti říká Kubernetes, zda je vaše aplikace živá nebo mrtvá. V prvním případě jej Kubernetes nechá na pokoji, ve druhém mrtvý pod vymaže a nahradí jej novým.
Představme si scénář, kdy vaší aplikaci trvá zahřátí a spuštění 1 minutu. Vaše služba nezačne fungovat, dokud nebude aplikace plně načtena a spuštěna, ačkoli pracovní postup již začal. Problémy budete mít také, pokud budete chtít toto nasazení zvětšit na více kopií, protože tyto kopie by neměly přijímat provoz, dokud nebudou plně připraveny. Ve výchozím nastavení však Kubernetes začne odesílat provoz, jakmile začnou procesy uvnitř kontejneru.
Při použití testu připravenosti počká Kubernetes, dokud nebude aplikace plně spuštěna, než povolí službě odesílat provoz do nové kopie.
Představme si jiný scénář, ve kterém aplikace na dlouhou dobu visí a přestává obsluhovat požadavky. Jak proces pokračuje, ve výchozím nastavení bude Kubernetes předpokládat, že je vše v pořádku, a bude pokračovat v odesílání požadavků do nefunkčního modulu. Při použití Liveness však Kubernetes zjistí, že aplikace již neobsluhuje požadavky, a ve výchozím nastavení restartuje mrtvý modul.
Podívejme se, jak se testuje připravenost a životaschopnost. Existují tři testovací metody – HTTP, Command a TCP. Ke kontrole můžete použít kteroukoli z nich. Nejběžnějším způsobem testování uživatele je sonda HTTP.
I když vaše aplikace není HTTP server, stále můžete vytvořit odlehčený HTTP server uvnitř vaší aplikace pro interakci s testem živosti. Poté Kubernetes začne pingovat pod, a pokud je odpověď HTTP v rozsahu 200 nebo 300 ms, bude to indikovat, že pod je v pořádku. V opačném případě bude modul označen jako „nezdravý“.
Pro testy příkazů Kubernetes spustí příkaz uvnitř vašeho kontejneru. Pokud se příkaz vrátí s nulovým výstupním kódem, bude kontejner označen jako zdravý, v opačném případě po obdržení čísla výstupního stavu od 1 do 255 bude kontejner označen jako „nemocný“. Tato testovací metoda je užitečná, pokud nemůžete nebo nechcete spustit HTTP server, ale jste schopni spustit příkaz, který zkontroluje stav vaší aplikace.
Posledním ověřovacím mechanismem je test TCP. Kubernetes se pokusí navázat připojení TCP na zadaném portu. Pokud to lze provést, nádoba je považována za zdravou, pokud ne, je považována za neživotaschopnou. Tato metoda může být užitečná, pokud používáte scénář, kde testování s požadavkem HTTP nebo provádění příkazu nefunguje příliš dobře. Například hlavní služby pro ověření pomocí TCP by byly gRPC nebo FTP.
Testy lze konfigurovat několika způsoby s různými parametry. Můžete určit, jak často se mají provádět, jaké jsou prahové hodnoty úspěchu a selhání a jak dlouho čekat na odpovědi. Další informace naleznete v dokumentaci k testům připravenosti a životnosti. Při nastavování testu Liveness je však jeden velmi důležitý bod – počáteční nastavení testovacího zpoždění initialDelaySeconds. Jak jsem již zmínil, selhání tohoto testu bude mít za následek restart modulu. Musíte se tedy ujistit, že testování nezačne, dokud nebude aplikace připravena ke spuštění, jinak začne cyklicky restartovat. Doporučuji použít dobu spuštění P99 nebo průměrnou dobu spuštění aplikace z vyrovnávací paměti. Nezapomeňte tuto hodnotu upravit, protože spouštění vaší aplikace bude rychlejší nebo pomalejší.
Většina odborníků potvrdí, že kontroly stavu jsou povinnou kontrolou pro jakýkoli distribuovaný systém a Kubernetes není výjimkou. Používání kontrol stavu služeb zajišťuje spolehlivý a bezproblémový provoz Kubernetes a je pro uživatele snadné.
Pokračování již brzy...
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