Distribuované systémy môžu byť náročné na správu, pretože majú veľa pohyblivých a meniacich sa prvkov, ktoré musia všetky správne fungovať, aby systém fungoval. Ak niektorý z prvkov zlyhá, systém to musí zistiť, obísť a opraviť, a to všetko musí prebiehať automaticky. V tejto sérii osvedčených postupov Kubernetes sa naučíme, ako nastaviť testy pripravenosti a životnosti na testovanie stavu klastra Kubernetes.
Kontrola stavu je jednoduchý spôsob, ako dať systému vedieť, či je vaša inštancia aplikácie spustená alebo nie. Ak je vaša inštancia aplikácie mimo prevádzky, iné služby by k nej nemali pristupovať ani do nej odosielať požiadavky. Namiesto toho musí byť požiadavka odoslaná do inej inštancie aplikácie, ktorá je už spustená alebo bude spustená neskôr. Okrem toho by mal systém obnoviť stratenú funkčnosť vašej aplikácie.
V predvolenom nastavení začne Kubernetes odosielať návštevnosť do modulu, keď sú spustené všetky kontajnery v moduloch, a reštartuje kontajnery, keď zlyhajú. Toto predvolené správanie systému môže byť na začiatok dosť dobré, ale spoľahlivosť nasadenia vášho produktu môžete zlepšiť použitím vlastných kontrol zdravého rozumu.
Našťastie, Kubernetes to robí celkom jednoducho, takže neexistuje žiadne ospravedlnenie pre ignorovanie týchto kontrol. Kubernetes poskytuje dva typy zdravotných kontrol a je dôležité pochopiť rozdiely v tom, ako sa každý používa.
Test pripravenosti je navrhnutý tak, aby povedal Kubernetes, že vaša aplikácia je pripravená zvládnuť prevádzku. Pred povolením služby odosielať návštevnosť do modulu musí Kubernetes overiť, či je kontrola pripravenosti úspešná. Ak test pripravenosti zlyhá, Kubernetes prestane odosielať prenosy do modulu, kým test neprejde.
Test životnosti povie Kubernetes, či je vaša aplikácia živá alebo mŕtva. V prvom prípade ho Kubernetes nechá na pokoji, v druhom vymaže mŕtvy modul a nahradí ho novým.
Predstavme si scenár, že vašej aplikácii trvá zahriatie a spustenie 1 minútu. Vaša služba nezačne fungovať, kým nebude aplikácia úplne načítaná a spustená, hoci pracovný postup sa už spustil. Problémy budete mať aj vtedy, ak budete chcieť toto nasadenie zväčšiť na viacero kópií, pretože tieto kópie by nemali prijímať návštevnosť, kým nebudú úplne pripravené. V predvolenom nastavení však Kubernetes začne odosielať prenos hneď, ako začnú procesy v kontajneri.
Pri použití testu pripravenosti Kubernetes počká, kým sa aplikácia úplne nespustí, a až potom povolí službe odosielať návštevnosť do novej kópie.
Predstavme si iný scenár, v ktorom aplikácia dlho visí a prestáva obsluhovať požiadavky. Ako proces pokračuje, Kubernetes bude v predvolenom nastavení predpokladať, že je všetko v poriadku a bude pokračovať v odosielaní požiadaviek do nefunkčného modulu. Pri používaní Liveness však Kubernetes zistí, že aplikácia už nevybavuje požiadavky a predvolene reštartuje mŕtvy modul.
Pozrime sa, ako sa testuje pripravenosť a životaschopnosť. Existujú tri metódy testovania – HTTP, Command a TCP. Na kontrolu môžete použiť ktorýkoľvek z nich. Najbežnejším spôsobom testovania používateľa je sonda HTTP.
Aj keď vaša aplikácia nie je HTTP server, stále môžete vo svojej aplikácii vytvoriť ľahký HTTP server na interakciu s testom živosti. Potom Kubernetes začne testovať modul ping a ak je odpoveď HTTP v rozsahu 200 alebo 300 ms, bude to znamenať, že modul je v poriadku. V opačnom prípade bude modul označený ako „nezdravý“.
Pre testy príkazov spustí Kubernetes príkaz vo vašom kontajneri. Ak sa príkaz vráti s nulovým výstupným kódom, kontajner bude označený ako zdravý, v opačnom prípade po prijatí čísla stavu odchodu od 1 do 255 bude kontajner označený ako „chorý“. Táto testovacia metóda je užitočná, ak nemôžete alebo nechcete spustiť HTTP server, ale dokážete spustiť príkaz, ktorý skontroluje stav vašej aplikácie.
Posledným overovacím mechanizmom je test TCP. Kubernetes sa pokúsi nadviazať TCP spojenie na zadanom porte. Ak je to možné, nádoba sa považuje za zdravú, ak nie, považuje sa za neživotaschopnú. Táto metóda môže byť užitočná, ak používate scenár, kde testovanie s požiadavkou HTTP alebo vykonaním príkazu nefunguje veľmi dobre. Napríklad hlavné služby na overenie pomocou TCP by boli gRPC alebo FTP.
Testy je možné konfigurovať niekoľkými spôsobmi s rôznymi parametrami. Môžete určiť, ako často sa majú vykonávať, aké sú prahové hodnoty úspechu a zlyhania a ako dlho čakať na odpovede. Ďalšie informácie nájdete v dokumentácii k testom pripravenosti a životnosti. Pri nastavovaní testu Liveness je však jeden veľmi dôležitý bod – počiatočné nastavenie oneskorenia testovania initialDelaySeconds. Ako som už spomenul, zlyhanie tohto testu bude mať za následok reštart modulu. Musíte sa teda uistiť, že testovanie sa nespustí, kým nebude aplikácia pripravená na spustenie, inak sa začne cyklicky reštartovať. Odporúčam použiť čas spustenia P99 alebo priemerný čas spustenia aplikácie z vyrovnávacej pamäte. Nezabudnite upraviť túto hodnotu, pretože čas spustenia vašej aplikácie bude rýchlejší alebo pomalší.
Väčšina odborníkov potvrdí, že zdravotné kontroly sú povinnou kontrolou každého distribuovaného systému a Kubernetes nie je výnimkou. Používanie kontrol stavu služieb zaisťuje spoľahlivú, bezproblémovú prevádzku Kubernetes a je pre používateľov jednoduché.
Pokračovanie už čoskoro...
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com