🥇Sondele de viață din Kubernetes pot fi periculoase

Notă. transl.: Inginerul principal de la Zalando, Henning Jacobs, a observat în mod repetat probleme în rândul utilizatorilor Kubernetes în înțelegerea scopului sondelor de viață (și pregătire) și a utilizării lor corecte. Prin urmare, și-a adunat gândurile în această notă încăpătoare, care va deveni în cele din urmă parte a documentației K8s.

Verificări de sănătate, cunoscute în Kubernetes ca sonde de viaţă (adică, literal, „teste de viabilitate” - aprox. traducere), poate fi destul de periculos. Vă recomand să le evitați dacă este posibil: singurele excepții sunt atunci când sunt cu adevărat necesare și sunteți pe deplin conștient de specificul și consecințele utilizării lor. Această publicație va vorbi despre controalele de viață și de pregătire și vă va spune și în ce cazuri este și nu ar trebui să le folosești.

Colegul meu Sandor a împărtășit recent pe Twitter cele mai frecvente erori pe care le întâlnește, inclusiv cele legate de utilizarea sondelor de pregătire/viciune:

Configurat incorect livenessProbe poate agrava situațiile de încărcare mare (închidere bulgăre de zăpadă + timp de pornire potențial lung al containerului/aplicației) și poate duce la alte consecințe negative, cum ar fi scăderea dependenței (Vezi si articolul meu recent despre limitarea numărului de solicitări în combinația K3s+ACME). Este și mai rău atunci când proba de viață este combinată cu o verificare a stării de sănătate, care este o bază de date externă: o singură eroare DB va reporni toate containerele dvs!

Mesaj general „Nu folosiți sonde de viață” în acest caz, nu ajută prea mult, așa că să ne uităm la ce sunt verificările de pregătire și de viață.

Notă: cea mai mare parte a testului de mai jos a fost inclusă inițial în documentația internă pentru dezvoltatori Zalando.

Verificări de pregătire și viabilitate

Kubernetes oferă două mecanisme importante numite sonde de viață și sonde de pregătire. Ei efectuează periodic anumite acțiuni - cum ar fi trimiterea unei cereri HTTP, deschiderea unei conexiuni TCP sau executarea unei comenzi în container - pentru a confirma că aplicația funcționează conform așteptărilor.

Utilizează Kubernetes sonde de pregătirepentru a înțelege când containerul este pregătit să accepte trafic. O pastă este considerată gata de utilizare dacă toate recipientele sale sunt gata. O utilizare a acestui mecanism este de a controla ce pod-uri sunt folosite ca backend-uri pentru serviciile Kubernetes (și în special Ingress).

Sonde de viață ajutați Kubernetes să înțeleagă când este timpul să reporniți containerul. De exemplu, o astfel de verificare vă permite să interceptați un impas atunci când o aplicație se blochează într-un singur loc. Repornirea containerului în această stare ajută la lansarea aplicației în ciuda erorilor, dar poate duce și la eșecuri în cascadă (vezi mai jos).

Dacă încercați să implementați o actualizare a aplicației care nu reușește verificările de viabilitate/pregătire, lansarea acesteia va fi blocată pe măsură ce Kubernetes așteaptă starea Ready din toate păstăile.

Exemplu

Iată un exemplu de sondă de pregătire care verifică o cale /health prin HTTP cu setările implicite (interval: 10 secunde, timeout: 1 secunda, pragul de succes: 1, pragul de eșec: 3):

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

Recomandări

Pentru microservicii cu punct final HTTP (REST etc.) definiți întotdeauna o sondă de pregătire, care verifică dacă aplicația (pod) este pregătită să accepte trafic.
Asigurați-vă că sonda de pregătire acoperă disponibilitatea portului actual al serverului web:
- folosind porturi în scopuri administrative, numite „admin” sau „management” (de exemplu, 9090), pentru readinessProbe, asigurați-vă că punctul final returnează OK numai dacă portul HTTP primar (cum ar fi 8080) este gata să accepte trafic*;
  *Sunt la curent cu cel puțin un caz la Zalando în care acest lucru nu s-a întâmplat, adică readinessProbe Am verificat portul de „management”, dar serverul în sine nu a început să funcționeze din cauza problemelor la încărcarea cache-ului.
- atașarea unei sonde de pregătire la un port separat poate duce la faptul că supraîncărcarea pe portul principal nu se va reflecta în verificarea de sănătate (adică pool-ul de fire de pe server este plin, dar verificarea de sănătate arată în continuare că totul este OK ).
Asigura-te ca sonda de pregătire permite inițializarea/migrarea bazei de date;
- Cel mai simplu mod de a realiza acest lucru este să contactați serverul HTTP numai după finalizarea inițializării (de exemplu, migrarea unei baze de date din Calea de zbor și așa mai departe.); adică, în loc să modificați starea verificării stării de sănătate, pur și simplu nu porniți serverul web până când migrarea bazei de date este finalizată*.
  * De asemenea, puteți rula migrări de baze de date din containere init în afara podului. Încă sunt un fan al aplicațiilor autonome, adică al celor în care containerul aplicației știe să aducă baza de date în starea dorită fără coordonare externă.
utilizare httpGet pentru verificări de pregătire prin punctele finale tipice de verificare a stării de sănătate (de exemplu, /health).
Înțelegeți parametrii de verificare impliciti (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- opțiunile implicite înseamnă că podul va deveni nu e gata după aproximativ 30 de secunde (3 verificări nereușite).
Folosiți un port separat pentru „admin” sau „management” dacă stiva de tehnologie (de exemplu, Java/Spring) o permite, pentru a separa gestionarea sănătății și a valorilor de traficul obișnuit:
- dar nu uita de punctul 2.
Dacă este necesar, sonda de pregătire poate fi utilizată pentru a încălzi/încărca memoria cache și a returna un cod de stare 503 până când containerul se încălzește:
- De asemenea, vă recomand să citiți noul cec startupProbe, a apărut în versiunea 1.16 (Am scris despre asta în rusă aici - aprox. traducere).

Măsuri de precauție

Nu vă bazați pe dependențe externe (cum ar fi depozitele de date) atunci când rulați teste de pregătire/de viață - acest lucru poate duce la eșecuri în cascadă:
- De exemplu, să luăm un serviciu REST cu 10 pod-uri în funcție de o bază de date Postgres: atunci când verificarea depinde de o conexiune funcțională la DB, toate cele 10 pod-uri pot eșua dacă există o întârziere pe partea rețelei/DB - de obicei, totul se termină mai rău decât ar putea;
- Vă rugăm să rețineți că Spring Data verifică implicit conexiunea la baza de date*;
  * Acesta este comportamentul implicit al Spring Data Redis (cel puțin a fost ultima dată când am verificat), ceea ce a dus la o eșec „catastrofal”: când Redis a fost indisponibil pentru o perioadă scurtă de timp, toate podurile „s-au prăbușit”.
- „extern” în acest sens poate însemna și alte poduri ale aceleiași aplicații, adică, în mod ideal, verificarea nu ar trebui să depindă de starea altor poduri ale aceluiași cluster pentru a preveni blocările în cascadă:
  - rezultatele pot varia pentru aplicațiile cu stare distribuită (de exemplu, stocarea în cache în memorie în pod-uri).
Nu folosiți o sondă de viață pentru păstăi (excepțiile sunt cazurile în care sunt cu adevărat necesare și sunteți pe deplin conștient de specificul și consecințele utilizării lor):
- O sondă de viață poate ajuta la recuperarea containerelor blocate, dar, deoarece aveți control deplin asupra aplicației dvs., lucruri precum procesele blocate și blocajele ar trebui să nu se întâmple: cea mai bună alternativă este să blocați aplicația în mod deliberat și să o aduceți înapoi la starea de echilibru anterioară;
- o sondă de funcționare eșuată va face ca containerul să se repornească, exacerbând astfel consecințele erorilor legate de încărcare: repornirea containerului va duce la un timp de nefuncționare (cel puțin pe durata pornirii aplicației, să zicem 30 de secunde impare), provocând noi erori. , creșterea încărcăturii pe alte containere și creșterea probabilității de defecțiune a acestora etc.;
- Verificările de viabilitate combinate cu o dependență externă sunt cea mai proastă combinație posibilă, amenințând cu eșecuri în cascadă: o ușoară întârziere din partea bazei de date va duce la repornirea tuturor containerelor!
Parametrii de verificare a vieții și a pregătirii trebuie să fie diferit:
- puteți utiliza o sondă de viață cu aceeași verificare de sănătate, dar cu un prag de răspuns mai mare (failureThreshold), de exemplu, atribuiți statutul nu e gata dupa 3 incercari si considera ca sonda de liveness a esuat dupa 10 incercari;
Nu utilizați verificări executive, deoarece sunt asociate cu probleme cunoscute care duc la apariția proceselor zombie:
- detalii: vezi prezentare de către specialiștii Datadog.

Rezumat

Utilizați sonde de pregătire pentru a determina când un pod este gata să primească trafic.
Folosiți sonde de viață numai atunci când sunt cu adevărat necesare.
Utilizarea incorectă a sondelor de pregătire/vitabilitate poate duce la o disponibilitate redusă și la defecțiuni în cascadă.

Materiale suplimentare pe tema

Documente Kubernetes: Configurați sondele Liveness și Readiness;
Sondele Kubernetes pentru viabilitate și pregătire revizuite: Cum să evitați să vă împușcați în celălalt picior;
Întreruperea laboratoarelor NRE post-mortem (vorbește și despre livenessProbe).

Actualizare nr. 1 din 2019-09-29

Despre containerele init pentru migrarea bazei de date: Notă de subsol adăugată.

mi-a amintit EJ despre PDB: una dintre problemele verificărilor de viață este lipsa de coordonare între păstăi. Kubernetes are Bugetele de întrerupere a podului (PDB) pentru a limita numărul de eșecuri concurente pe care le poate întâmpina o aplicație, totuși verificările nu țin cont de PDB. În mod ideal, am putea spune K8-urilor să „Repornească un pod dacă testul eșuează, dar nu le reporniți pe toate pentru a evita înrăutățirea situației”.

Bryan a spus-o perfect: „Folosește sondarea vieții când știi exact ce cel mai bun lucru de făcut este să omorâți aplicația„(din nou, nu te lăsa dus de cap).

Actualizare nr. 2 din 2019-09-29

În ceea ce privește citirea documentației înainte de utilizare: am creat cererea corespunzătoare (cerere de caracteristică) pentru a adăuga documentație despre sondele de viață.

PS de la traducator

Citește și pe blogul nostru:

Sursa: www.habr.com

Sondele de liveness din Kubernetes pot fi periculoase