Dôležitým bodom pri prevádzke distribuovaných systémov je odstraňovanie porúch. Kubernetes s tým pomáha pomocou ovládačov, ktoré monitorujú stav vášho systému a reštartujú služby, ktoré prestali fungovať. Kubernetes však môže násilne zastaviť vaše aplikácie, aby zabezpečil celkové zdravie systému. V tejto sérii sa pozrieme na to, ako môžete pomôcť Kubernetes vykonávať svoju prácu efektívnejšie a znížiť prestoje aplikácií.
Pred kontajnermi väčšina aplikácií bežala na virtuálnych alebo fyzických počítačoch. Ak aplikácia spadla alebo zamrzla, zrušenie prebiehajúcej úlohy a opätovné načítanie programu trvalo dlho. V najhoršom prípade musel tento problém niekto riešiť ručne v noci, v najnevhodnejšiu hodinu. Ak dôležitú úlohu vykonávali iba 1-2 pracovné stroje, takéto rušenie bolo úplne neprijateľné.
Preto namiesto manuálneho reštartu začali používať monitorovanie na úrovni procesu na automatické reštartovanie aplikácie v prípade abnormálneho ukončenia. Ak program zlyhá, monitorovací proces zachytí ukončovací kód a reštartuje server. S príchodom systémov ako Kubernetes bol tento typ reakcie na zlyhania systému jednoducho integrovaný do infraštruktúry.
Kubernetes používa slučku udalostí pozorovania-rozdiel-prijmite-akciu, aby sa zabezpečilo, že zdroje zostanú zdravé, keď prechádzajú z kontajnerov do samotných uzlov.
To znamená, že už nemusíte manuálne spúšťať monitorovanie procesov. Ak zdroj neprejde kontrolou stavu, Kubernetes mu jednoducho automaticky poskytne náhradu. Kubernetes však robí oveľa viac, než len monitoruje zlyhanie vašej aplikácie. Môže vytvoriť viac kópií aplikácie na spustenie na viacerých počítačoch, aktualizovať aplikáciu alebo spustiť viacero verzií vašej aplikácie súčasne.
Preto existuje veľa dôvodov, prečo môže Kubernetes ukončiť úplne zdravý kontajner. Ak napríklad upgradujete svoje nasadenie, Kubernetes pomaly zastaví staré moduly a zároveň spustí nové. Ak uzol vypnete, Kubernetes prestane spúšťať všetky moduly v tomto uzle. Nakoniec, ak sa uzlu vyčerpajú zdroje, Kubernetes vypne všetky moduly, aby uvoľnil tieto zdroje.
Preto je dôležité, aby sa vaša aplikácia ukončila s minimálnym dopadom na koncového používateľa a minimálnym časom obnovy. To znamená, že pred vypnutím musí uložiť všetky údaje, ktoré je potrebné uložiť, uzavrieť všetky sieťové pripojenia, dokončiť zostávajúcu prácu a zvládnuť ďalšie naliehavé úlohy.
V praxi to znamená, že vaša aplikácia musí byť schopná spracovať správu SIGTERM, signál ukončenia procesu, ktorý je predvoleným signálom pre utilitu kill na operačných systémoch Unix. Po prijatí tejto správy by sa aplikácia mala vypnúť.
Keď sa Kubernetes rozhodne ukončiť modul, dôjde k niekoľkým udalostiam. Pozrime sa na každý krok, ktorý Kubernetes vykoná pri vypínaní kontajnera alebo pod.
Povedzme, že chceme ukončiť jeden z modulov. V tomto momente prestane prijímať novú premávku – kontajnery bežiace v podu nebudú ovplyvnené, ale všetka nová premávka bude zablokovaná.
Pozrime sa na hák preStop, čo je špeciálny príkaz alebo požiadavka HTTP, ktorá sa odosiela do kontajnerov v pod. Ak sa vaša aplikácia nevypne správne pri prijatí SIGTERM, môžete použiť preStop na správne vypnutie.
Väčšina programov sa elegantne ukončí, keď dostanú signál SIGTERM, ale ak používate kód tretej strany alebo nejaký systém, ktorý úplne neovládate, hák preStop je skvelý spôsob, ako si vynútiť elegantné vypnutie bez zmeny aplikácie.
Po vykonaní tohto háku Kubernetes odošle signál SIGTERM do kontajnerov v podu, čím im dá vedieť, že budú čoskoro odpojené. Po prijatí tohto signálu váš kód prejde do procesu vypnutia. Tento proces môže zahŕňať zastavenie akýchkoľvek pripojení s dlhou životnosťou, ako je pripojenie k databáze alebo stream WebSocket, uloženie aktuálneho stavu a podobne.
Aj keď používate preStop hook, je veľmi dôležité skontrolovať, čo presne sa stane s vašou aplikáciou, keď do nej pošlete signál SIGTERM, a ako sa správa, aby udalosti alebo zmeny v prevádzke systému spôsobené vypnutím modulu nenastali. prekvapenie pre teba.
V tomto bode bude Kubernetes čakať určitý čas, ktorý sa nazýva terminationGracePeriodSecond, alebo obdobie, počas ktorého sa plynule vypne, keď prijme signál SIGTERM, kým podnikne ďalšie kroky.
Štandardne je toto obdobie 30 sekúnd. Je dôležité poznamenať, že prebieha paralelne s hákom preStop a signálom SIGTERM. Kubernetes nebude čakať na ukončenie háku preStop a SIGTERM – ak sa vaša aplikácia ukončí pred skončením obdobia TerminationGracePeriod, Kubernetes okamžite prejde na ďalší krok. Preto skontrolujte, či hodnota tejto periódy v sekundách nie je menšia ako čas potrebný na správne vypnutie modulu a ak presiahne 30 s, zvýšte periódu na požadovanú hodnotu v YAML. V uvedenom príklade ide o 60. roky.
A nakoniec, posledným krokom je, ak kontajnery stále bežia po ukončení GracePeriod, pošlú signál SIGKILL a budú násilne odstránené. V tomto bode Kubernetes vyčistí aj všetky ostatné objekty pod.
Kubernetes ukončuje moduly z mnohých dôvodov, takže sa uistite, že sa vaša aplikácia v každom prípade ukončí elegantne, aby ste zaistili stabilnú službu.
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