Probe živosti u Kubernetesu mogu biti opasne

Bilješka. transl.: Vodeći inženjer iz Zalanda, Henning Jacobs, više puta je primijetio probleme među korisnicima Kubernetesa u razumijevanju svrhe sondi za životnost (i spremnost) i njihove pravilne upotrebe. Stoga je svoje misli sabrao u ovoj opširnoj bilješki, koja će s vremenom postati dio dokumentacije K8s.

Zdravstveni pregledi, poznati u Kubernetesu kao sonde za živost (tj. doslovno, “testovi održivosti” - pribl. prevod), može biti prilično opasno. Preporučujem da ih izbjegavate ako je moguće: izuzeci su samo kada su zaista neophodni i kada ste potpuno svjesni specifičnosti i posljedica njihove upotrebe. Ova publikacija će govoriti o provjerama životnosti i spremnosti, a također će vam reći u kojim slučajevima vrijedi i ne bi trebalo da ih koristite.

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

Neispravno konfigurisano livenessProbe može pogoršati situacije visokog opterećenja (gašenje grudve snijega + potencijalno dugo vrijeme pokretanja spremnika/aplikacije) i dovesti do drugih negativnih posljedica kao što je pad ovisnosti (vidi takođe moj nedavni članak o ograničavanju broja zahtjeva u kombinaciji K3s+ACME). Još je gore kada se sonda živosti kombinira sa zdravstvenim pregledom, koji je vanjska baza podataka: jedan DB kvar će ponovo pokrenuti sve vaše kontejnere!

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

Napomena: Većina donjeg testa je prvobitno bila uključena u Zalandovu internu dokumentaciju za programere.

Provjere spremnosti i životnosti

Kubernetes pruža dva važna mehanizma tzv sonde za životnost i sonde za spremnost. Oni povremeno izvode neku radnju—kao što je slanje HTTP zahtjeva, otvaranje TCP veze ili izvršavanje naredbe u kontejneru—kako bi potvrdili da aplikacija radi kako se očekuje.

Kubernetes koristi sonde za spremnostda shvati kada je kontejner spreman da prihvati saobraćaj. Mahuna se smatra spremnom za upotrebu ako su svi njeni spremnici spremni. Jedna upotreba ovog mehanizma je kontrola koji se podovi koriste kao pozadine za Kubernetes usluge (a posebno Ingress).

Sonde za živost pomozite Kubernetesu da shvati kada je vrijeme za ponovno pokretanje kontejnera. Na primjer, takva provjera vam omogućava da presretnete zastoj kada se aplikacija zaglavi na jednom mjestu. Ponovno pokretanje kontejnera u ovom stanju pomaže da se aplikacija pokrene uprkos greškama, ali može dovesti i 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:

Evo primjera sonde spremnosti koja provjerava putanju /health preko HTTP-a sa zadanim postavkama (interval: 10 sekundi, vrijeme je isteklo: 1 sekunda, prag uspjeha: 1, prag kvara: 3):

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

preporuke

1. Za mikroservise sa HTTP krajnjom tačkom (REST, itd.) uvijek definirajte sondu spremnosti, koji provjerava da li je aplikacija (pod) spremna da prihvati promet.
2. Provjerite je li sonda spremnosti pokriva dostupnost stvarnog porta web servera:
   • korištenje portova u administrativne svrhe, nazvane "admin" ili "management" (na primjer, 9090), za readinessProbe, uverite se da krajnja tačka samo vraća OK ako je primarni HTTP port (kao 8080) spreman da prihvati saobraćaj*;

     * Poznat mi je barem jedan slučaj u Zalandu gdje se to nije dogodilo, tj. readinessProbe Provjerio sam "management" port, ali sam server nije počeo da radi zbog problema sa učitavanjem keša.

   • priključivanje sonde spremnosti na poseban port može dovesti do činjenice da se preopterećenje glavnog porta neće odraziti na provjeru zdravlja (odnosno, spremište niti na serveru je puno, ali provjera zdravlja i dalje pokazuje da je sve u redu ).
3. Budi siguran da sonda spremnosti omogućava inicijalizaciju/migraciju baze podataka;
   • Najlakši način da se to postigne je da kontaktirate HTTP server tek nakon što je inicijalizacija završena (na primjer, migracija baze podataka iz Flyway i tako dalje.); odnosno, umjesto da promijenite status provjere zdravlja, jednostavno nemojte pokretati web server dok se migracija baze podataka ne završi*.

     * Također možete pokrenuti migracije baze podataka iz init kontejnera izvan pod. I dalje sam ljubitelj samostalnih aplikacija, odnosno onih u kojima kontejner aplikacije zna da dovede bazu podataka u željeno stanje bez vanjske koordinacije.

4. Koristite httpGet za provjere spremnosti kroz tipične krajnje tačke zdravstvene provjere (na primjer, /health).
5. Razumjeti zadane parametre provjere (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • zadane opcije znače da će pod postati nije spreman nakon otprilike 30 sekundi (3 neuspjele provjere uračunljivosti).
6. Koristite zaseban port za "admin" ili "upravljanje" ako tehnološki stog (npr. Java/Spring) to dozvoljava, da odvojite upravljanje zdravljem i metrikom od redovnog saobraćaja:
   • ali ne zaboravite na tačku 2.
7. Ako je potrebno, sonda spremnosti se može koristiti za zagrijavanje/učitavanje keša i vraćanje statusnog koda 503 dok se spremnik ne zagrije:
   • Također preporučujem da pročitate novi ček startupProbe, pojavio u verziji 1.16 (pisali smo o tome na ruskom ovdje - cca. prevod).

Opomene

1. Nemojte se oslanjati na vanjske zavisnosti (kao što su skladišta podataka) kada se izvode testovi spremnosti/živosti - to može dovesti do kaskadnih kvarova:
   • Kao primjer, uzmimo REST uslugu sa stanjem sa 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 tako sve se završava gore nego što bi moglo;
   • Imajte na umu da Spring Data provjerava vezu s bazom podataka po defaultu*;

     * Ovo je podrazumevano ponašanje Spring Data Redis-a (barem je to bio poslednji put da sam proverio), što je dovelo do "katastrofalnog" kvara: kada je Redis kratko vreme bio nedostupan, svi podovi su se "srušili".

   • “spoljašnji” u ovom smislu može značiti i druge podove iste aplikacije, odnosno u idealnom slučaju provjera ne bi trebala ovisiti o stanju drugih modula istog klastera kako bi se spriječila kaskadna rušenja:
     • rezultati se mogu razlikovati za aplikacije s distribuiranim stanjem (na primjer, keširanje u memoriji u podovima).
2. Nemojte koristiti sondu za živost za mahune (izuzetak su slučajevi kada su zaista neophodne i kada ste potpuno svjesni specifičnosti i posljedica njihove upotrebe):
   • Proba za živost može pomoći da se oporave obješeni kontejneri, ali budući da imate potpunu kontrolu nad svojom aplikacijom, stvari kao što su obješeni procesi i zastoji u idealnom slučaju ne bi se trebali događati: najbolja alternativa je namjerno srušiti aplikaciju i vratiti je u prethodno stabilno stanje;
   • neuspješna sonda životnosti dovest će do ponovnog pokretanja spremnika, što potencijalno može pogoršati posljedice grešaka povezanih s učitavanjem: ponovno pokretanje spremnika rezultirat će prekidom rada (barem za vrijeme trajanja pokretanja aplikacije, recimo 30-ak sekundi), uzrokujući nove greške , povećanje opterećenja drugih kontejnera i povećanje vjerovatnoće njihovog kvara, itd.;
   • provjere živosti u kombinaciji s vanjskom ovisnošću su najgora moguća kombinacija, prijeteći kaskadnim kvarovima: malo kašnjenje na strani baze podataka će dovesti do ponovnog pokretanja svih vaših kontejnera!
3. Provjere parametara životnosti i spremnosti mora biti drugačiji:
   • možete koristiti sondu za živost sa istim zdravstvenim pregledom, ali višim pragom odziva (failureThreshold), na primjer, dodijelite status nije spreman nakon 3 pokušaja i smatrati da je sonda živosti neuspješna nakon 10 pokušaja;
4. Nemojte koristiti exec provjere, budući da su povezani s poznatim problemima koji dovode do pojave zombi procesa:
   • detalji: vidi prezentacija stručnjaka Datadog-a.

Rezime

• Koristite sonde spremnosti da odredite kada je podna jedinica spremna da primi promet.
• Koristite sonde za živost samo kada su zaista potrebne.
• Nepravilna upotreba sondi spremnosti/živosti može dovesti do smanjene dostupnosti i kaskadnih kvarova.

Dodatni materijali na tu temu

• Kubernetes dokumenti: Konfigurirajte probe za živost i spremnost;
• Revidirani Kubernetesovi testovi za živost i spremnost: kako izbjeći pucanje u drugu nogu;
• NRE Labs Outage Post- Mortem (on takođe govori o livenessProbe).

Ažuriranje br. 1 od 2019

O init kontejnerima za migraciju baze podataka: Fusnota dodana.

EJ me podsjetio o PDB-u: jedan od problema s provjerama živosti je nedostatak koordinacije između mahuna. Kubernetes ima Budžeti za poremećaje (PDB) ograničiti broj istovremenih 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 "Ponovo pokreni jedan pod ako njegov test ne uspije, ali nemoj ih ponovo pokrenuti sve da ne bi pogoršao stvari."

Bryan je to savršeno izrazio: „Koristite sondiranje živosti kada tačno znate šta najbolja stvar koju možete učiniti je ubiti aplikaciju(još jednom, nemojte se zanositi).

Ažuriranje br. 2 od 2019

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

PS od prevodioca

Pročitajte i na našem blogu:

• «Kubernetes: Pod Life»;
• «7 najboljih praksi za korištenje kontejnera prema Google-u»;
• «7 principa za dizajniranje aplikacija zasnovanih na kontejnerima".

izvor: www.habr.com