🥇 Sondat e gjallërisë në Kubernetes mund të jenë të rrezikshme

Shënim. përkth.: Inxhinieri kryesor nga Zalando, Henning Jacobs, ka vërejtur vazhdimisht probleme midis përdoruesve të Kubernetes në kuptimin e qëllimit të sondave të gjallërisë (dhe gatishmërisë) dhe përdorimin e tyre korrekt. Prandaj, ai mblodhi mendimet e tij në këtë shënim të madh, i cili përfundimisht do të bëhet pjesë e dokumentacionit të K8s.

Kontrollet shëndetësore, të njohura në Kubernetes si sonda gjallërie (d.m.th., fjalë për fjalë, "teste qëndrueshmërie" - përafërsisht përkth.), mund të jetë mjaft i rrezikshëm. Unë rekomandoj t'i shmangni ato nëse është e mundur: përjashtimet e vetme janë kur ato janë vërtet të nevojshme dhe ju jeni plotësisht të vetëdijshëm për specifikat dhe pasojat e përdorimit të tyre. Ky botim do të flasë për kontrollet e gjallërisë dhe gatishmërisë, dhe gjithashtu do t'ju tregojë në cilat raste është dhe ju nuk duhet t'i përdorni ato.

Kohët e fundit kolegu im Sandor ndau në Twitter gabimet më të zakonshme që has, duke përfshirë ato që lidhen me përdorimin e sondave të gatishmërisë/gjallërisë:

Konfiguruar gabimisht livenessProbe mund të përkeqësojë situatat me ngarkesë të lartë (fikja e topit të borës + koha potencialisht e gjatë e nisjes së kontejnerit/aplikacionit) dhe mund të çojë në pasoja të tjera negative, si p.sh. rënia e varësisë (Shiko gjithashtu artikulli im i fundit në lidhje me kufizimin e numrit të kërkesave në kombinimin K3s+ACME). Është edhe më keq kur sonda e gjallërisë kombinohet me një kontroll shëndetësor, i cili është një bazë të dhënash e jashtme: një dështim i vetëm DB do të rinisë të gjithë kontejnerët tuaj!

Mesazh i përgjithshëm "Mos përdorni sonda gjallërie" në këtë rast nuk ndihmon shumë, kështu që le të shohim se për çfarë janë kontrollet e gatishmërisë dhe gjallërisë.

Shënim: Shumica e testit më poshtë fillimisht u përfshi në dokumentacionin e brendshëm të zhvilluesit të Zalando.

Kontrollet e gatishmërisë dhe gjallërisë

Kubernetes ofron dy mekanizma të rëndësishëm të quajtur sondat e gjallërisë dhe sondat e gatishmërisë. Ata kryejnë periodikisht disa veprime - të tilla si dërgimi i një kërkese HTTP, hapja e një lidhjeje TCP ose ekzekutimi i një komande në kontejner - për të konfirmuar që aplikacioni po funksionon siç pritej.

Kubernetes përdor sondat e gatishmërisëpër të kuptuar kur kontejneri është gati për të pranuar trafikun. Një pod konsiderohet i gatshëm për përdorim nëse të gjitha kontejnerët e tij janë gati. Një përdorim i këtij mekanizmi është të kontrollojë se cilat pods përdoren si mbështetëse për shërbimet e Kubernetes (dhe veçanërisht Ingress).

Sondat e gjallërisë ndihmoni Kubernetes të kuptojnë se kur është koha për të rifilluar kontejnerin. Për shembull, një kontroll i tillë ju lejon të kapni një bllokim kur një aplikacion ngec në një vend. Rindezja e kontejnerit në këtë gjendje ndihmon në largimin e aplikacionit pavarësisht gabimeve, por gjithashtu mund të çojë në dështime në kaskadë (shih më poshtë).

Nëse përpiqeni të vendosni një përditësim aplikacioni që dështon në kontrollet e gjallërisë/gadishmërisë, prezantimi i tij do të bllokohet ndërsa Kubernetes pret statusin Ready nga të gjitha bishtajat.

Shembull

Këtu është një shembull i një sondë gatishmërie që kontrollon një shteg /health nëpërmjet HTTP me cilësimet e paracaktuara (interval: 10 sekonda, koha e ndërprerjes: 1 sekond, pragu i suksesit: 1, pragu i dështimit: 3):

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

Rekomandime

Për mikroshërbimet me pikë fundore HTTP (REST, etj.) gjithmonë përcaktoni një hetim gatishmërie, i cili kontrollon nëse aplikacioni (pod) është gati për të pranuar trafikun.
Sigurohuni që hetimi i gatishmërisë mbulon disponueshmërinë e portës aktuale të serverit të uebit:
- duke përdorur portet për qëllime administrative, të quajtura "admin" ose "menaxhimi" (për shembull, 9090), për readinessProbe, sigurohuni që pika përfundimtare të kthehet në rregull vetëm nëse porta kryesore HTTP (si 8080) është gati për të pranuar trafikun*;
  *Jam në dijeni për të paktën një rast në Zalando ku kjo nuk ka ndodhur, d.m.th. readinessProbe Kontrollova portën e "menaxhimit", por vetë serveri nuk filloi të funksionojë për shkak të problemeve me ngarkimin e cache.
- bashkëngjitja e një sondë gatishmërie në një port të veçantë mund të çojë në faktin se mbingarkesa në portin kryesor nuk do të pasqyrohet në kontrollin shëndetësor (d.m.th., grupi i fillesave në server është plot, por kontrolli shëndetësor ende tregon se gjithçka është në rregull ).
Sigurohu hetimi i gatishmërisë mundëson inicializimin/migrimin e bazës së të dhënave;
- Mënyra më e lehtë për ta arritur këtë është të kontaktoni serverin HTTP vetëm pasi të ketë përfunduar inicializimi (për shembull, migrimi i bazës së të dhënave nga Rrugë fluturimi dhe kështu me radhë.); domethënë, në vend që të ndryshoni statusin e kontrollit shëndetësor, thjesht mos e nisni web serverin derisa të përfundojë migrimi i bazës së të dhënave*.
  * Mund të ekzekutoni gjithashtu migrime të bazës së të dhënave nga kontejnerët init jashtë pod. Unë jam ende një adhurues i aplikacioneve të pavarura, domethënë atyre në të cilat kontejneri i aplikacionit di si ta sjellë bazën e të dhënave në gjendjen e dëshiruar pa koordinim të jashtëm.
përdorim httpGet për kontrollet e gatishmërisë përmes pikave tipike përfundimtare të kontrollit shëndetësor (për shembull, /health).
Kuptoni parametrat e kontrollit të paracaktuar (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- opsionet e paracaktuara nënkuptojnë se pod do të bëhet jo gati pas rreth 30 sekondash (3 kontrolle të dështuara të shëndetit).
Përdorni një port të veçantë për "admin" ose "menaxhim" nëse grumbulli i teknologjisë (p.sh. Java/Spring) e lejon atë, për të ndarë menaxhimin e shëndetit dhe metrikës nga trafiku i rregullt:
- por mos harroni pikën 2.
Nëse është e nevojshme, sonda e gatishmërisë mund të përdoret për të ngrohur/ngarkuar cache-në dhe për të kthyer një kod statusi 503 derisa kontejneri të ngrohet:
- Unë gjithashtu ju rekomandoj që të lexoni kontrollin e ri startupProbe, u shfaq në versionin 1.16 (ne kemi shkruar për të në Rusisht këtu - përafërsisht. përkth.).

keshillon

Mos u mbështetni në varësi të jashtme (të tilla si magazinat e të dhënave) kur ekzekutohen testet e gatishmërisë / gjallërisë - kjo mund të çojë në dështime në kaskadë:
- Si shembull, le të marrim një shërbim shtetëror REST me 10 pods në varësi të një databaze të Postgres: kur kontrolli varet nga një lidhje funksionale me DB, të 10 pods mund të dështojnë nëse ka një vonesë në anën e rrjetit/DB - zakonisht gjithçka përfundon më keq se sa mund;
- Ju lutemi vini re se Spring Data kontrollon lidhjen e bazës së të dhënave si parazgjedhje*;
  * Kjo është sjellja e paracaktuar e Spring Data Redis (të paktën ishte hera e fundit që kontrollova), gjë që çoi në një dështim "katastrofik": kur Redis nuk ishte i disponueshëm për një kohë të shkurtër, të gjitha podet "u rrëzuan".
- "i jashtëm" në këtë kuptim mund të nënkuptojë gjithashtu pjesë të tjera të të njëjtit aplikacion, domethënë, në mënyrë ideale, kontrolli nuk duhet të varet nga gjendja e podeve të tjera të të njëjtit grup për të parandaluar përplasjet në kaskadë:
  - rezultatet mund të ndryshojnë për aplikacionet me gjendje të shpërndarë (për shembull, caching në memorie në pods).
Mos përdorni një sondë gjallërie për bishtajat (përjashtim bëjnë rastet kur ato janë vërtet të nevojshme dhe jeni plotësisht të vetëdijshëm për specifikat dhe pasojat e përdorimit të tyre):
- Një hetim i gjallërisë mund të ndihmojë në rikuperimin e kontejnerëve të varur, por meqenëse ju keni kontroll të plotë mbi aplikacionin tuaj, gjëra të tilla si proceset e varura dhe bllokimet në mënyrë ideale nuk duhet të ndodhin: alternativa më e mirë është të prishni qëllimisht aplikacionin dhe ta ktheni atë në gjendjen e mëparshme të qëndrueshme;
- një hetim i dështuar i gjallërisë do të shkaktojë rinisjen e kontejnerit, duke përkeqësuar në këtë mënyrë pasojat e gabimeve të lidhura me ngarkimin: rinisja e kontejnerit do të rezultojë në ndërprerje (të paktën për kohëzgjatjen e fillimit të aplikacionit, le të themi 30 sekonda tek), duke shkaktuar gabime të reja , duke rritur ngarkesën në kontejnerë të tjerë dhe duke rritur mundësinë e dështimit të tyre, etj.;
- kontrollet e gjallërisë së kombinuar me një varësi të jashtme janë kombinimi më i keq i mundshëm, duke kërcënuar dështime në kaskadë: një vonesë e lehtë në anën e bazës së të dhënave do të çojë në një rinisje të të gjithë kontejnerëve tuaj!
Parametrat e kontrolleve të gjallërisë dhe gatishmërisë duhet të jetë ndryshe:
- ju mund të përdorni një sondë gjallërie me të njëjtin kontroll shëndetësor, por një prag më të lartë reagimi (failureThreshold), për shembull, caktoni statusin jo gati pas 3 përpjekjeve dhe konsideroni se sonda e gjallërisë ka dështuar pas 10 përpjekjeve;
Mos përdorni kontrolle ekzekutive, pasi ato shoqërohen me probleme të njohura që çojnë në shfaqjen e proceseve të zombies:
- detaje: shih prezantim nga specialistët e Datadog.

Përmbledhje

Përdorni sondat e gatishmërisë për të përcaktuar se kur një pod është gati për të marrë trafik.
Përdorni sondat e gjallërisë vetëm kur ato janë vërtet të nevojshme.
Përdorimi jo i duhur i sondave të gatishmërisë/gjallërisë mund të çojë në zvogëlimin e disponueshmërisë dhe dështime në kaskadë.

Materiale shtesë mbi temën

Dokumentet e Kubernetes: Konfiguro hetimet e gjallërisë dhe gatishmërisë;
Sondat e gjallërisë dhe gatishmërisë Kubernetes u rishikuan: Si të shmangni të qëlloni veten në këmbën tjetër;
NRE Labs ndërprerje pas vdekjes (ai flet edhe për livenessProbe).

Përditësimi nr. 1 nga 2019-09-29

Rreth kontejnerëve init për migrimin e bazës së të dhënave: Fusnota u shtua.

Më kujtoi EJ në lidhje me PDB: një nga problemet me kontrollet e gjallërisë është mungesa e koordinimit midis pods. Kubernetes ka Buxhetet e përçarjes së grupeve (PDB) për të kufizuar numrin e dështimeve të njëkohshme që një aplikacion mund të përjetojë, megjithatë kontrollet nuk marrin parasysh PDB-në. Në mënyrë ideale, ne mund t'i themi K8s të "Rinise një pod nëse testi i tij dështon, por mos i rinisni të gjitha për të shmangur përkeqësimin e gjërave."

Bryan e shprehu në mënyrë të përsosur: “Përdorni probimin e gjallërisë kur e dini saktësisht se çfarë Gjëja më e mirë për të bërë është të vrasësh aplikacionin"(përsëri, mos u tërhiqni).

Përditësimi nr. 2 nga 2019-09-29

Lidhur me leximin e dokumentacionit përpara përdorimit: Kam krijuar kërkesën përkatëse (kërkesa e veçorisë) për të shtuar dokumentacion në lidhje me sondat e gjallërisë.

PS nga përkthyesi

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Sondat e gjallërisë në Kubernetes mund të jenë të rrezikshme