🥇Elususe proovid Kuberneteses võivad olla ohtlikud

Märkus tõlke kohta.: Zalando juhtiv insener Henning Jacobs on korduvalt märganud Kubernetes'i kasutajatel probleeme liveness (ja readiness) probe'ide mõistmise ja nende õige rakendamisega. Seetõttu koondas ta oma mõtted sellesse lühikesse märkusesse, mis aja jooksul muutub K8si dokumentatsiooni osaks.

Kubernetes'is tuntud kui liveness probes (st. sõna otseses mõttes «elujõudluse testid» — märk. tõlk.), võivad olla üsna ohtlikud. Soovitan neid võimaluse korral vältida: eranditeks on ainult juhtumid, kui need on tõeliselt vajalikud ja te täielikult mõistate nende kasutamise eripära ja tagajärgi. Selles publikatsioonis räägitakse liveness- ja readiness-kontrollidest ning tuuakse välja, millal asub ja millal neid ei tohiks rakendada.

Minu kolleeg Sandor jagas hiljuti Twitter'is kõige levinumaid vigu, millega ta kokku puutub, sealhulgas readiness/liveness probe'ide kasutamisega seotud vigu:

Vale seadistamine livenessProbe võib halvendada kõrge koormuse olukordi (lumepalliefekt + potentsiaalselt pikk konteineri/rakenduse käivitamine) ja põhjustada teisi negatiivseid tagajärgi, nagu sõltuvuste kokkuvarisemine (vt ka minu hiljutine artikkel K3s+ACME kombineeritud päringute piiramisest). Veel hullem on, kui liveness probe on kombineeritud sõltuvuse tervisekontrolliga, milleks on väline andmebaas: üks andmebaasi rike taaskäivitab kõik teie konteinerid!

Üks peamine sõnum «Ärge kasutage liveness probe'e» antud juhul aitab vähe, seega vaatame, milleks readiness- ja liveness-kontrollid on mõeldud.

Märkus: enamik allpool toodud testidest oli algselt kaasatud Zalando arendajate sisemisse dokumentatsiooni.

Readiness ja Liveness kontrollid

Kubernetes pakub kahte olulist mehhanismi, mida nimetatakse liveness probes ja readiness probes. Need täidavad perioodiliselt teatud toimingut — näiteks saadavad HTTP-päringu, avavad TCP-ühenduse või käivitavad käsu konteineris — 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 kontrollida, milliseid pod’e kasutatakse Kubernetes’i teenuste (ja eeskätt Ingress’i) tagaplaanidena.

Elamise kontrollid aitavad Kubernetes’il mõista, millal on aeg konteinerit taaskäivitada. Näiteks võimaldab selline kontroll haarata deadlock’ist, kus rakendus „hakkab” paigale. Konteineri taaskäivitamine sellises seisundis aitab rakendust liigutada surnud punktist edasi, hoolimata vigadest, kuid see võib samuti viia kaskaadsete tõrgeteni (vt allpool).

Kui proovite rakenduse värskendust juurutada, mis ei lähi elamise / valmiduse kontrollidest, jääb selle juurutamine seisma, kuna Kubernetes ootab staatust Valmis kõigilt pod’idelt.

Näide

Siin on näide valmiduse kontrollist, mis kontrollib teed /health HTTP kaudu vaikeseadetega (intervall: 10 sekundit, aegumine: 1 sekund, eduka künnise: 1, ebaõnnestumise künnise: 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 porti valmiduse:
- kasutades haldusotstarbeliseks portides, mida nimetatakse „admin” või „management” (nt 9090), readinessProbe, veenduge, et lõpp-punkt tagastab OK, ainult kui peamine HTTP-port (näiteks 8080) on valmis liiklust vastu võtma*;
  * Olen teadlik vähemalt ühest juhtumist Zalando’s, kus seda ei juhtunud, see tähendab readinessProbe et kontrolliti „haldus” porti, kuid server ise ei hakanud tööle, kuna vahemälu laadimisega olid probleeme.
- valmiduse kontrolli rakendamine eraldi porti võib tähendada, et koormus peamisel pordil ei kajastu tervisekontrollis (see tähendab, et serveri niitide poolsus on täitunud, kuid tervisekontroll näitab endiselt, et kõik on OK).
Veenduge, et valmiduse kontroll hõlmab andmebaasi initsialiseerimist / migratsiooni;
- kõige lihtsam viis selle saavutamiseks on pöörduda HTTP-serveri poole alles pärast initsialiseerimise (nt andmebaasi migratsiooni) lõppu; Flyway st selle asemel, et muuta tervisekontrolli staatust, lihtsalt ärge käitage veebiserverit enne, kui andmebaasi migratsioon on lõpule viidud*.
  * Samuti on võimalik käivitada andmebaasi migreerimist init-konteineritest väljaspool pod’i. Ma olen endiselt iseseisvate rakenduste (self-contained) fänn, st selliste, kus rakenduse konteiner teab ilma välist kooskõlastuseta, kuidas viia andmebaas soovitud olekusse.
Kasutage httpGet valmistumisproovide jaoks läbi tüüpiliste tervisekontrollide lõpp-punkte (näiteks, /health).
Tutvu vaikeväärtustega kontrolli parameetrite osas. (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- vaikeväärtused tähendavad, et pod muutub not-ready umbes 30 sekundi pärast (3 ebaõnnestunud tervisekontrolli).
Kasutage eraldi porti ‘admin’ või ‘management’ jaoks, kui tehnoloogiline virn (näiteks Java/Spring) seda võimaldab, et eraldada tervise ja metoodika haldamine tavaliikluse eest:
- aga ärge unustage punkti 2.
Vajadusel võib valmisoleku kontrolli kasutada teadmiste kaldumiseks/vahemälu laadimiseks ja väljastada olekukoodi 503, kuni konteiner ei ole ‘soojenenud’:
- soovitan tuttavaks saada uue kontrolliga startupProbe, mis tuli välja versioonis 1.16 (oleme sellest kirjutanud vene keeles. siin — toimetaja märkus).

Hoiatused

Ärge toetuge välistele sõltuvustele (nagu andmete ladustamine) valmisoleku/eluviiside testide läbiviimisel — see võib põhjustada kaskaadseid ebaõnnestumisi:
- näiteks võtame stateful-teenuse REST 10 pod’iga, mis sõltub ühest Postgres andmebaasist: kui kontroll sõltub töötavast ühendusest andmebaasiga, võivad kõik 10 pod’i kokku kukkuda, kui tekib viivitus võrgu/andmebaasi mõttes — tavaliselt lõpeb kõik hullemalt, kui võiks;
- pange tähele, et Spring Data kontrollib vaikimisi andmebaasiga ühendust*;
  * Selline on Spring Data Redis vaikimisi käitumine (vähemalt oli see nii, kui ma eelmisel korral kontrollisin), mis viis ‘katastroofilise’ ebaõnnestumiseni: kui Redis oli lühiajaliselt kättesaamatu, kukkusid kõik pod’id kokku.
- ‘väline’ selles tähenduses võib samuti tähendada muid sama rakenduse pod’e, st ideaaljuhul ei peaks kontroll sõltuma sama klastrisse kuuluvate teiste pod’ide olekust, et vältida kaskaadseid kukkumisi:
  - tulemused võivad varieeruda rakenduste puhul, millel on jaotatud olek (näiteks, in-memory vahemälu pod’ides).
Ärge kasutage eluviisi kontrolli pod’ide jaoks (välja arvatud juhul, kui see on tõeliselt vajalik ja olete täielikult teadlik nende kasutamise eripäradest ja tagajärgedest):
- liveness probe võib aidata taastada „seisvaid” konteinerite, kuid kuna teil on täielik kontroll oma rakenduse üle, ei tohiks sellised asjad nagu „seisvad” protsessid ja deadlock'id ideaalis tekkida: parem alternatiiv on rakenduse tahtlik kokku kukkumine ja selle naasmine eelmisse stabiilsesse seisundisse;
- ebaõnnestunud liveness probe toob kaasa konteineri taaskäivitamise, mis võib potentsiaalselt süvendada laadimisega seotud vigu: konteineri taaskäivitamine põhjustab seiskumise (vähemalt rakenduse käivitamise ajal, ütleme, üle 30 sekundi), tekitades uusi vigu, suurendades koormust teistele konteineritele ja tõstes nende rikke tõenäosust jne;
- liveness-proovid koos välise sõltuvusega on halvim võimalik kombinatsioon, mis ähvardab kaskaadsete tõrgete ohtu: isegi väike viivitus andmebaasi küljelt võib põhjustada kõigi teie konteinerite taaskäivitamise!
liveness- ja readiness-proovide parameetrid peavad olema erinevad:
- võib kasutada liveness probe sama health check'iga, kuid kõrgema aktiveerimiskünnisega (failureThreshold), näiteks määrata olek not-ready pärast 3 katset ja arvata, et liveness probe ebaõnnestus pärast 10 katset;
Ärge kasutage exec-proove, kuna nendega on seotud tuntud probleemid, mis põhjustavad zombiprotsesside tekkimist:
- detailid: vt. Datadogi spetsialistide ettekannet.

Elulookirjeldus

Kasutage readiness probe'e, et määrata, millal pod on valmis liiklust vastu võtma.
Kasutage liveness proove ainult siis, kui need on tõeliselt vajalikud.
Valesti kasutatud readiness/liveness probes võivad põhjustada kättesaadavuse vähenemist ja kaskaadseid tõrkeid.

Täiendavad materjalid teema kohta

Kubernetes docs: Liveness ja Readiness Proovide konfigureerimine;
Kubernetes Liveness ja Readiness Proovid uuesti vaatamisel: Kuidas mitte endale jalga tulistada;
NRE Labs'i katkestuse järeldused (kätkeb ka livenessProbe'i).

Uuendus nr 1 alates 2019-09-29

Init-konteinerite kohta andmebaasi migreerimisel: lisatud jalus.

EJ tuletas mulle meelde PDB: üheks liveness proovide probleemiks on pod'ide vahelise koordineerimise puudumine. Kubernetesel on Pod Disruption Budgets (PDB) rakenduse paralleelsete rikete arvu piiramiseks, mida see võib kogeda, kuid proovide puhul ei arvestata PDB-d. Ideaalis saame käskida K8s: „Taaskäivita üks pod, kui selle proov ebaõnnestub, kuid ära taaskäivita kõiki, et mitte olukorda halvendada”.

Bryan väljendas seda suurepäraselt: „Kasutage elususe proove, kui teate täpselt, et parim asi, mida teha, on rakendus „tapmine“(ärge üle pingutage).