🥇Elavuse uuringud Kuberneteses võivad olla ohtlikud

Märk. tõlge.: Zalando peainsener Henning Jacobs on korduvalt märganud, et Kubernetesega kasutajatel on probleeme liveness (ja readiness) probe'ide mõistmisega ning nende õige rakendamisega. Seetõttu kogus ta oma mõtted kokku selles lühikeses märkuses, mis ajapikku saab K8s dokumentatsiooni osaks.

Kuberneteses tuntud olekusektsioonid liveness probe'id (s.t. sõna-sõnalt "elujõudlustestid" — tõlkija märkus), võivad olla üsna ohtlikud. Soovitan neid võimalusel vältida; eranditeks on vaid juhtumid, kui need on tõeliselt vajalikud ning te mõistate täielikult nende kasutamise spetsiifikat ja tagajärgi. Selles postituses räägitakse liveness- ja readiness-probe'idest ning ka sellest, millal maksavad ja millal mitte neid kasutada.

Minu kolleeg Sandor jagas hiljuti Twitteris kõige sagedasemaid vigu, millega ta kokku puutub, sealhulgas neid, mis on seotud readiness/liveness probe'ide kasutamisega:

Vale seadistamine livenessProbe võib keerulisemaks muuta olukordi, kus on kõrge koormus (laviinilised katkestused + potentsiaalselt pikaajaline konteineri/rakenduse käivitamine) ja põhjustada muid negatiivseid tagajärgi, nagu sõltuvuste kokkuvarisemine. (vt ka minu hiljutine artikkel päringute arvu piiramise kohta koos K3s+ACME-ga). Veelgi hullem on see, kui live probe on ühendatud sõltuvuse tervise kontrollimise (health check) kaudu, milleks on väline andmebaas: üks andmebaasi rike taaskäivitab kõik teie konteinerid.!

Üks peamine punkt „Ärge kasutage liveness probes“ selles kontekstis aitab vähe, seega vaatame, milleks on mõeldud readiness- ja liveness-kontrollid.

Märkus: suurem osa allpool olevast testist oli algselt lisatud Zalando arendajate sisemisse dokumentatsioonisse.

Readiness ja Liveness kontrollid

Kubernetes pakub kahte olulist mehhanismi, mida nimetatakse liveness probes ja readiness probes.Need teevad perioodiliselt teatud toimingut — näiteks saadavad HTTP-päringu, avavad TCP-ühenduse või täidavad konteineris käsu — et kinnitada, et rakendus töötab korralikult.

Kubernetes kasutab readiness probes, et mõista, millal konteiner on valmis liiklust vastu võtma. Pod loetakse töövalmiks, kui kõik selle konteinerid on valmis. Üks selle mehhanismi rakendusi on jälgida, milliseid pod’e kasutatakse Kubernetes’i teenuste (ja eriti Ingress’i) tagaplaanidena.

Eluiga kontrollib aitavad Kubernetes’il mõista, millal on aeg konteiner taaselustada. Näiteks selline kontroll aitab kinni pidada deadlock’i, kui rakendus „jä морозится” ühes kohas. Konteineri taaskäivitamine sellises olekus aitab rakendust elustada, hoolimata veadest, kuid see võib samuti põhjustada kaskaadne tõrkeid (vt allpool).

Kui proovite juurutada rakenduse värskendust, mis ebaõnnestub eluiga/valmiduse kontrollides, jääb selle rakendamine seisma, kuna Kubernetes ootab Valmis kõigi pod’ide staatust.

Näide

Siin on näide valmiduse kontrollist, mis kontrollib teed /health HTTP kaudu vaikeseadetega (interval: 10 sekundit, ajakava: 1 sekund, edukuse kynrakindlus: 1, ebaõnnestumise kynrakindlus: 3):

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

Soovitused

HTTP lõpp-punktiga mikroteenuste (REST jne) puhul määrake alati valmiduse kontroll, mis kontrollib, kas rakendus (pod) on valmis liiklust vastu võtma.
Veenduge, et valmiduse kontroll katab veebiserveri tegeliku sadama valmisolekut:
- kasutades haldussorte, nimetatakse neid "admin" või "management" (näiteks 9090), readinessProbe, veenduge, et lõpp-punkt tagastab OK ainult siis, kui põhihttp-sadam (nagu 8080) on valmis liiklust vastu võtma*;
  * Olen teadlik vähemalt ühest juhtumist Zalando's, kui seda ei juhtunud, st readinessProbe kontrollisin "management" sadamat, kuid server ei hakanud tööle, kuna oli probleemidega vahemälu laadimisega.
- valmistamiskatse riputamine eraldi sadamale võib põhjustada peamise sadama koormuse mittepeegeldumist tervise kontrollis (st serveri sõnumite bassein on täis, kuid tervise kontroll näitab siiski, et kõik on OK).
Veenduge, et valmistamiskatse hõlmab andmebaasi initsialiseerimist/migratsiooni;
- lihtsaim viis selle saavutamiseks on pöörduda HTTP-serveri poole alles pärast initsialiseerimise lõppu (nt andmebaasi migratsiooniga Flyway jne); see tähendab, et tervise kontrolli staatuse muutmise asemel ärge lihtsalt käivitage veebiserverit enne andmebaasi migratsiooni lõppu*.
  * Samuti on võimalik käivitada andmebaasi migratsioone init-konteineritest pod'ist väljaspool. Ma olen endiselt iseseisvate rakenduste fänn, st selliste, kus rakenduse konteiner ilma välist koordineerimiseta teab, kuidas viia andmebaas soovitud seisu.
Kasutage httpGet readiness kontrollide jaoks tüüpiliste health check endpoint’ide kaudu (näiteks, /health).
Tutvuge vaikeparameetritega. (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- vaikeparameetrid tähendavad, et pod muutub not-ready umbes 30 sekundi pärast (3 ebaõnnestunud töövõimekuse kontrolli).
Kasutage «admin» või «management» jaoks eraldi porti, kui tehnoloogiline stack (näiteks Java/Spring) seda võimaldab, et eraldada «tervishoiu» ja mõõdikute haldamine tavalisest liiklusest:
- aga ärge unustage punkti 2.
Vajadusel saab readiness probet kasutada kütmiseks/vahemälu laadimiseks ja tagastada olekukood 503, kuni konteiner on «soojenenud»:
- soovitan samuti tutvuda uue kontrolliga, startupProbe, mis ilmus versioonis 1.16, (me oleme sellest kirjutanud vene keeles. siit — kt. tõlge).

Hoiatused

Ärge toetuge välistele sõltuvustele. (näiteks andmehoidlad) readiness/liveness testide läbiviimisel — see võib põhjustada kaskaadseid tõrkeid:
- kuna näitena võtame stateful-teenuse REST koos 10 pod'iga, mis sõltuvad ühest Postgres andmebaasist: kui kontroll sõltub töötavast ühendusest DB-ga, võivad kõik 10 pod'i kukkuda, kui võrgu/DB-poolel tekib viivitus — tavaliselt lõpeb kõik halvemini, kui võiks;
- pange tähele, et Spring Data kontrollib vaikimisi ühendust andmebaasiga*;
  * See on Spring Data Redis vaikimisi käitumine (vähemalt oli see nii, kui ma viimati kontrollisin), mis viis „katastroofilise” tõrkeni: kui Redis oli lühikeseks ajaks kättesaamatu, kukkusid kõik pod'id kokku.
- „väline” võib selles tähenduses tähendada ka teisi sama rakenduse pod'e, see tähendab, et ideaalis ei tohiks kontroll sõltuda sama klastris olevate teiste pod'ide seisundist, et vältida kaskaadseid kokku kukkumisi:
  - tulemused võivad varieeruda rakendustes, millel on jaotatud seisund (näiteks in-memory cache pod'ides).
Ärge kasutage liveness probe pod’ide jaoks (välja arvatud olukorrad, kus need on tõeliselt vajalikud ja teate täielikult nende kasutamise spetsiifikat ja tagajärgi):
- liveness probe võib aidata taastada „hanginud” konteinerid, kuid kuna teil on oma rakenduse üle täielik kontroll, ei tohiks ideeliselt toimuda selliseid asju nagu „hangunud” protsessid ja deadlockid: parim alternatiiv on rakenduse tahtlik kokkuvarisemine ja selle taastamine eelnevalt stabiilsesse olekusse;
- ebaõnnestunud liveness probe põhjustab konteineri taaskäivitamist, mis võib potentsiaalselt süvendada laadimisvigade tagajärgi: konteineri taaskäivitamine toob kaasa seisaku (vähemalt rakenduse käivitamise ajaks, ütleme, üle 30 sekundi), tekitades uusi vigu ja suurendades teiste konteinerite koormust ning suurendades tõrkeid jne;
- liveness-kontrollid koos välise sõltuvusega on halvim võimalik kombinatsioon, mis ähvardab kaskaadi ebaõnnestumistega: isegi väike viivitus andmebaasi poolel toob kaasa kõigi teie konteinerite taaskäivitamise!
liveness- ja readiness-kontrollide parameetrid peavad olema erinevad:
- saab kasutada liveness-proovi sama health checkiga, kuid kõrgema läviväärtusega (failureThreshold), näiteks määrata olek not-ready pärast 3 katset ja pidada liveness-proovi ebaõnnestunuks pärast 10 katset;
Ärge kasutage exec-kontrolle, kuna nendega on seotud tuntud probleemid, mis võivad viia zombiprotsesside tekkimiseni:
- täiendavaid üksikasju: vt. Datadogi spetsialistide ettekanne.

Kokkuvõte

Kasutage readiness probe, et määrata, millal pod on valmis liiklust vastu võtma.
Kasutage liveness probe ainult siis, kui need on tõeliselt vajalikud.
Vale readiness/liveness proovi kasutamine võib viia kättesaadavuse languseni ja kaskaadsetesse tõrgetesse.

Lisatud materjalid teema kohta

Uuendus nr 1, 2019-09-29

Init-konteineritest andmebaasi migratsiooniks: lisatud jalus.

EJ meenutas mulle PDBst: üks liveness-proovide probleemidest on koordineerimise puudumine podide vahel. Kuberneteses on Pod Disruption Budgets (PDB) rakenduse samal ajal toimuvaid paralleelseid rikkeid piirates, kuid kontrollid ei arvestata PDB-ga. Ideaalis võiksime K8s-ile öelda: „Taaskäivita üks pod, kui selle kontroll ebaõnnestub, kuid ära taaskäivita neid kõiki, et mitte veelgi halvemaks teha.”

Bryan sõnastas selle suurepäraselt: „Kasutage elavuse uuringut, kui te teate täpselt, et parim asi, mida teha, on „tapmine” rakendus“ (taaskord, selles ei tasu üle pingutada).