ProHoster > Dienoraštis > Administravimas > Gyvumo zondai Kubernetes gali būti pavojingi

Gyvumo zondai Kubernetes gali būti pavojingi

Pastaba. vert.: Pagrindinis inžinierius iš Zalando Henningas Jacobsas ne kartą pastebėjo, kad Kubernetes naudotojai nesupranta gyvumo (ir parengties) zondų paskirties ir teisingo jų naudojimo. Todėl jis surinko savo mintis šiame talpiame užraše, kuris ilgainiui taps K8s dokumentacijos dalimi.

Gyvumo zondai Kubernetes gali būti pavojingi

Sveikatos patikrinimai, žinomi Kubernetes kaip gyvumo zondai (t. y. pažodžiui „gyvybingumo testai“ – apytikslis vertimas), gali būti gana pavojinga. Jei įmanoma, rekomenduoju jų vengti: vienintelės išimtys yra tada, kai jos tikrai būtinos ir jūs puikiai žinote jų naudojimo specifiką ir pasekmes. Šiame leidinyje bus kalbama apie gyvumo ir parengties patikrinimus, taip pat bus pasakyta, kokiais atvejais yra ir jūs neturėtumėte jų naudoti.

Mano kolega Sandoras neseniai socialiniame tinkle „Twitter“ pasidalijo dažniausiai pasitaikančiomis klaidomis, įskaitant tas, kurios yra susijusios su parengties / gyvumo zondų naudojimu:

Gyvumo zondai Kubernetes gali būti pavojingi

Neteisingai sukonfigūruotas livenessProbe gali pabloginti didelės apkrovos situacijas (sniego gniūžtės išjungimas + galimai ilgas konteinerio / programos paleidimo laikas) ir sukelti kitų neigiamų pasekmių, pvz., priklausomybės sumažėjimą (taip pat žr mano paskutinis straipsnis apie užklausų skaičiaus apribojimą K3s + ACME derinyje). Dar blogiau, kai gyvumo zondas derinamas su sveikatos patikrinimu, kuris yra išorinė duomenų bazė: DB gedimas iš naujo paleis visus konteinerius!

Bendras pranešimas „Nenaudokite gyvumo zondų“ šiuo atveju tai nelabai padeda, tad pažiūrėkime, kam skirti pasirengimo ir gyvumo patikros.

Pastaba: didžioji toliau pateikto testo dalis iš pradžių buvo įtraukta į „Zalando“ vidinę kūrėjo dokumentaciją.

Pasirengimo ir gyvumo patikrinimai

„Kubernetes“ pateikia du svarbius mechanizmus, vadinamus gyvumo zondai ir parengties zondai. Jie periodiškai atlieka tam tikrus veiksmus, pvz., siunčia HTTP užklausą, atidaro TCP ryšį arba vykdo komandą konteineryje, kad patvirtintų, jog programa veikia taip, kaip tikėtasi.

Kubernetes naudoja parengties zondaisuprasti, kada konteineris yra pasirengęs priimti srautą. Ankštis laikoma paruošta naudoti, jei visos jos talpyklos yra paruoštos. Vienas iš šio mechanizmo panaudojimo būdų yra kontroliuoti, kurie blokai naudojami kaip „Kubernetes“ paslaugų (ir ypač „Ingress“) užpakalinės programos.

Gyvumo zondai padėti Kubernetes suprasti, kada laikas iš naujo paleisti konteinerį. Pavyzdžiui, toks patikrinimas leidžia perimti aklavietę, kai programa užstringa vienoje vietoje. Tokios būsenos sudėtinio rodinio paleidimas iš naujo padeda paleisti programą nepaisant klaidų, tačiau tai taip pat gali sukelti pakopinio gedimo (žr. toliau).

Jei bandysite įdiegti programos naujinimą, kuriam nepavyks patikrinti gyvybingumo / parengties, jo išleidimas bus sustabdytas, nes „Kubernetes“ lauks būsenos Ready iš visų ankščių.

Pavyzdys

Čia yra parengties zondo, tikrinančio kelią, pavyzdys /health per HTTP su numatytaisiais nustatymais (intervalas: 10 sekundžių, laukimas: 1 sekundė, sėkmės slenkstis: 1, nesėkmės slenkstis: 3):

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

Rekomendacijos

  1. Mikropaslaugoms su HTTP galutiniu tašku (REST ir kt.) visada apibrėžkite parengties zondą, kuris patikrina, ar programa (pod) yra paruošta priimti srautą.
  2. Įsitikinkite, kad yra parengties zondas apima faktinio žiniatinklio serverio prievado prieinamumą:
    • naudojant prievadus administravimo tikslais, vadinamus „admin“ arba „valdymu“ (pavyzdžiui, 9090), readinessProbe, įsitikinkite, kad galutinis taškas grąžina OK tik tuo atveju, jei pagrindinis HTTP prievadas (pvz., 8080) yra pasirengęs priimti srautą*;

      *Žinau bent vieną atvejį Zalande, kai taip neatsitiko, t.y. readinessProbe Patikrinau "valdymo" prievadą, bet pats serveris nepradėjo veikti dėl talpyklos įkėlimo problemų.

    • pasirengimo zondo prijungimas prie atskiro prievado gali lemti tai, kad pagrindinio prievado perkrova neatsispindės būklės patikrinime (ty serverio gijų telkinys yra pilnas, bet būklės patikrinimas vis tiek rodo, kad viskas gerai ).
  3. Įsitikinti, kad parengties zondas leidžia inicijuoti / perkelti duomenų bazę;
    • Lengviausias būdas tai pasiekti yra susisiekti su HTTP serveriu tik baigus inicijavimą (pavyzdžiui, perkėlus duomenų bazę iš Flyway ir taip toliau.); tai yra, užuot pakeitę būsenos patikrinimo būseną, tiesiog nepaleiskite žiniatinklio serverio, kol nebus baigtas duomenų bazės perkėlimas*.

      * Taip pat galite paleisti duomenų bazių perkėlimą iš init konteinerių, esančių už podelio ribų. Aš vis dar esu savarankiškų programų, ty tų, kuriose programų konteineris žino, kaip perkelti duomenų bazę į norimą būseną be išorinio derinimo, gerbėjas.

  4. Naudokite httpGet pasirengimo patikrinimams pagal tipinius sveikatos patikrinimo galutinius taškus (pvz., /health).
  5. Supraskite numatytuosius tikrinimo parametrus (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
    • numatytosios parinktys reiškia, kad podelis taps nepasirengusi maždaug po 30 sekundžių (3 nepavykę sveiko proto patikrinimai).
  6. Naudokite atskirą prievadą „administratoriui“ arba „valdymui“, jei technologijų rinkinys (pvz., „Java“ / „Spring“) tai leidžia, kad atskirtumėte sveikatos ir metrikos valdymą nuo įprasto srauto:
    • bet nepamiršk 2 punkto.
  7. Jei reikia, parengties zondą galima naudoti talpyklai sušildyti / įkelti ir grąžinti 503 būsenos kodą, kol konteineris sušils:
    • Taip pat rekomenduoju perskaityti naują čekį startupProbe, pasirodė 1.16 versijoje (apie tai rašėme rusiškai čia - apytiksliai vertimas.).

Įspėjimai

  1. Nepasikliaukite išorinėmis priklausomybėmis (pvz., duomenų saugyklos), kai vykdomi parengties / veikimo bandymai – tai gali sukelti pakopinius gedimus:
    • Kaip pavyzdį paimkime būseną rodančią REST paslaugą su 10 blokų, priklausomai nuo vienos Postgres duomenų bazės: kai tikrinimas priklauso nuo veikiančio ryšio su DB, visi 10 podų gali sugesti, jei yra uždelsimas tinklo / DB pusėje – paprastai taip. viskas baigiasi blogiau, nei galėtų;
    • Atkreipkite dėmesį, kad Spring Data pagal numatytuosius nustatymus tikrina duomenų bazės ryšį*;

      * Tai yra numatytasis „Spring Data Redis“ elgesys (bent jau paskutinį kartą tikrinau), dėl kurio įvyko „katastrofiškas“ gedimas: kai „Redis“ buvo trumpą laiką nepasiekiamas, „sugriuvo“ visos ankštys.

    • „Išorinis“ šia prasme taip pat gali reikšti kitus tos pačios programos blokus, t.
      • Paskirstytos būsenos programų rezultatai gali skirtis (pavyzdžiui, talpyklos kaupimas atmintyje talpyklose).
  2. Nenaudokite gyvumo zondo ankštims (išimtys yra atvejai, kai jie tikrai būtini ir jūs puikiai žinote jų naudojimo specifiką ir pasekmes):
    • Gyvumo zondas gali padėti atkurti pakabintus konteinerius, tačiau kadangi jūs visiškai kontroliuojate savo programą, idealiu atveju tokių dalykų kaip pakabinti procesai ir aklavietės neturėtų atsitikti: geriausia alternatyva yra sąmoningai sugriauti programą ir grąžinti ją į ankstesnę pastovią būseną;
    • sugedus gyvumo zondui, konteineris bus paleistas iš naujo, o tai gali sustiprinti su įkėlimu susijusių klaidų pasekmes: iš naujo paleidus konteinerį, trūks prastovos (bent jau programos paleidimo metu, tarkime, 30 sekundžių), ir atsiras naujų klaidų. , didinant kitų konteinerių apkrovą ir didinant jų gedimo tikimybę ir pan.;
    • gyvumo patikrinimai kartu su išorine priklausomybe yra blogiausias įmanomas derinys, keliantis grėsmę pakopiniams gedimams: nedidelis delsimas duomenų bazės pusėje lems visų jūsų konteinerių paleidimą iš naujo!
  3. Gyvumo ir parengties patikrinimų parametrai turi skirtis:
    • galite naudoti gyvumo zondą su tuo pačiu patikrinimu, bet aukštesniu atsako slenksčiu (failureThreshold), pavyzdžiui, priskirti būseną nepasirengusi po 3 bandymų ir mano, kad gyvumo zondas nepavyko po 10 bandymų;
  4. Nenaudokite vykdymo patikrinimų, nes jie yra susiję su žinomomis problemomis, dėl kurių atsiranda zombių procesai:

Santrauka

  • Naudokite parengties zondus, kad nustatytumėte, kada modulis yra pasirengęs priimti srautą.
  • Gyvumo zondus naudokite tik tada, kai jų tikrai reikia.
  • Netinkamai naudojant parengties / gyvybingumo zondus gali sumažėti pasiekiamumas ir gali atsirasti pakopinių gedimų.

Gyvumo zondai Kubernetes gali būti pavojingi

Papildoma medžiaga šia tema

Atnaujinimas Nr.1 ​​nuo 2019-09-29

Apie duomenų bazių perkėlimo init konteinerius: pridėta išnaša.

EJ man priminė apie PBP: viena iš gyvumo patikrų problemų yra ankščių koordinavimo trūkumas. Kubernetes turi Pod Disruption Biudžetai (PBP) siekiant apriboti vienu metu galimų programos gedimų skaičių, tačiau atliekant patikras neatsižvelgiama į PBP. Idealiu atveju galėtume nurodyti K8s: „Iš naujo paleiskite vieną bloką, jei jo bandymas nepavyksta, bet nepaleiskite jų iš naujo, kad nepablogintumėte situacijos“.

Bryanas tai puikiai pasakė: „Naudokite gyvumo zondavimą, kai tiksliai žinote, ką Geriausias dalykas yra užmušti programą“ (vėlgi, nenusimink).

Gyvumo zondai Kubernetes gali būti pavojingi

Atnaujinimas Nr.2 ​​nuo 2019-09-29

Dėl dokumentacijos skaitymo prieš naudojimą: sukūriau atitinkamą užklausą (funkcijos užklausa), kad pridėtumėte dokumentus apie gyvumo zondus.

PS iš vertėjo

Taip pat skaitykite mūsų tinklaraštyje:

Šaltinis: www.habr.com

Добавить комментарий