S distribuovanými systémami môže byť ťažké manipulovať, pretože obsahujú množstvo pohyblivých a meniacich sa prvkov, ktoré musia správne fungovať na zabezpečenie funkčnosti systému. Ak jeden z prvkov zlyhá, systém ho musí identifikovať, obísť a opraviť, a to všetko automaticky. V tejto sérii „Kubernetes Best Practices“ sa naučíme, ako nastaviť testy Readiness a Liveness na overenie životaschopnosti Kubernetes klastra.
Kontrola zdravia Health Check je jednoduchý spôsob, ako dať systému vedieť, či je inštancia vašej aplikácie aktívna alebo nie. Ak inštancia vašej aplikácie nepracuje, ostatné služby by sa na ňu nemali obracať alebo zasielať jej požiadavky. Namiesto toho by mala byť požiadavka zaslaná inej inštancii aplikácie, ktorá je už spustená alebo sa spustí neskôr. Okrem toho by systém mal vrátiť vašej aplikácii stratenú funkčnosť.
Predvolene Kubernetes začne posielať prevádzku do podu, keď sú všetky kontajnery v rámci podov spustené, a znovu spúšťať kontajnery, keď zlyhajú. Na začiatku môže byť toto správanie systému dostatočne dobré, avšak môžete zvýšiť spoľahlivosť nasadenia svojho produktu použitím vlastných testov zdravia.
Našťastie Kubernetes umožňuje dosiahnuť tieto ciele veľmi jednoducho, takže ignorovanie takýchto kontrol nemá žiadne ospravedlnenie. Kubernetes poskytuje dva typy testov Health Check a je dôležité pochopiť rozdiely v aplikácii každého z nich.
Test pripravenosti Readiness slúži na to, aby informoval Kubernetes o pripravenosti vašej aplikácie obsluhovať prevádzku. Predtým, ako povolí službe posielať prevádzku do podu, musí Kubernetes overiť úspešnosť testu pripravenosti. Ak test Readiness zlyhá, Kubernetes prestane posielať prevádzku do podu, kým testovanie neprejde úspešne.
Test životaschopnosti Liveness informuje Kubernetes, či je vaše aplikácie živé alebo mŕtve. V prvom prípade Kubernetes ho ponechá na pokoji, v druhom odstráni mŕtvy pod a nahradí ho novým.
Predstavte si scenár, v ktorom vášmu aplikácii na "naštartovanie" a spustenie trvá 1 minútu. Vaša služba nezačne pracovať, pokiaľ aplikácia nie je úplne načítaná a spustená, aj keď pracovný proces už začal. Navyše sa môžu vyskytnúť problémy, ak sa rozhodnete rozšíriť toto nasadenie na niekoľko kópií, pretože tieto kópie by nemali prijímať prevádzku, kým nebudú úplne pripravené. Avšak vo východziom nastavení Kubernetes začne posielať prevádzku ihneď po začatí procesov vo vnútri kontajnera.
Pri použití testu pripravenosti Readiness bude Kubernetes čakať, kým bude aplikácia úplne spustená, a až potom umožní službe posielať prevádzku na novú kópiu.
Predstavte si iný scenár, v ktorom aplikácia visí dlhú dobu a prestáva obsluhovať požiadavky. Keďže proces pokračuje v behu, Kubernetes predpokladá, že všetko je v poriadku a pokračuje v posielaní požiadaviek na nefunkčný pod. Avšak pri použití Liveness Kubernetes zistí, že aplikácia viac neobsluhuje požiadavky, a vo východzom nastavení reštartuje nefunkčný pod.
Pozrime sa na to, ako sa testuje pripravenosť a životaschopnosť. Existujú tri spôsoby testovania — HTTP, Command a TCP. Na overenie môžete použiť ktorýkoľvek z nich. Najbežnejšou metódou používateľského testu je HTTP probe.
Aj keď vaša aplikácia nie je HTTP-server, môžete vo svojej aplikácii vytvoriť ľahký HTTP-server na interakciu s testom Liveness. Následne Kubernetes začne pingiť pod a ak HTTP odpoveď bude vo vnútri rozsahu 200 alebo 300 ms, to znamená, že pod je "zdravý". V opačnom prípade bude jednotka označená ako "nezdravá".
Pre testy pomocou Command Kubernetes vykonáva príkaz vo vnútri vášho kontajnera. Ak sa príkaz vracia s nulovým exit kódom, kontajner sa označí ako zdravý, inak, pri získaní čísla exit status od 1 do 255, sa kontajner označí ako "chorý". Tento spôsob testovania je užitočný, ak nemôžete alebo nechcete spustiť HTTP-server, ale môžete spustiť príkaz, ktorý skontroluje "zdravie" vašej aplikácie.
Posledný mechanizmus kontroly je test TCP. Kubernetes sa pokúsi nadviazať TCP spojenie na určenom porte. Ak sa to podarí, kontajner sa považuje za zdravý, ak nie – za nefunkčný. Tento spôsob sa môže hodiť, ak používate scenár, kde testovanie pomocou HTTP požiadavky alebo vykonanie príkazu nefunguje dobre. Napríklad hlavnými službami na kontrolu pomocou TCP budú gRPC alebo FTP.
Testy je možné nastaviť viacerými spôsobmi s rôznymi parametrami. Môžete určiť, ako často sa majú vykonávať, aké sú hraničné hodnoty úspechu a neúspechu, a ako dlho čakať na odpovede. Podrobnejšie informácie sú uvedené v dokumentácii k testom Readiness a Liveness. Existuje však jeden veľmi dôležitý aspekt nastavenia testu Liveness – počiatočné nastavenie oneskorenia testovania initialDelaySeconds. Ako som spomínal, neúspešné vykonanie tohto testu povedie k reštartu modulu. Preto sa musíte uistiť, že testovanie sa nezačne, kým aplikácia nebude pripravená na prácu, inak sa začne cyklicky reštartovať. Odporúčam použiť čas startupu P99 alebo priemerný čas spustenia aplikácie zo schránky. Nezabudnite upraviť túto hodnotu, keď sa čas spustenia vašej aplikácie zvyšuje alebo znižuje.
Väčšina odborníkov potvrdí, že Health Check je povinnou kontrolou pre akýkoľvek distribuovaný systém a Kubernetes nie je výnimkou. Používanie kontroly „zdravia“ služieb zabezpečuje spoľahlivú a bezporuchovú prevádzku Kubernetes a pre používateľov je to bez námahy.
Pokračovanie čoskoro ...
Trochu reklamy 🙂
Ďakujeme, že ostávate s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavých materiálov? Podporte nás, vytvorením objednávky alebo odporúčaním známym, , unikátny ekvivalent entry-level serverov, ktorý sme pre vás vytvorili: (k dispozícii varianty s RAID1 a RAID10, až 24 jadier a až 40GB DDR4).
Dell R730xd je dvakrát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len u nás v Holandsku! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolárov! Prečítajte si o tom
Zdroj: habr.com
