Kubernetese elavuse mõõtmised võivad olla ohtlikud

Märge. tõlge: Zalando juhtivinsener Henning Jacobs on korduvalt märganud probleeme Kubernetese kasutajate seas elavdamise (ja valmisoleku) sondide eesmärgi ja õige kasutamise mõistmisel. Seetõttu kogus ta oma mõtted sellesse mahukasse märkmesse, millest saab lõpuks osa K8s dokumentatsioonist.

Tervisekontrollid, tuntud Kubernetes kui elavuse sondid (st sõna-sõnalt "elujõulisuse testid" - umbes tõlge), võib olla üsna ohtlik. Soovitan neid võimalusel vältida: ainsad erandid on siis, kui need on tõeliselt vajalikud ning oled täielikult teadlik nende kasutamise eripäradest ja tagajärgedest. See väljaanne räägib elujõulisuse ja valmisoleku kontrollist ning annab ka teada, millistel juhtudel Maksumus ja te ei tohiks neid kasutada.

Mu kolleeg Sandor jagas hiljuti Twitteris levinumaid vigu, millega ta kokku puutub, sealhulgas neid, mis on seotud valmisoleku/elavuse anduri kasutamisega:

Valesti konfigureeritud livenessProbe võib raskendada suure koormusega olukordi (lumepalli väljalülitamine + potentsiaalselt pikk konteineri/rakenduse käivitusaeg) ja põhjustada muid negatiivseid tagajärgi, nagu sõltuvuse vähenemine (Vaata ka minu hiljutine artikkel taotluste arvu piiramise kohta kombinatsioonis K3s + ACME). Veelgi hullem on see, kui elavuse sond on kombineeritud tervisekontrolliga, mis on väline andmebaas: üksainus DB-tõrge taaskäivitab kõik teie konteinerid!

Üldine sõnum "Ära kasuta elavdamise sonde" antud juhul see eriti ei aita, nii et vaatame, milleks on valmisoleku ja elavuse kontrollid.

Märkus. Suurem osa allolevast testist lisati algselt Zalando sisemisse arendaja dokumentatsiooni.

Valmisoleku ja elujõulisuse kontrollid

Kubernetes pakub kahte olulist mehhanismi, mida nimetatakse elavuse sondid ja valmisoleku sondid. Nad sooritavad perioodiliselt mingeid toiminguid (nt HTTP-päringu saatmine, TCP-ühenduse avamine või konteineris käsu täitmine), et kinnitada, et rakendus töötab ootuspäraselt.

Kubernetes kasutab valmisoleku sondidet aru saada, millal konteiner on liikluse vastuvõtmiseks valmis. Kaun loetakse kasutusvalmis, kui kõik selle konteinerid on valmis. Üks selle mehhanismi kasutusvõimalus on juhtida, milliseid kaunasid kasutatakse Kubernetese teenuste (ja eriti Ingressi) taustaprogrammidena.

Elavsuse proovid aidake Kubernetesel mõista, millal on aeg konteiner taaskäivitada. Näiteks võimaldab selline kontroll kinni pidada ummikseisu, kui rakendus ühte kohta kinni jääb. Konteineri taaskäivitamine selles olekus aitab rakendusel vigadest hoolimata käivitada, kuid see võib põhjustada ka kaskaadtõrkeid (vt allpool).

Kui proovite juurutada rakenduse värskendust, mis ei läbi töövõime/valmiduse kontrolli, peatub selle levitamine, kuna Kubernetes ootab olekut Ready kõigist kaunadest.

Näide

Siin on näide teekonda kontrollivast valmisolekusondist /health HTTP kaudu vaikeseadetega (intervall: 10 sekundit, timeout: 1 sekund, edukuse künnis: 1, ebaõnnestumise lävi: 3):

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

Soovitused

1. HTTP lõpp-punktiga mikroteenuste jaoks (REST jne) määrake alati valmisolekusond, mis kontrollib, kas rakendus (pod) on liikluse vastuvõtmiseks valmis.
2. Veenduge, et valmisolekusond hõlmab tegeliku veebiserveri pordi saadavust:
   • portide kasutamine administratiivsetel eesmärkidel, mida nimetatakse "administraatoriks" või "halduseks" (näiteks 9090), readinessProbe, veenduge, et lõpp-punkt tagastab OK ainult siis, kui esmane HTTP-port (nt 8080) on liikluse vastuvõtmiseks valmis*;

     *Olen teadlik vähemalt ühest juhtumist Zalandos, kus seda ei juhtunud, s.t. readinessProbe Kontrollisin "haldus" porti, kuid server ise ei hakanud vahemälu laadimise probleemide tõttu tööle.

   • valmisolekusondi ühendamine eraldi pordi külge võib viia selleni, et põhipordi ülekoormus ei kajastu tervisekontrollis (st et serveri lõimekogum on täis, kuid tervisekontroll näitab siiski, et kõik on korras ).
3. Veendu, et valmisoleku sond võimaldab andmebaasi initsialiseerimist/migreerimist;
   • Lihtsaim viis selle saavutamiseks on võtta ühendust HTTP-serveriga alles pärast initsialiseerimise lõpetamist (näiteks andmebaasi üleviimine Lennutee ja nii edasi.); see tähendab, et tervisekontrolli oleku muutmise asemel lihtsalt ärge käivitage veebiserverit enne, kui andmebaasi migratsioon on lõpule viidud*.

     * Samuti saate käivitada andmebaasi migratsiooni algkonteineritest väljaspool pod. Olen endiselt iseseisev rakenduste fänn, st need, mille rakenduskonteiner teab, kuidas viia andmebaas soovitud olekusse ilma välise koordineerimiseta.

4. Kasutage httpGet valmisoleku kontrollimiseks tüüpiliste tervisekontrolli lõpp-punktide kaudu (nt /health).
5. Saate aru vaikekontrolli parameetritest (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • vaikevalikud tähendavad, et pod muutub ei ole valmis umbes 30 sekundi pärast (3 ebaõnnestunud mõistuse kontrolli).
6. Kasutage "administraatori" või "halduse" jaoks eraldi porti, kui tehnoloogiapinn (nt Java/Spring) seda võimaldab, et eraldada tervise- ja mõõdikute haldus tavalisest liiklusest.
   • aga ära unusta punkti 2.
7. Vajadusel saab valmisolekuandurit kasutada vahemälu soojendamiseks/laadimiseks ja olekukoodi 503 tagastamiseks, kuni konteiner soojeneb:
   • Soovitan ka uue tšeki läbi lugeda startupProbe, ilmus versioonis 1.16 (me kirjutasime sellest vene keeles siin - u. tõlge.).

Hoiatused

1. Ärge lootke välistele sõltuvustele (nt andmeladud) valmisoleku/elujõulisuse testide käitamisel – see võib põhjustada kaskaadtõrkeid:
   • Näitena võtame olekupõhise REST-teenuse 10 podiga sõltuvalt ühest Postgresi andmebaasist: kui kontroll sõltub toimivast ühendusest DB-ga, võivad kõik 10 podi ebaõnnestuda, kui võrgu/DB poolel on viivitus – tavaliselt kõik lõppeb hullemini, kui võiks;
   • Pange tähele, et Spring Data kontrollib vaikimisi andmebaasi ühendust*;

     * See on Spring Data Redise vaikekäitumine (vähemalt see oli viimane kord, kui ma kontrollisin), mis viis "katastroofilise" tõrkeni: kui Redis oli lühikest aega kättesaamatu, jooksid kõik podid kokku.

   • "Väline" võib selles tähenduses tähendada ka teisi sama rakenduse kaustasid, st ideaaljuhul ei tohiks kontroll sõltuda sama klastri teiste kaustade olekust, et vältida kaskaadkrahhe:
     • tulemused võivad hajutatud olekuga rakenduste puhul erineda (nt mälusisene vahemällu salvestamine kaustades).
2. Ärge kasutage elavuse andurit kaunade jaoks (erandiks on juhud, kui need on tõesti vajalikud ja olete nende kasutamise eripäradest ja tagajärgedest täielikult teadlik):
   • Elavdamise sond võib aidata üles riputatud konteinereid taastada, kuid kuna teil on täielik kontroll oma rakenduse üle, ei tohiks ideaaljuhul selliseid asju nagu riputatud protsessid ja ummikseisud juhtuda: parim alternatiiv on rakenduse tahtlik kokkujooksmine ja eelmise püsioleku naasmine;
   • ebaõnnestunud elavuse sond põhjustab konteineri taaskäivitamise, mis võib potentsiaalselt süvendada laadimisega seotud vigade tagajärgi: konteineri taaskäivitamine põhjustab seisakuid (vähemalt rakenduse käivitamise ajaks, näiteks 30 sekundit), põhjustades uusi tõrkeid. , suurendades teiste konteinerite koormust ja suurendades nende rikke tõenäosust jne;
   • elavuskontrollid koos välise sõltuvusega on halvim võimalik kombinatsioon, mis ähvardab kaskaadtõrkeid: väike viivitus andmebaasi poolel toob kaasa kõigi teie konteinerite taaskäivitamise!
3. Elavduse ja valmisoleku kontrollimise parameetrid peab olema erinev:
   • saate kasutada sama tervisekontrolliga, kuid kõrgema reageerimislävega elavussondi (failureThreshold), näiteks määrake olek ei ole valmis pärast 3 katset ja arvestage, et elavuse sond on pärast 10 katset ebaõnnestunud;
4. Ärge kasutage exec-tšekke, kuna need on seotud teadaolevate probleemidega, mis viivad zombiprotsesside ilmnemiseni:
   • üksikasjad: vt Datadogi spetsialistide ettekanne.

Kokkuvõte

• Kasutage valmisolekusonde, et teha kindlaks, millal pod on liikluse vastuvõtmiseks valmis.
• Kasutage elavdussonde ainult siis, kui neid tõesti vaja on.
• Valmisoleku-/elujõusondide ebaõige kasutamine võib põhjustada kättesaadavuse vähenemist ja kaskaadtõrkeid.

Lisamaterjalid teemal

• Kubernetese dokumendid: konfigureerige elavuse ja valmisoleku sondid;
• Kubernetese elavuse ja valmisoleku sondid on uuesti läbi vaadatud: kuidas vältida endale teise jalga tulistamist;
• NRE Labsi surmajärgne seisak (ta räägib ka elavusestProbe).

Värskendus nr 1 2019-09-29

Andmebaasi migratsiooni init-konteinerite kohta: Lisatud joonealune märkus.

EJ tuletas mulle meelde esialgse eelarveprojekti kohta: üks elulisuse kontrollimise probleeme on kaunade vahelise koordineerimise puudumine. Kubernetes on Podi häirete eelarved (EPB) et piirata samaaegsete tõrgete arvu, mida rakendus võib kogeda, kuid kontrollimisel ei võeta arvesse esialgset eelarveprojekti. Ideaalis võiksime öelda K8sile: "Taaskäivitage üks pod, kui selle test ebaõnnestub, kuid ärge taaskäivitage neid kõiki, et vältida asja hullemaks muutmist."

Bryan sõnastas selle suurepäraselt: „Kasutage elujõulisuse analüüsi, kui teate täpselt, mida parim asi, mida teha, on rakendus tappa"(jällegi, ärge laske end endast välja lasta).

Värskendus nr 2 2019-09-29

Seoses dokumentatsiooni lugemisega enne kasutamist: lõin vastava päringu (funktsioonitaotlus), et lisada dokumentatsiooni elavussondide kohta.

PS tõlkijalt

Loe ka meie blogist:

• «Kubernetes: Pod Life";
• «7 parimat tava konteinerite kasutamiseks vastavalt Google'ile";
• «7 konteineripõhiste rakenduste kavandamise põhimõtted'.

Allikas: www.habr.com