🥇Sonde živosti u Kubernetesu mogu biti opasne

Bilješka. prev.: Vodeći inženjer iz Zalanda, Henning Jacobs, opetovano je primijetio probleme među korisnicima Kubernetesa u razumijevanju svrhe sondi živosti (i spremnosti) i njihove ispravne upotrebe. Stoga je svoje misli sabrao u ovu prostranu bilješku, koja će s vremenom postati dio dokumentacije K8s.

Provjere zdravlja, poznate u Kubernetesu kao sonde živosti (tj. doslovno "testovi održivosti" - pribl. prijevod), može biti vrlo opasno. Preporučam da ih izbjegavate ako je moguće: iznimke su samo kada su uistinu nužni i u potpunosti ste svjesni specifičnosti i posljedica njihove uporabe. Ova publikacija će govoriti o provjerama živosti i spremnosti, a također će vam reći u kojim slučajevima Trošak i ne biste ih trebali koristiti.

Moj kolega Sandor nedavno je na Twitteru podijelio najčešće pogreške s kojima se susreće, uključujući one koje se odnose na korištenje sondi spremnosti/životnosti:

Neispravno konfigurirano livenessProbe može pogoršati situacije s velikim opterećenjem (gašenje snowload-a + potencijalno dugo vrijeme pokretanja spremnika/aplikacije) i dovesti do drugih negativnih posljedica kao što je pad ovisnosti (vidi također moj nedavni članak o ograničavanju broja zahtjeva u kombinaciji K3s+ACME). Još je gore kada se sonda živosti kombinira s provjerom zdravlja, što je vanjska baza podataka: jedan kvar DB-a ponovno će pokrenuti sve vaše spremnike!

Opća poruka "Nemojte koristiti sonde za živost" u ovom slučaju to ne pomaže puno, pa pogledajmo čemu služe provjere spremnosti i živosti.

Napomena: većina testa u nastavku izvorno je uključena u Zalandovu internu dokumentaciju za razvojne programere.

Provjere spremnosti i živosti

Kubernetes pruža dva važna mehanizma tzv sonde živosti i sonde spremnosti. Oni povremeno izvode neke radnje - kao što je slanje HTTP zahtjeva, otvaranje TCP veze ili izvršavanje naredbe u spremniku - kako bi potvrdili da aplikacija radi prema očekivanjima.

Kubernetes koristi sonde za spremnostkako bi razumjeli kada je kontejner spreman prihvatiti promet. Mahuna se smatra spremnom za upotrebu ako su svi njezini spremnici spremni. Jedna upotreba ovog mehanizma je kontrolirati koji se podovi koriste kao pozadina za Kubernetes usluge (a posebno Ingress).

Sonde za živost pomoći Kubernetesu da shvati kada je vrijeme za ponovno pokretanje spremnika. Na primjer, takva vam provjera omogućuje presretanje zastoja kada aplikacija zapne na jednom mjestu. Ponovno pokretanje spremnika u ovom stanju pomaže u pokretanju aplikacije unatoč pogreškama, ali također može dovesti do kaskadnih kvarova (pogledajte dolje).

Ako pokušate implementirati ažuriranje aplikacije koje ne prođe provjere živosti/spremnosti, njegovo uvođenje će biti zaustavljeno dok Kubernetes čeka status Ready iz svih mahuna.

Primjer

Ovdje je primjer sonde spremnosti koja provjerava put /health putem HTTP-a sa zadanim postavkama (interval: 10 sekundi, tajm-aut: 1 sekunda, prag uspješnosti: 1, prag neuspjeha: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Preporuke

Za mikroservise s HTTP krajnjom točkom (REST, itd.) uvijek definirajte sondu spremnosti, koji provjerava je li aplikacija (pod) spremna prihvatiti promet.
Provjerite spremnost sonde pokriva dostupnost stvarnog porta web poslužitelja:
- korištenje portova u administrativne svrhe, nazvane "admin" ili "management" (na primjer, 9090), za readinessProbe, pobrinite se da krajnja točka vraća OK samo ako je primarni HTTP port (poput 8080) spreman prihvatiti promet*;
  *Znam za barem jedan slučaj u Zalandu gdje se to nije dogodilo, tj. readinessProbe Provjerio sam "upravljački" priključak, ali sam poslužitelj nije počeo raditi zbog problema s učitavanjem predmemorije.
- pričvršćivanje sonde spremnosti na zasebni port može dovesti do činjenice da se preopterećenje na glavnom portu neće odraziti na provjeru zdravlja (odnosno, skup niti na poslužitelju je pun, ali provjera zdravlja i dalje pokazuje da je sve u redu ).
Uvjerite se u to sonda spremnosti omogućuje inicijalizaciju/migraciju baze podataka;
- Najlakši način da to postignete je kontaktirati HTTP poslužitelj tek nakon dovršetka inicijalizacije (na primjer, migracija baze podataka iz Flyway i tako dalje.); to jest, umjesto promjene statusa provjere zdravlja, jednostavno nemojte pokretati web poslužitelj dok se migracija baze podataka ne završi*.
  * Također možete pokrenuti migracije baze podataka iz init spremnika izvan modula. I dalje sam ljubitelj self-contained aplikacija, odnosno onih u kojima kontejner aplikacije zna bez vanjske koordinacije dovesti bazu u željeno stanje.
upotreba httpGet za provjere spremnosti kroz tipične krajnje točke provjere zdravlja (na primjer, /health).
Razumijevanje zadanih parametara provjere (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- zadane opcije znače da će mahuna postati nije spreman nakon otprilike 30 sekundi (3 neuspjele provjere ispravnosti).
Upotrijebite zaseban priključak za "admin" ili "management" ako tehnološki skup (npr. Java/Spring) to dopušta, kako biste odvojili upravljanje zdravljem i metrikom od redovnog prometa:
- ali ne zaboravite točku 2.
Ako je potrebno, sonda spremnosti može se koristiti za zagrijavanje/učitavanje predmemorije i vraćanje statusnog koda 503 dok se spremnik ne zagrije:
- Također preporučujem da pročitate novi ček startupProbe, pojavio se u verziji 1.16 (pisali smo o tome na ruskom здесь - cca. prev.).

Mjere opreza

Nemojte se oslanjati na vanjske ovisnosti (kao što su skladišta podataka) prilikom izvođenja testova spremnosti/životnosti - to može dovesti do kaskadnih kvarova:
- Kao primjer, uzmimo REST uslugu s praćenjem stanja s 10 podova ovisno o jednoj Postgres bazi podataka: kada provjera ovisi o radnoj vezi s DB-om, svih 10 podova može propasti ako postoji kašnjenje na strani mreže/DB - obično je sve završava gore nego što bi moglo;
- Imajte na umu da Spring Data prema zadanim postavkama provjerava vezu s bazom podataka*;
  * Ovo je zadano ponašanje Spring Data Redisa (barem je bilo zadnji put kad sam provjerio), što je dovelo do "katastrofalnog" kvara: kada je Redis kratko vrijeme bio nedostupan, sve su se mahune "srušile".
- "vanjski" u ovom smislu također može značiti druge module iste aplikacije, to jest, idealno provjera ne bi trebala ovisiti o stanju drugih modula istog klastera kako bi se spriječilo kaskadno rušenje:
  - rezultati mogu varirati za aplikacije s distribuiranim stanjem (na primjer, predmemoriranje u memoriji u modulima).
Ne koristite sondu za život za mahune (iznimka su slučajevi kada su stvarno nužni i u potpunosti ste upoznati sa specifičnostima i posljedicama njihove uporabe):
- Proba živosti može pomoći u oporavku obješenih spremnika, ali budući da imate potpunu kontrolu nad svojom aplikacijom, stvari poput suspendiranih procesa i zastoja u idealnom slučaju ne bi se trebale dogoditi: najbolja alternativa je namjerno srušiti aplikaciju i vratiti je u prethodno stabilno stanje;
- neuspješna sonda živosti uzrokovat će ponovno pokretanje spremnika, čime se potencijalno pogoršavaju posljedice pogrešaka povezanih s učitavanjem: ponovno pokretanje spremnika rezultirat će prekidom rada (barem tijekom trajanja pokretanja aplikacije, recimo 30-ak sekundi), uzrokujući nove pogreške , povećanje opterećenja na druge spremnike i povećanje vjerojatnosti njihovog kvara itd.;
- provjere živosti u kombinaciji s vanjskom ovisnošću najgora su moguća kombinacija, koja prijeti kaskadnim kvarovima: malo kašnjenje na strani baze podataka dovest će do ponovnog pokretanja svih vaših spremnika!
Parametri provjere živosti i spremnosti mora biti drugačiji:
- možete koristiti sondu živosti s istom provjerom zdravlja, ali višim pragom odgovora (failureThreshold), na primjer, dodijelite status nije spreman nakon 3 pokušaja i smatrajte da sonda živosti nije uspjela nakon 10 pokušaja;
Nemojte koristiti izvršne provjere, jer su povezani s poznatim problemima koji dovode do pojave zombi procesa:
- detalji: vidi prezentacija Datadog stručnjaka.

Rezime

Upotrijebite sonde spremnosti da odredite kada je jedinica spremna za primanje prometa.
Koristite sonde za živost samo kada su stvarno potrebne.
Nepravilna uporaba sondi spremnosti/životnosti može dovesti do smanjene dostupnosti i kaskadnih kvarova.

Dodatni materijali na tu temu

Kubernetes dokumenti: Konfigurirajte sonde živosti i spremnosti;
Ponovno razmatranje Kubernetesovih sondi živosti i spremnosti: Kako izbjeći pucanje sebi u drugu nogu;
Ispad laboratorija NRE post-mortem (on također govori o livenessProbe).

Ažuriranje br. 1 od 2019

O init spremnicima za migraciju baze podataka: Dodana fusnota.

EJ me podsjetio o PDB-u: jedan od problema s provjerama živosti je nedostatak koordinacije između mahuna. Kubernetes ima Proračuni ometanja blokova (PDB) kako bi se ograničio broj istodobnih kvarova koje aplikacija može doživjeti, međutim provjere ne uzimaju u obzir PDB. U idealnom slučaju, mogli bismo reći K8s da "ponovno pokreni jednu jedinicu ako test ne uspije, ali ih nemoj ponovno pokrenuti sve da ne pogoršaš stvari."

Bryan je to savršeno izrazio: “Upotrijebite ispitivanje živosti kada točno znate što najbolja stvar za učiniti je ubiti aplikaciju"(opet, nemojte se zanositi).

Ažuriranje br. 2 od 2019

Što se tiče čitanja dokumentacije prije uporabe: Kreirao sam odgovarajući zahtjev (zahtjev za značajku) za dodavanje dokumentacije o sondama živosti.

PS od prevoditelja

Pročitajte i na našem blogu:

Izvor: www.habr.com

Probe živosti u Kubernetesu mogu biti opasne