🥇Sondat e liveness-it në Kubernetes mund të jenë të rrezikshme

Shën. përkth.: Inxhinier i lartë nga kompania Zalando — Henning Jacobs — ka vënë re disa herë probleme me përdoruesit e Kubernetes në kuptimin e qëllimit të liveness (dhe readiness) probes dhe aplikimit të tyre të saktë. Prandaj, ai ka mbledhur mendimet e tij në këtë shënim të shpejtë, i cili me kalimin e kohës do të bëhet pjesë e dokumentacionit K8s.

Kontrollimet e gjendjes, të njohura në Kubernetes si liveness probes (të cilat domethënë, 'testet e jetshmërisë' — shën. përkth.), mund të jenë mjaft të rrezikshme. Rekomandoj të shmangni ato sa të jetë e mundur; përjashtimet janë vetëm rastet kur ato janë vërtet të nevojshme dhe ju e kuptoni plotësisht specifikën dhe pasojat e përdorimit të tyre. Në këtë publikim, do të flasim për liveness- dhe readiness-probes, si dhe do të diskutojmë se në cilat raste ndodhet dhe nuk duhet t'i aplikoni.

Kolegu im Sandor së fundmi ndau në Twitter gabimet më të shpeshta që ai has, duke përfshirë ato të lidhura me përdorimin e readiness/liveness probes:

E keqëkonfiguruar livenessProbe mund të përkeqësojë situatat me ngarkesë të lartë (çlirimi në baticë + potencialisht nisje e gjatë e kontejnerit/aplikacionit) dhe të sjellë pasojat e tjera negative siç janë rëniet e varësive (shih gjithashtu artikulli im i fundit në lidhje me kufizimin e numrit të kërkesave në kombinimin K3s+ACME). Madje edhe më keq, kur liveness probe kombinohet me kontrollin e shëndetit të varësisë (health check) e cila është një bazë të dhënash e jashtme: një dështim i vetëm i DB do të ri-nisë të gjithë kontejnerët tuaj.!

Mesazhi i përgjithshëm "Mos përdorni liveness probes" në këtë rast ndihmon pak, prandaj le të shqyrtojmë se për çfarë janë krijuar kontrollet e readiness- dhe liveness.

Shënim: pjesa më e madhe e provimit të mëposhtëm fillimisht ishte përfshirë në dokumentacionin e brendshëm për zhvilluesit e Zalando.

Kontrollimet Readiness dhe Liveness

Kubernetes ofron dy mekanizma të rëndësishëm, të quajtur liveness probes dhe readiness probes.Ato kryejnë periodikisht një veprim — për shembull, dërgojnë një kërkesë HTTP, hapin një lidhje TCP ose ekzekutojnë një komandë në kontejner — për të konfirmuar që aplikacioni po punon siç duhet.

Kubernetes përdor readiness probes., që të kuptoni kur kontejneri është gati për të pranuar trafik. Një pod konsiderohet i gatshëm për punë, nëse të gjithë kontenjert e tij janë gati. Një nga aplikimet e këtij mekanizmi është të kontrolloni se cilat pod’i përdoren si backend për shërbimet Kubernetes (dhe veçanërisht për Ingress-in).

Probat e gjallërisë ndihmojnë Kubernetes të kuptojë kur është koha për të rinisur kontejnerin. Për shembull, një provë e tillë ndihmon për të ndalur deadlock-un, kur aplikacioni "ngatërron" në një vend. Rinisi i kontejnerit në këtë gjendje ndihmon për të lëvizur aplikacionin nga pika në ndalesë, megjithatë, kjo mund të çojë gjithashtu në dështime kaskadë (shih më poshtë).

Nëse përpiqeni të zhvilloni një përditësim të aplikacionit që dështon provat e gjallërisë/gatshmërisë, angazhimi i tij do të ngecë, pasi Kubernetes do të presë statusin Gati nga të gjithë pod’ët.

Shembulli

Ja një shembull i provës së gatshmërisë, që kontrollon rrugën /health përmes HTTP me konfigurime të paracaktuara (interval: 10 sekonda, timeout: 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 mikrosherbimet me endpoint HTTP (REST etj.) gjithmonë caktoni provën e gatshmërisë, e cila kontrollon nëse aplikacioni (pod) është gati të pranojë trafik.
Sigurohuni që provat e gatshmërisë të mbulojnë gatishmërinë e portit aktual të serverit web:
- duke përdorur porte për nevojat administrativë, të quajtura "admin" ose "menaxhimi" (p.sh., 9090), për readinessProbe, sigurohuni që endpoint të kthejë OK vetëm nëse porti kryesor HTTP (si 8080) është gati për të pranuar trafik*;
  * Jam i vetëdijshëm për të paktën një rast në Zalando, kur kjo nuk ndodhi, pra readinessProbe kontrolloi portin "menaxhimi", por vetë serveri nuk nisi për shkak të problemeve me ngarkimin e caches.
- vendosja e provës së gatshmërisë në një port të veçantë mund të çojë në atë që ngarkesa në portin kryesor nuk do të reflektohet në kontrollin e shëndetit (pra, pool-i i thread-ëve në server është i mbushur, megjithatë kontrolli i shëndetit akoma tregon se gjithçka është OK).
Sigurohuni që prova e gatshmërisë përfshin inicializimin/migrimin e bazës së të dhënave;
- mënyra më e thjeshtë për ta arritur këtë është të kontaktoni serverin HTTP vetëm pas përfundimit të inicializimit (p.sh., migrimi i BDs me Flyway etj.); do të thotë, në vend që të ndryshoni statusin e kontrollit të shëndetit, thjesht mos aktivizoni serverin web derisa migrimi i BDs të përfundojë*.
  * Gjithashtu mund të ekzekutoni migrime DB nga konteinerët init jasht pod-it. Unë ende jam një ndjekës i aplikacioneve të vetë-mjaftueshme, dmth, atyre në të cilat konteineri i aplikacionit e di se si ta sjellë DB-në në gjendjen e duhur pa koordinim të jashtëm.
Përdorni httpGet për kontrollet e gatishmërisë përmes endpoint-ave tipike të kontrolleve të shëndetit (për shembull, /health).
Merrni parasysh parametrat e kontrolleve të caktuar siç është parazgjedhur (intervali: 10s, koha e skadencës: 1s, threshold-i i suksesit: 1, threshold-i i dështimit: 3):
- parametrat e parazgjedhur do të thotë se pod-i do të bëhet not-ready pjesërisht pas rreth 30 sekondave (3 kontrolle të dështuar të funksionimit).
Përdorni një port të veçantë për «admin» ose «menaxhim», nëse stoku teknologjik (për shembull, Java/Spring) e lejon këtë, për të ndarë menaxhimin e 'shëndetit' dhe metrike nga trafiku i zakonshëm:
- por mos harroni pikën 2.
Nëse është e nevojshme, mund të përdorni kontrollet e gatishmërisë për ngrohje/ngarkim të caches dhe të ktheni kodin e gjendjes 503 derisa konteineri të 'ngrohet':
- po ashtu rekomandoj të njiheni me kontrollin e ri startupProbe, që u shfaq në versionin 1.16 (ne kemi shkruar për të në rusisht këtu — shën. përkth.).

Këshilla

Mos u mbështetni në varësi të jashtme (siç janë depozitë të dhënash) kur bëni prova për gatishmërinë/livshmërinë — kjo mund të çojë në dështime kaskadë:
- si një shembull, le të marrim një shërbim stateful REST me 10 pod-e që varen nga një database Postgres: kur kontrolli varen nga një lidhje aktive me DB-në, të gjithë 10 pod-të mund të bien nëse ka vonesa në rrjet/nga ana e DB-së — zakonisht e gjithë kjo përfundon më keq se sa do të mund të ishte;
- kushtojini vëmendje se Spring Data në parazgjedhje kontrollon lidhjen me DB-në*;
  * Ky është sjellja e parazgjedhur e Spring Data Redis (të paktën kështu ishte kur e kontrollova herën e fundit), që çoi në një dështim 'katastrofik': kur për një kohë të shkurtër Redis nuk ishte në dispozicion, të gjithë pod-të 'ranë'.
- ‘jashtë’ në këtë kuptim gjithashtu mund të dojë të thotë pod-e të tjera të të njëjtit aplikacion, dmth, në mënyrë ideale kontrolli nuk duhet të varet nga gjendja e pod-eve të tjera në të njëjtin klaster për të parandaluar rëniet kaskadë:
  - rezultatet mund të variojnë për aplikacionet me gjendje të shpërndara (për shembull, cache në memorje në pod-e).
Mos përdorni probe livshmërie për pod-e (përjashtimet janë rastet kur ato vërtet kërkohen dhe ju e kuptoni plotësisht specifikën dhe pasojat e përdorimit të tyre):
- Përgjigje liveness mund të ndihmojë në rikuperimin e konteinerëve "të ngrirë", por, pasi keni kontroll të plotë mbi aplikacionin tuaj, gjëra si proceset "e ngrira" dhe bllokimet nuk duhet të ndodhin idealisht: alternativa më e mirë është që aplikacioni të bjerë me qellim dhe të kthehet në një gjendje të mëparshme të qëndrueshme;
- Dështimi i përgjigjes liveness do të çojë në rinisjen e konteinerit, duke përkeqësuar potencialisht pasojat e gabimeve të lidhura me ngarkesën: rinisja e konteinerit do të sjellë ndalesa (të paktën për kohën e nisjes së aplikacionit, le të themi, më shumë se 30 sekonda), duke shkaktuar gabime të reja, duke rritur ngarkesën në konteinerët e tjerë dhe duke rritur probabilitetin e dështimit të tyre, etj.;
- Kontrolli i liveness në kombinim me një varësi të jashtme është kombinimi më i keq i mundshëm, që kërcënon me dështime kaskadë: një vonesë e vogël në anën e DB do të sjellë rinisje të të gjithë konteinerëve tuaj!
Parametrat e kontrolleve liveness dhe readiness duhet të jenë të ndryshëm:
- mund të përdoret përgjigje liveness me të njëjtin kontroll të shëndetit, por me një prag më të lartë aktivizimi (failureThreshold), për shembull, të jepni statusin not-ready pas 3 përpjekjeve dhe të konsideroni se përgjigja liveness ka dështuar pas 10 përpjekjeve;
Mos përdorni kontrolle exec, pasi lidhjet me to kanë probleme të njohura që çojnë në shfaqjen e proceseve zombie:
- detajet: shihni prezantimin e specialistëve të kompanisë Datadog.

CV

Përdorni kontrollin readiness për të përcaktuar kur pod-i është i gatshëm të pranojë trafik.
Përdorni kontrollin liveness vetëm kur është e nevojshme.
Përdorimi i gabuar i kontrollave readiness/liveness mund të çojë në ulje të disponueshmërisë dhe dështime kaskadë.

Materiale shtesë mbi këtë temë

Dokumentet Kubernetes: Konfiguro Provat e Liveness dhe Readiness;
Provat e Liveness dhe Readiness në Kubernetes Rishikuar: Si të Shmangni Shkëputjen e Vetvetes;
Analiza e Ndërprerjes NRE Labs (flet edhe për livenessProbe).

Përditësimi #1 nga 2019-09-29

Rreth konteinerëve init për migrimin e DB: është shtuar një shënim.

EJ më kujtoi për PDB: një nga problemet e kontrollave liveness është mungesa e koordinatës midis pod-ëve. Në Kubernetes ka Buxhetet e Shkëputjes së Pod-eve (PDB) për të kufizuar numrin e dështimeve paralele që mund të përjetojë aplikacioni, megjithatë kontrollet nuk e marrin parasysh PDB-në. Idealisht mund të urdhërojmë K8s: "Rinisni një pod, nëse kontrolli i tij dështon, por mos rinisni të gjithë, për të mos e bërë edhe më keq".

Bryan e formuloi shkëlqyeshëm: «Përdorni sondat e liveness-it kur jeni të sigurt se gjëja më e mirë për të bërë është të «vrasni» aplikacionin» (përsëri, mos u teproni).