🥇 Lewendigheidsondersoeke in Kubernetes kan gevaarlik wees

Let wel. vertaal.: Hoofingenieur van Zalando, Henning Jacobs, het herhaaldelik probleme onder Kubernetes-gebruikers opgemerk om die doel van lewendheid (en gereedheid) probes en hul korrekte gebruik te verstaan. Daarom het hy sy gedagtes in hierdie ruim nota versamel, wat uiteindelik deel van die K8s-dokumentasie sal word.

Gesondheidsondersoeke, bekend in Kubernetes as lewendheidsondersoeke (d.w.s. letterlik "lewensvatbaarheidstoetse" - ongeveer vertaal.), kan nogal gevaarlik wees. Ek beveel aan om dit te vermy indien moontlik: die enigste uitsonderings is wanneer dit werklik nodig is en jy ten volle bewus is van die besonderhede en gevolge van die gebruik daarvan. Hierdie publikasie sal praat oor lewenskragtigheid en gereedheidskontroles, en sal jou ook vertel in watter gevalle is en jy moet dit nie gebruik nie.

My kollega Sandor het onlangs op Twitter die mees algemene foute wat hy teëkom, gedeel, insluitend dié wat verband hou met die gebruik van gereedheid-/lewenskragsondersoeke:

Verkeerd opgestel livenessProbe kan hoë-ladingsituasies vererger (sneeubal-afskakeling + potensieel lang houer/toepassing begintyd) en lei tot ander negatiewe gevolge soos afhanklikheiddalings (sien ook my onlangse artikel oor die beperking van die aantal versoeke in die K3s+ACME-kombinasie). Dit is selfs erger as die lewendheidsondersoek gekombineer word met 'n gesondheidsondersoek, wat 'n eksterne databasis is: 'n enkele DB-fout sal al jou houers herbegin!

Algemene boodskap "Moenie lewendige sondes gebruik nie" in hierdie geval help dit nie veel nie, so kom ons kyk waarvoor die gereedheids- en lewenskragkontroles is.

Let wel: Die meeste van die toets hieronder is oorspronklik in Zalando se interne ontwikkelaardokumentasie ingesluit.

Gereedheids- en Lewensheidskontroles

Kubernetes verskaf twee belangrike meganismes genoem lewendheidsondersoeke en gereedheidsondersoeke. Hulle voer van tyd tot tyd een of ander aksie uit - soos om 'n HTTP-versoek te stuur, 'n TCP-verbinding oop te maak of 'n opdrag in die houer uit te voer - om te bevestig dat die toepassing soos verwag werk.

Kubernetes gebruik gereedheidsondersoekeom te verstaan wanneer die houer gereed is om verkeer te aanvaar. 'n Peul word as gereed vir gebruik beskou as al sy houers gereed is. Een gebruik van hierdie meganisme is om te beheer watter peule as backends vir Kubernetes-dienste (en veral Ingress) gebruik word.

Lewendigheidsondersoeke help Kubernetes om te verstaan wanneer dit tyd is om die houer te herbegin. So 'n tjek laat jou byvoorbeeld toe om 'n dooie punt te onderskep wanneer 'n toepassing op een plek vashaak. Deur die houer in hierdie toestand te herbegin, help dit om die toepassing van die grond af te kry ten spyte van foute, maar dit kan ook lei tot deurlopende mislukkings (sien hieronder).

As jy probeer om 'n programopdatering te ontplooi wat nie die lewendheid-/gereedheidskontrole slaag nie, sal die ontplooiing daarvan geblokkeer word terwyl Kubernetes wag vir die status Ready uit alle peule.

Voorbeeld

Hier is 'n voorbeeld van 'n gereedheidsondersoek wat 'n pad nagaan /health via HTTP met verstek instellings (interval: 10 sekondes, Time-out: 1 sekonde, suksesdrempel: 1, mislukkingsdrempel: 3):

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

Aanbevelings

Vir mikrodienste met HTTP-eindpunt (RES, ens.) definieer altyd 'n gereedheidsondersoek, wat kyk of die toepassing (peul) gereed is om verkeer te aanvaar.
Maak seker dat die gereedheidsonde dek die beskikbaarheid van die werklike webbedienerpoort:
- gebruik van poorte vir administratiewe doeleindes, genoem "admin" of "bestuur" (byvoorbeeld, 9090), vir readinessProbe, maak seker dat die eindpunt slegs OK terugkeer as die primêre HTTP-poort (soos 8080) gereed is om verkeer te aanvaar*;
  *Ek is bewus van ten minste een geval by Zalando waar dit nie gebeur het nie, m.a.w. readinessProbe Ek het die "bestuur"-poort nagegaan, maar die bediener self het nie begin werk nie as gevolg van probleme met die laai van die kas.
- om 'n gereedheidsondersoek aan 'n aparte poort te koppel, kan daartoe lei dat oorlading op die hoofpoort nie in die gesondheidskontrole weerspieël sal word nie (dit wil sê, die draadpoel op die bediener is vol, maar die gesondheidsondersoek wys steeds dat alles in orde is ).
Maak seker dat gereedheidsondersoek maak databasisinisialisering/migrasie moontlik;
- Die maklikste manier om dit te bereik is om eers die HTTP-bediener te kontak nadat inisialisering voltooi is (byvoorbeeld, migreer 'n databasis vanaf vliegpad en so aan.); dit wil sê, in plaas daarvan om die gesondheidskontrole-status te verander, moet eenvoudig nie die webbediener begin voordat die databasismigrasie voltooi is* nie.
  * Jy kan ook databasismigrasies vanaf inithouers buite die peul laat loop. Ek is steeds 'n aanhanger van selfstandige toepassings, dit wil sê dié waarin die toepassinghouer weet hoe om die databasis in die verlangde toestand te bring sonder eksterne koördinasie.
Gebruik httpGet vir gereedheidskontroles deur tipiese gesondheidskontrole-eindpunte (byvoorbeeld, /health).
Verstaan die verstek tjek parameters (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- die verstek opsies beteken dat die peul sal word nie gereed nie na ongeveer 30 sekondes (3 mislukte gesonde verstandkontrole).
Gebruik 'n aparte poort vir "admin" of "bestuur" as die tegnologiestapel (bv. Java/Spring) dit toelaat, om gesondheids- en statistiekbestuur van gewone verkeer te skei:
- maar moenie van punt 2 vergeet nie.
Indien nodig, kan die gereedheidsonde gebruik word om die kas op te warm/laai en 'n 503-statuskode terug te gee totdat die houer opwarm:
- Ek beveel ook aan dat jy die nuwe tjek lees startupProbe, verskyn in weergawe 1.16 (ons het daaroor in Russies geskryf hier - ongeveer. vertaal.).

waarsku

Moenie op eksterne afhanklikhede staatmaak nie (soos datapakhuise) wanneer gereedheids-/lewenskragtoetse uitgevoer word - dit kan lei tot oorlopende mislukkings:
- As 'n voorbeeld, kom ons neem 'n stateful REST-diens met 10 peule, afhangend van een Postgres-databasis: wanneer die kontrole afhang van 'n werkende verbinding met die DB, kan al 10 peule misluk as daar 'n vertraging aan die netwerk/DB-kant is - gewoonlik alles eindig erger as wat dit kon;
- Neem asseblief kennis dat Spring Data die databasisverbinding by verstek nagaan*;
  * Dit is die verstekgedrag van Spring Data Redis (dit was ten minste die laaste keer wat ek nagegaan het), wat gelei het tot 'n "katastrofiese" mislukking: toe Redis vir 'n kort rukkie onbeskikbaar was, het alle peule "gecrash".
- "ekstern" in hierdie sin kan ook ander peule van dieselfde toepassing beteken, dit wil sê, ideaal gesproke behoort die kontrole nie afhanklik te wees van die toestand van ander peule van dieselfde groep om kaskade-ongelukke te voorkom nie:
  - resultate kan verskil vir toepassings met verspreide toestand (byvoorbeeld, in-geheue-kas in peule).
Moenie 'n lewendige sonde gebruik nie vir peule (uitsonderings is gevalle wanneer dit regtig nodig is en jy ten volle bewus is van die besonderhede en gevolge van hul gebruik):
- 'n Lewendigheidsondersoek kan help om gehang houers te herstel, maar aangesien jy volle beheer oor jou toepassing het, behoort dinge soos gehang prosesse en dooiepunte ideaal gesproke nie te gebeur nie: die beste alternatief is om die toepassing doelbewus te laat crash en dit terug te bring na vorige bestendige toestand;
- 'n mislukte lewendheidsondersoek sal veroorsaak dat die houer herbegin, en daardeur moontlik die gevolge van laaiverwante foute vererger: herbegin van die houer sal stilstand tot gevolg hê (ten minste vir die duur van die toepassing se begin, sê 30 sekondes), wat nuwe foute veroorsaak , die verhoging van die vrag op ander houers en die verhoging van die waarskynlikheid van hul mislukking, ens.;
- lewendheidskontroles gekombineer met 'n eksterne afhanklikheid is die ergste moontlike kombinasie, wat dreigende mislukkings dreig: 'n effense vertraging aan die databasiskant sal lei tot 'n herbegin van al jou houers!
Parameters van lewenskragtigheid en gereedheidskontroles moet anders wees:
- jy kan 'n lewendheidsondersoek met dieselfde gesondheidsondersoek gebruik, maar 'n hoër reaksiedrempel (failureThreshold), ken byvoorbeeld die status toe nie gereed nie na 3 pogings en neem in ag dat die lewendheidsondersoek na 10 pogings misluk het;
Moenie exec-tjeks gebruik nie, aangesien hulle geassosieer word met bekende probleme wat lei tot die voorkoms van zombieprosesse:
- besonderhede: sien aanbieding deur Datadog-spesialiste.

Opsomming

Gebruik gereedheidsondersoeke om te bepaal wanneer 'n peul gereed is om verkeer te ontvang.
Gebruik lewendheidsondersoeke slegs wanneer dit regtig nodig is.
Onbehoorlike gebruik van gereedheid-/lewenskrag-probes kan lei tot verminderde beskikbaarheid en deurlopende mislukkings.

Bykomende materiaal oor die onderwerp

Opdatering nr. 1 vanaf 2019-09-29

Oor init-houers vir databasismigrasie: Voetnoot bygevoeg.

EJ het my herinner oor VOB: een van die probleme met lewenskragkontroles is die gebrek aan koördinasie tussen peule. Kubernetes het Peulontwrigtingbegrotings (PDB) om die aantal gelyktydige mislukkings wat 'n toepassing kan ervaar te beperk, maar die kontroles neem nie die VOB in ag nie. Ideaal gesproke kan ons vir K8s sê om "een peul weer te begin as sy toets misluk, maar moenie hulle almal herbegin om te verhoed dat dinge erger word nie."

Bryan het dit perfek gestel: “Gebruik lewendige ondersoek wanneer jy presies weet wat die beste ding om te doen is om die toepassing dood te maak"(Weereens, moenie meegevoer raak nie).

Opdatering nr. 2 vanaf 2019-09-29

Met betrekking tot die lees van die dokumentasie voor gebruik: Ek het die ooreenstemmende versoek geskep (funksie versoek) om dokumentasie oor lewendheidsondersoeke by te voeg.

Lewendigheidsondersoeke in Kubernetes kan gevaarlik wees