Vivaj sondoj en Kubernetes povas esti danĝeraj

Notu. transl.: Ĉefa inĝeniero de Zalando, Henning Jacobs, plurfoje rimarkis problemojn inter uzantoj de Kubernetes por kompreni la celon de viveco (kaj preteco) enketoj kaj ilia ĝusta uzo. Tial li kolektis siajn pensojn en ĉi tiu ampleksa noto, kiu poste fariĝos parto de la dokumentado de K8s.

Sankontroloj, konataj en Kubernetes kiel sondoj de viveco (t.e., laŭvorte, "daŭrigeblaj testoj" - ĉ. traduk.), povas esti sufiĉe danĝera. Mi rekomendas eviti ilin se eble: la nuraj esceptoj estas kiam ili estas vere necesaj kaj vi plene konscias pri la specifaĵoj kaj sekvoj de ilia uzo. Ĉi tiu eldonaĵo parolos pri viveco kaj pretecaj kontroloj, kaj ankaŭ diros al vi en kiuj kazoj valoras kaj vi ne devus uzi ilin.

Mia kolego Sandor lastatempe konigis en Twitter la plej oftajn erarojn, kiujn li renkontas, inkluzive de tiuj rilataj al la uzo de pretecaj/vivecaj enketoj:

Malĝuste agordita livenessProbe povas plimalbonigi situaciojn de alta ŝarĝo (neĝbulo-fermo + eble longa tempo de lanĉado de ujo/aplikaĵo) kaj konduki al aliaj negativaj sekvoj kiel dependecaj faloj. (Vidu ankaŭ mia lastatempa artikolo pri limigo de la nombro da petoj en la kombinaĵo K3s+ACME). Estas eĉ pli malbona kiam la vivecsondilo estas kombinita kun sankontrolo, kiu estas ekstera datumbazo: ununura DB-malsukceso rekomencos ĉiujn viajn ujojn!

Ĝenerala mesaĝo "Ne uzu vivecsondilojn" ĉi-kaze ĝi ne multe helpas, do ni rigardu por kio estas la pretecaj kaj vivecaj kontroloj.

Noto: Plejparto de la provo malsupre estis origine inkluzivita en la interna ellaboranto dokumentado de Zalando.

Kontroloj de Preteco kaj Vivo

Kubernetes provizas du gravajn mekanismojn nomitajn sondiloj de viveco kaj sondoj de preteco. Ili periode faras iun agon - kiel sendi HTTP-peton, malfermi TCP-konekton aŭ plenumi komandon en la ujo - por konfirmi, ke la aplikaĵo funkcias kiel atendite.

Kubernetes uzas pretaj sondojpor kompreni kiam la ujo estas preta akcepti trafikon. Pod estas konsiderata preta por uzo se ĉiuj ĝiaj ujoj estas pretaj. Unu uzo de ĉi tiu mekanismo estas kontroli kiuj balgoj estas uzataj kiel backends por Kubernetes-servoj (kaj precipe Ingress).

Sondoj de viveco helpu Kubernetes kompreni kiam estas tempo rekomenci la ujon. Ekzemple, tia kontrolo permesas vin kapti blokiĝon kiam aplikaĵo blokiĝas en unu loko. Rekomenci la ujon en ĉi tiu stato helpas ekfunkciigi la aplikaĵon malgraŭ eraroj, sed ĝi ankaŭ povas konduki al kaskadaj fiaskoj (vidu sube).

Se vi provas disfaldi aplikaĵon, kiu malsukcesas la kontrolojn de viveco/preteco, ĝia lanĉo estos haltigita dum Kubernetes atendas la staton. Ready el ĉiuj balgoj.

Ekzemplo:

Jen ekzemplo de preta sondilo kontrolanta vojon /health per HTTP kun defaŭltaj agordoj (intervalo: 10 Sekundoj, ekflugo: 1 sekundo, sukcesa sojlo: 1, malsukcesa sojlo: 3):

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

rekomendoj

1. Por mikroservoj kun HTTP-finpunkto (REST, ktp.) ĉiam difinu pretecan sondon, kiu kontrolas ĉu la aplikaĵo (pod) estas preta akcepti trafikon.
2. Certigu, ke la preteca sondilo kovras la haveblecon de la fakta retservila haveno:
   • uzante havenojn por administraj celoj, nomitaj "administranto" aŭ "administrado" (ekzemple, 9090), por readinessProbe, certigu, ke la finpunkto nur resendas OK se la ĉefa HTTP-haveno (kiel 8080) pretas akcepti trafikon*;

     *Mi konscias pri almenaŭ unu kazo ĉe Zalando, kie tio ne okazis, t.e. readinessProbe Mi kontrolis la "administran" havenon, sed la servilo mem ne ekfunkciis pro problemoj ŝargi la kaŝmemoron.

   • ligi pretecan sondilon al aparta haveno povas konduki al la fakto, ke troŝarĝo sur la ĉefa haveno ne reflektiĝos en la sankontrolo (tio estas, la fadeno sur la servilo estas plena, sed la sankontrolo ankoraŭ montras, ke ĉio estas en ordo. ).
3. Certigu tion preteca sondilo ebligas datumbazan inicialigon/migradon;
   • La plej facila maniero por atingi tion estas kontakti la HTTP-servilon nur post kiam pravalorigo estas kompleta (ekzemple, migrante datumbazon de Flugvojo kaj tiel plu.); tio estas, anstataŭ ŝanĝi la sankontrolan staton, simple ne lanĉu la retservilon ĝis la datumbaza migrado finiĝos*.

     * Vi ankaŭ povas ruli datumbazajn migradojn el init-ujoj ekster la pod. Mi ankoraŭ estas ŝatanto de memstaraj aplikoj, tio estas, tiuj en kiuj la aplikaĵujo scias kiel alporti la datumbazon en la deziratan staton sen ekstera kunordigo.

4. Uzu httpGet por pretecaj kontroloj per tipaj sankontrolaj finpunktoj (ekzemple, /health).
5. Komprenu la defaŭltajn kontrolajn parametrojn (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • la defaŭltaj opcioj signifas, ke la pod fariĝos ne-preta post ĉirkaŭ 30 sekundoj (3 malsukcesaj saneckontroloj).
6. Uzu apartan havenon por "administranto" aŭ "administrado" se la teknologia stako (ekz. Java/Spring) permesas ĝin, por apartigi sanan kaj metrikan administradon de regula trafiko:
   • sed ne forgesu pri punkto 2.
7. Se necese, la preteca sondilo povas esti uzata por varmigi/ŝarĝi la kaŝmemoron kaj resendi statuskodon 503 ĝis la ujo varmiĝas:
   • Mi ankaŭ rekomendas, ke vi legu la novan ĉekon startupProbe, aperis en versio 1.16 (ni skribis pri ĝi en la rusa tie - ĉ. traduk.).

Kavernoj

1. Ne fidu eksterajn dependecojn (kiel datumstokejoj) dum rulado de pretecaj/vivecaj testoj - tio povas konduki al kaskadaj fiaskoj:
   • Ekzemple, ni prenu ŝtatan REST-servon kun 10 podoj depende de unu Postgres-datumbazo: kiam la kontrolo dependas de funkcianta konekto al la DB, ĉiuj 10 podoj povas malsukcesi se estas prokrasto ĉe la reto/DB-flanko - kutime ĝi ĉio finiĝas pli malbona ol ĝi povus;
   • Bonvolu noti, ke Spring Data kontrolas la datumbazan konekton defaŭlte*;

     * Jen la defaŭlta konduto de Spring Data Redis (almenaŭ ĝi estis la lastan fojon kiam mi kontrolis), kio kaŭzis "katastrofan" fiaskon: kiam Redis estis neatingebla por mallonga tempo, ĉiuj balgoj "kraŝis".

   • "ekstera" en ĉi tiu signifo ankaŭ povas signifi aliajn podojn de la sama aplikaĵo, tio estas, ideale la kontrolo ne devus dependi de la stato de aliaj podoj de la sama areto por malhelpi kaskadajn kraŝojn:
     • rezultoj povas varii por aplikoj kun distribuita stato (ekzemple, en-memora kaŝmemoro en podoj).
2. Ne uzu vivecsondilon por podoj (esceptoj estas kazoj kiam ili estas vere necesaj kaj vi plene konscias pri la specifaĵoj kaj konsekvencoj de ilia uzo):
   • Vivo-enketo povas helpi reakiri penditajn ujojn, sed ĉar vi havas plenan kontrolon de via aplikaĵo, aferoj kiel penditaj procezoj kaj blokiĝo devus ideale ne okazi: la plej bona alternativo estas intence kraŝi la aplikaĵon kaj revenigi ĝin al antaŭa stabila stato;
   • malsukcesa vivec-enketo igos la ujon rekomenci, tiel eble plimalbonigante la sekvojn de ŝarĝo-rilataj eraroj: rekomenci la ujon rezultigos malfunkcion (almenaŭ dum la daŭro de la aplikaĵkomenco, diru 30-neparajn sekundojn), kaŭzante novajn erarojn. , pliigante la ŝarĝon sur aliaj ujoj kaj pliigante la verŝajnecon de ilia fiasko, ktp.;
   • vivkontroloj kombinitaj kun ekstera dependeco estas la plej malbona ebla kombinaĵo, minacante kaskadaj fiaskoj: eta prokrasto ĉe la datumbazo kondukos al rekomenco de ĉiuj viaj ujoj!
3. Parametroj de viveco kaj preteco-kontroloj devas esti malsama:
   • vi povas uzi vivecsondilon kun la sama sankontrolo, sed pli alta responda sojlo (failureThreshold), ekzemple, atribui la statuson ne-preta post 3 provoj kaj konsideru, ke la sondilo de viveco malsukcesis post 10 provoj;
4. Ne uzu ekzekutkontrolojn, ĉar ili estas asociitaj kun konataj problemoj, kiuj kondukas al apero de zombiaj procezoj:
   • detaloj: vidu prezento de Datadog-specialistoj.

Resumo

• Uzu pretecajn enketojn por determini kiam pod estas preta ricevi trafikon.
• Uzu vivecsondilojn nur kiam ili vere bezonas.
• Nedeca uzo de pretecaj/vivecaj enketoj povas konduki al reduktita havebleco kaj kaskadaj fiaskoj.

Pliaj materialoj pri la temo

• Dokumentoj de Kubernetes: Agordi Sondojn pri Vivo kaj Preteco;
• Enketoj pri Vivo kaj Preteco de Kubernetes Revizita: Kiel Eviti Pafi Vin en la Alia Piedo;
• NRE Labs Outage Post-Mortem (li ankaŭ parolas pri vivenessProbe).

Ĝisdatigo n-ro 1 de 2019-09-29

Pri init-ujoj por datumbaza migrado: Piednoto aldonita.

EJ memorigis min pri PDB: unu el la problemoj kun vivkontroloj estas la manko de kunordigo inter podoj. Kubernetes havas Pod-interrompaj Buĝetoj (PDB) limigi la nombron da samtempaj malsukcesoj kiujn aplikaĵo povas sperti, sed la kontroloj ne konsideras la PDB. Ideale, ni povus diri al K8s "Rekomenci unu pod se ĝia testo malsukcesas, sed ne rekomencu ilin ĉiujn por eviti plimalbonigi aferojn."

Bryan esprimis ĝin perfekte: “Uzu vivecon sondante kiam vi scias precize kio la plej bona afero por fari estas mortigi la aplikaĵon"(denove, ne lasu forporti).

Ĝisdatigo n-ro 2 de 2019-09-29

Pri legado de la dokumentado antaŭ uzo: Mi kreis la respondan peton (trajto peto) por aldoni dokumentadon pri vivecaj sondoj.

PS de tradukisto

Legu ankaŭ en nia blogo:

• «Kubernetes: Pod Life»;
• «7 plej bonaj praktikoj por uzi ujojn laŭ Guglo»;
• «7 Principoj por Dezajnado de Uj-Bazitaj Aplikoj".

fonto: www.habr.com