Lífsrannsóknir í Kubernetes geta verið hættulegar

Athugið. þýð.: Aðalverkfræðingur frá Zalando, Henning Jacobs, hefur ítrekað tekið eftir vandamálum meðal Kubernetes notenda við að skilja tilgang lífleika (og viðbúnaðar) rannsaka og rétta notkun þeirra. Þess vegna safnaði hann hugsunum sínum í þessa rúmgóðu athugasemd, sem mun að lokum verða hluti af skjölum K8s.

Heilbrigðiseftirlit, þekkt í Kubernetes sem lífskannanir (þ.e.a.s. bókstaflega „lífvænleikapróf“ - u.þ.b. þýðing), getur verið mjög hættulegt. Ég mæli með að forðast þau ef mögulegt er: einu undantekningarnar eru þegar þær eru sannarlega nauðsynlegar og þú ert fullkomlega meðvitaður um sérkenni og afleiðingar notkunar þeirra. Í þessu riti verður fjallað um athugun á líftíma og viðbúnaði og einnig sagt í hvaða tilvikum er og þú ættir ekki að nota þá.

Samstarfsmaður minn Sandor deildi nýlega á Twitter algengustu villunum sem hann lendir í, þar á meðal þeim sem tengjast notkun á reiðubúnaði/lifunarkönnunum:

Rangt stillt livenessProbe getur aukið aðstæður með mikla álagi (lokun á snjóbolta + hugsanlega langur ræsingartími gáma/forrita) og leitt til annarra neikvæðra afleiðinga eins og fækkunar ávana. (sjá einnig nýleg grein mína um að takmarka fjölda beiðna í K3s+ACME samsetningunni). Það er enn verra þegar lífleikarannsóknin er sameinuð heilsufarsskoðun, sem er ytri gagnagrunnur: ein DB bilun mun endurræsa alla ílátin þín!

Almenn skilaboð „Ekki nota lífleikarannsakendur“ í þessu tilfelli hjálpar það ekki mikið, svo við skulum skoða til hvers viðbúnaðar- og lífskönnunin er.

Athugið: Mest af prófunum hér að neðan var upphaflega innifalið í innri þróunarskjölum Zalando.

Viðbúnaðar- og lífskjör

Kubernetes býður upp á tvö mikilvæg kerfi sem kallast lífskannanir og viðbúnaðarrannsóknir. Þeir framkvæma reglulega einhverja aðgerð - eins og að senda HTTP beiðni, opna TCP tengingu eða framkvæma skipun í ílátinu - til að staðfesta að forritið virki eins og búist var við.

Kubernetes notar viðbúnaðarrannsóknirtil að skilja hvenær gámurinn er tilbúinn til að taka við umferð. Belg telst tilbúið til notkunar ef öll ílát hans eru tilbúin. Ein notkun þessa kerfis er að stjórna hvaða hólf eru notuð sem stuðningur fyrir Kubernetes þjónustu (og sérstaklega Ingress).

Liveness rannsaka hjálpa Kubernetes að skilja hvenær það er kominn tími til að endurræsa ílátið. Til dæmis gerir slíkt ávísun þér kleift að stöðva stöðvun þegar forrit festist á einum stað. Að endurræsa ílátið í þessu ástandi hjálpar til við að koma forritinu í gang þrátt fyrir villur, en það getur líka leitt til bilana í steypum (sjá hér að neðan).

Ef þú reynir að setja upp forritsuppfærslu sem stenst ekki virkni/viðbúnaðarathugun, mun útbreiðsla hennar stöðvast þar sem Kubernetes bíður eftir stöðunni Ready úr öllum belgjum.

Dæmi

Hér er dæmi um viðbúnaðarkönnun sem athugar slóð /health í gegnum HTTP með sjálfgefnum stillingum (bil: 10 sekúndur, Tímamörk: 1 sekúnda, árangursþröskuldur: 1, bilunarþröskuldur: 3):

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

Tillögur

1. Fyrir örþjónustur með HTTP endapunkt (REST osfrv.) skilgreina alltaf viðbúnaðarrannsókn, sem athugar hvort forritið (pod) sé tilbúið til að taka við umferð.
2. Gakktu úr skugga um reiðubúinn rannsaka fjallar um framboð á raunverulegu vefþjónstengi:
   • að nota höfn í stjórnunarlegum tilgangi, kölluð „admin“ eða „stjórnun“ (til dæmis 9090), fyrir readinessProbe, vertu viss um að endapunkturinn skili aðeins OK ef aðal HTTP tengið (eins og 8080) er tilbúið til að taka við umferð*;

     *Mér er kunnugt um að minnsta kosti eitt tilvik hjá Zalando þar sem þetta gerðist ekki, þ.e. readinessProbe Ég athugaði „stjórnun“ tengið, en þjónninn sjálfur byrjaði ekki að virka vegna vandamála við að hlaða skyndiminni.

   • að tengja viðbúnaðarprófun við aðskilda höfn getur leitt til þess að ofhleðsla á aðalportinu endurspeglast ekki í heilsutékkinu (þ.e. þráðasafnið á þjóninum er fullt, en heilsuathugunin sýnir samt að allt er í lagi ).
3. Gakktu úr skugga um það viðbúnaðarkönnun gerir gagnagrunns frumstillingu/flutninga kleift;
   • Auðveldasta leiðin til að ná þessu er að hafa samband við HTTP þjóninn aðeins eftir að frumstillingu er lokið (td að flytja gagnagrunn frá Flugbraut og svo framvegis.); það er að segja, í stað þess að breyta heilsufarsstöðu skaltu einfaldlega ekki ræsa vefþjóninn fyrr en flutningi gagnagrunnsins er lokið*.

     * Þú getur líka keyrt gagnagrunnsflutninga frá init-gámum utan hólfsins. Ég er enn aðdáandi sjálfstæðra forrita, það er þeirra sem forritagámurinn veit hvernig á að koma gagnagrunninum í æskilegt ástand án ytri samhæfingar.

4. Используйте httpGet til að kanna viðbúnað í gegnum dæmigerða heilsuskoðunarendapunkta (td, /health).
5. Skildu sjálfgefnar athugabreytur (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • sjálfgefna valmöguleikarnir þýða að belgurinn verður ekki tilbúinn eftir um 30 sekúndur (3 misheppnuð geðheilsupróf).
6. Notaðu sérstaka höfn fyrir „admin“ eða „stjórnun“ ef tæknistaflan (t.d. Java/Spring) leyfir það, til að aðgreina heilsu- og mælingastjórnun frá venjulegri umferð:
   • en ekki gleyma lið 2.
7. Ef nauðsyn krefur er hægt að nota viðbúnaðarkannann til að hita upp/hlaða skyndiminni og skila 503 stöðukóða þar til ílátið hitnar:
   • Ég mæli líka með því að þú lesir nýju ávísunina startupProbe, birtist í útgáfu 1.16 (við skrifuðum um það á rússnesku hér - ca. þýðing.).

Forsendur

1. Ekki treysta á ytri ósjálfstæði (eins og gagnavöruhús) þegar viðbúnaðar-/lifunarpróf eru keyrð - þetta getur leitt til bilana sem falla:
   • Sem dæmi, tökum REST þjónustu með 10 belgjum sem fer eftir einum Postgres gagnagrunni: þegar athugunin er háð virkri tengingu við DB, geta allir 10 belgirnir bilað ef það er seinkun á net-/DB hliðinni - venjulega allt endar verr en það gat;
   • Vinsamlegast athugaðu að Spring Data athugar gagnagrunnstenginguna sjálfgefið*;

     * Þetta er sjálfgefin hegðun Spring Data Redis (að minnsta kosti var það síðast þegar ég athugaði), sem leiddi til „skelfilegrar“ bilunar: þegar Redis var ófáanlegur í stuttan tíma „hrundu“ allir belgjurtir.

   • „ytri“ í þessum skilningi getur einnig þýtt aðra belg af sama forriti, það er, helst ætti athugunin ekki að vera háð ástandi annarra belg í sama þyrpingunni til að koma í veg fyrir hrun:
     • Niðurstöður geta verið mismunandi fyrir forrit með dreift ástand (til dæmis, skyndiminni í minni í belg).
2. Ekki nota lífleikarannsakendur fyrir belg (undantekningar eru tilvik þegar þeir eru raunverulega nauðsynlegir og þú ert fullkomlega meðvitaður um sérkenni og afleiðingar notkunar þeirra):
   • Lífleikarannsakandi getur hjálpað til við að endurheimta hengda ílát, en þar sem þú hefur fulla stjórn á forritinu þínu, ættu hlutir eins og hengdir ferli og deadlocks helst ekki að gerast: besti kosturinn er að hrynja forritið vísvitandi og koma því aftur í fyrra stöðugt ástand;
   • misheppnuð lífleikarannsókn mun valda því að gámurinn endurræsir sig og gæti þar með hugsanlega aukið afleiðingar hleðslutengdra villna: endurræsing gámsins mun leiða til stöðvunartíma (að minnsta kosti meðan á ræsingu forritsins stendur, td 30 sekúndur), sem veldur nýjum villum , auka álag á aðra gáma og auka líkur á bilun þeirra osfrv.;
   • lífleikaathuganir ásamt ytri ósjálfstæði eru versta mögulega samsetningin, sem ógnar steypandi bilun: lítilsháttar töf á gagnagrunnshliðinni mun leiða til endurræsingar á öllum gámunum þínum!
3. Færibreytur lífleika og viðbúnaðarathugunar hlýtur að vera öðruvísi:
   • þú getur notað lífleikarannsakanda með sömu heilsufarsskoðun, en hærri svörunarþröskuld (failureThreshold), til dæmis, úthlutaðu stöðunni ekki tilbúinn eftir 3 tilraunir og líttu svo á að lífleikakönnunin hafi mistekist eftir 10 tilraunir;
4. Ekki nota exec checks, þar sem þau tengjast þekktum vandamálum sem leiða til útlits uppvakningaferla:
   • upplýsingar: sjá kynningu frá sérfræðingum Datadog.

Yfirlit

• Notaðu viðbúnaðarkannanir til að ákvarða hvenær fræbelgur er tilbúinn til að taka á móti umferð.
• Notaðu lífleikarannsakendur aðeins þegar þeirra er raunverulega þörf.
• Óviðeigandi notkun á viðbúnaðar-/lifunarkönnunum getur leitt til minnkaðs aðgengis og bilana í fossi.

Viðbótarefni um efnið

• Kubernetes skjöl: Stilltu lifnaðar- og viðbúnaðarprófanir;
• Lífs- og viðbúnaðarrannsóknir Kubernetes endurskoðaðar: Hvernig á að forðast að skjóta sjálfan þig í annan fótinn;
• Stöðvun NRE Labs eftir slátrun (hann talar líka um livenessProbe).

Uppfærsla nr. 1 frá 2019-09-29

Um init gáma fyrir flutning gagnagrunns: Neðanmálsgrein bætt við.

EJ minnti mig á um PDB: eitt af vandamálunum við athugun á líftíma er skortur á samhæfingu milli belg. Kubernetes hefur Fjárhagsáætlun fyrir truflanir (PDB) til að takmarka fjölda samhliða bilana sem forrit getur lent í, en athuganir taka ekki tillit til PDB. Helst gætum við sagt K8s að "endurræsa einn pod ef prófið hans mistekst, en ekki endurræsa þá alla til að forðast að gera hlutina verri."

Bryan orðaði það fullkomlega: „Notaðu lífleikarannsókn þegar þú veist nákvæmlega hvað það besta til að gera er að drepa forritið"(aftur, ekki láta kippa sér upp við).

Uppfærsla nr. 2 frá 2019-09-29

Varðandi að lesa skjölin fyrir notkun: Ég bjó til samsvarandi beiðni (lögun beiðni) til að bæta við skjölum um lífleikarannsóknir.

PS frá þýðanda

Lestu líka á blogginu okkar:

• «Kubernetes: Pod Life»;
• «7 bestu starfsvenjur til að nota ílát samkvæmt Google»;
• «7 meginreglur fyrir hönnun gáma-undirstaða forrita'.

Heimild: www.habr.com