🥇Sonde živahnosti v Kubernetesu so lahko nevarne

Opomba. prevod: Vodilni inženir iz Zalanda, Henning Jacobs, je večkrat opazil težave med uporabniki Kubernetes pri razumevanju namena sond živosti (in pripravljenosti) in njihove pravilne uporabe. Zato je svoje misli zbral v tem obsežnem zapisku, ki bo sčasoma postal del dokumentacije K8s.

Pregledi zdravja, v Kubernetesu znani kot sonde za živost (t.j. dobesedno "preizkusi sposobnosti preživetja" - pribl. prevod), je lahko zelo nevarno. Priporočam, da se jim izognete, če se le da: izjeme so le takrat, ko so resnično nujni in se dobro zavedate posebnosti in posledic njihove uporabe. Ta publikacija bo govorila o preverjanju uporabnosti in pripravljenosti ter vam povedala, v katerih primerih je in jih ne bi smeli uporabljati.

Moj kolega Sandor je nedavno na Twitterju delil najpogostejše napake, na katere naleti, vključno s tistimi, ki so povezane z uporabo sond pripravljenosti/živosti:

Nepravilno konfiguriran livenessProbe lahko poslabša situacije z visoko obremenitvijo (zaustavitev snežne kepe + potencialno dolg čas zagona vsebnika/aplikacije) in vodi do drugih negativnih posledic, kot so padci odvisnosti (Poglej tudi moj nedavni članek o omejevanju števila zahtevkov v kombinaciji K3s+ACME). Še huje je, če je merilnik živahnosti kombiniran s pregledom zdravja, ki je zunanja zbirka podatkov: ena napaka DB bo znova zagnala vse vaše vsebnike!

Splošno sporočilo "Ne uporabljajte sond živahnosti" v tem primeru ne pomaga veliko, zato poglejmo, čemu služita preverjanja pripravljenosti in uporabnosti.

Opomba: večina spodnjega preizkusa je bila prvotno vključena v Zalandovo interno dokumentacijo za razvijalce.

Preverjanja pripravljenosti in živahnosti

Kubernetes ponuja dva pomembna mehanizma, imenovana sonde za živost in sonde pripravljenosti. Občasno izvajajo nekaj dejanj, na primer pošiljanje zahteve HTTP, odpiranje povezave TCP ali izvajanje ukaza v vsebniku, da potrdijo, da aplikacija deluje po pričakovanjih.

Kubernetes uporablja sonde za pripravljenostrazumeti, kdaj je zabojnik pripravljen sprejeti promet. Strok se šteje za pripravljenega za uporabo, če so pripravljeni vsi njegovi vsebniki. Ena uporaba tega mehanizma je nadzor nad tem, kateri podi se uporabljajo kot zaledja za storitve Kubernetes (in zlasti Ingress).

Sonde za živahnost pomagajte Kubernetesu razumeti, kdaj je čas za ponovni zagon vsebnika. Tako preverjanje vam na primer omogoča, da prestrežete zastoj, ko se aplikacija zatakne na enem mestu. Ponovni zagon vsebnika v tem stanju pomaga zagnati aplikacijo kljub napakam, vendar lahko povzroči tudi kaskadne napake (glejte spodaj).

Če poskusite uvesti posodobitev aplikacije, ki ne opravi preverjanj živosti/pripravljenosti, bo njena uvedba zaustavljena, ko bo Kubernetes čakal na stanje Ready iz vseh strokov.

Primer

Tukaj je primer sonde pripravljenosti, ki preverja pot /health prek HTTP s privzetimi nastavitvami (Interval: 10 sekund, Prekinitev: 1 sekunda, prag uspešnosti: 1, prag neuspeha: 3):

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

Priporočila

Za mikrostoritve s končno točko HTTP (REST itd.) vedno določite sondo pripravljenosti, ki preveri ali je aplikacija (pod) pripravljena na sprejem prometa.
Prepričajte se, da je sonda pripravljenosti zajema razpoložljivost dejanskih vrat spletnega strežnika:
- uporabo vrat za administrativne namene, imenovanih "admin" ali "management" (na primer 9090), za readinessProbe, se prepričajte, da končna točka vrne OK samo, če so primarna vrata HTTP (na primer 8080) pripravljena sprejeti promet*;
  *Poznam vsaj en primer pri Zalandu, kjer se to ni zgodilo, tj. readinessProbe Preveril sem vrata “management”, vendar sam strežnik ni začel delovati zaradi težav pri nalaganju predpomnilnika.
- priključitev sonde pripravljenosti na ločena vrata lahko privede do dejstva, da se preobremenitev na glavnih vratih ne bo odrazila v pregledu stanja (to pomeni, da je nabor niti na strežniku poln, vendar pregled stanja še vedno kaže, da je vse v redu ).
Poskrbi da sonda pripravljenosti omogoča inicializacijo/selitev baze podatkov;
- To najlažje dosežete tako, da vzpostavite stik s strežnikom HTTP šele po končani inicializaciji (na primer selitev baze podatkov iz Flyway in tako naprej.); to pomeni, da namesto spreminjanja statusa zdravstvenega pregleda preprosto ne zaženete spletnega strežnika, dokler selitev baze podatkov ni končana*.
  * Prav tako lahko zaženete selitve baze podatkov iz init vsebnikov zunaj sklopa. Še vedno sem ljubitelj samostojnih aplikacij, torej takšnih, pri katerih zna vsebnik aplikacije spraviti bazo v želeno stanje brez zunanje koordinacije.
Uporabi httpGet za preverjanje pripravljenosti prek tipičnih končnih točk preverjanja zdravja (npr. /health).
Razumeti privzete parametre preverjanja (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- privzete možnosti pomenijo, da bo pod postal ni pripravljen po približno 30 sekundah (3 neuspeli pregledi razumnosti).
Uporabite ločena vrata za "admin" ali "management", če tehnološki sklad (npr. Java/Spring) to omogoča, da ločite upravljanje zdravja in meritev od običajnega prometa:
- vendar ne pozabite na točko 2.
Če je potrebno, lahko sondo pripravljenosti uporabite za ogrevanje/nalaganje predpomnilnika in vrnete statusno kodo 503, dokler se vsebnik ne segreje:
- Priporočam tudi, da preberete nov ček startupProbe, pojavil v različici 1.16 (o tem smo pisali v ruščini tukaj — pribl. prev.).

Opozorila

Ne zanašajte se na zunanje odvisnosti (kot so podatkovna skladišča) pri izvajanju testov pripravljenosti/živosti - to lahko privede do kaskadnih napak:
- Kot primer vzemimo storitev REST s spremljanjem stanja z 10 podi, odvisnimi od ene baze podatkov Postgres: ko je preverjanje odvisno od delujoče povezave z DB, lahko vseh 10 podov ne uspe, če pride do zakasnitve na strani omrežja/DB - običajno vse se konča slabše, kot bi se lahko;
- Upoštevajte, da Spring Data privzeto preveri povezavo z bazo podatkov*;
  * To je privzeto vedenje Spring Data Redis (vsaj zadnjič, ko sem preveril), kar je povzročilo "katastrofalno" napako: ko je bil Redis kratek čas nedosegljiv, so se vsi podi "zrušili".
- »zunanji« v tem smislu lahko pomeni tudi druge sklope iste aplikacije, kar pomeni, da v idealnem primeru preverjanje ne bi smelo biti odvisno od stanja drugih sklopov iste gruče, da preprečimo kaskadne zrušitve:
  - rezultati se lahko razlikujejo za aplikacije s porazdeljenim stanjem (na primer predpomnjenje v pomnilniku v sklopih).
Ne uporabljajte merilnika moči za stroke (izjema so primeri, ko so res nujni in ste popolnoma seznanjeni s posebnostmi in posledicami njihove uporabe):
- Sonda živahnosti lahko pomaga obnoviti obešene vsebnike, a ker imate popoln nadzor nad svojo aplikacijo, se stvari, kot so obešeni procesi in zastoji, idealno ne bi smele zgoditi: najboljša alternativa je, da namerno zrušite aplikacijo in jo vrnete v prejšnje stabilno stanje;
- neuspešna sonda živosti bo povzročila ponovni zagon vsebnika in s tem potencialno poslabšala posledice napak, povezanih z nalaganjem: ponovni zagon vsebnika bo povzročil izpade (vsaj za čas zagona aplikacije, recimo 30 lihih sekund), kar bo povzročilo nove napake , povečanje obremenitve drugih zabojnikov in povečanje verjetnosti njihove okvare itd.;
- pregledi živosti v kombinaciji z zunanjo odvisnostjo so najslabša možna kombinacija, ki grozi s kaskadnimi okvarami: majhna zamuda na strani baze podatkov bo vodila do ponovnega zagona vseh vaših vsebnikov!
Parametri preverjanja življenjske dobe in pripravljenosti mora biti drugačen:
- lahko uporabite sondo živahnosti z enakim zdravstvenim pregledom, vendar z višjim pragom odziva (failureThreshold), na primer dodelite status ni pripravljen po 3 poskusih in menite, da je bila sonda za okvaro po 10 poskusih;
Ne uporabljajte preverjanj exec, saj so povezani z znanimi težavami, ki vodijo do pojava zombi procesov:
- podrobnosti: glej predstavitev strokovnjakov podjetja Datadog.

Povzetek

Uporabite sonde pripravljenosti, da ugotovite, kdaj je enota pripravljena na sprejem prometa.
Uporabljajte sonde za živahnost le, kadar so res potrebne.
Nepravilna uporaba sond pripravljenosti/živosti lahko privede do zmanjšane razpoložljivosti in kaskadnih okvar.

Dodatno gradivo na to temo

Dokumenti Kubernetes: Konfigurirajte sonde Liveness in Readiness;
Ponovno pregledane sonde Kubernetes Liveness in Readiness Probes: Kako se izogniti streljanju v drugo nogo;
Posmrtni izpad laboratorijev NRE (govori tudi o livenessProbe).

Posodobitev št. 1 od 2019. septembra 09

O init vsebnikih za selitev podatkovne baze: Dodana opomba.

EJ me je spomnil o PPP: ena od težav pri pregledih živahnosti je pomanjkanje koordinacije med stroki. Kubernetes ima Proračuni motenj podov (PDB) za omejitev števila sočasnih napak, ki jih lahko aplikacija doživi, vendar preverjanja ne upoštevajo PPP. V idealnem primeru bi lahko K8s rekli, naj "Znova zažene eno enoto, če njen test ne uspe, vendar ne zaženi znova vseh, da ne bi poslabšali stvari."

Bryan se je odlično izrazil: »Uporabite sondiranje živahnosti, ko natančno veste, kaj najboljša stvar je, da ubiješ aplikacijo« (še enkrat, naj vas ne zanese).

Posodobitev št. 2 od 2019. septembra 09

Glede branja dokumentacije pred uporabo: Ustvaril sem ustrezno zahtevo (zahteva za funkcijo), da dodate dokumentacijo o sondah živahnosti.

PS od prevajalca

Preberite tudi na našem blogu:

Vir: www.habr.com

Sonde živahnosti v Kubernetesu so lahko nevarne