🥇Ang liveness probe sa Kubernetes ay maaaring mapanganib

Tandaan. transl.: Ang lead engineer mula sa Zalando, Henning Jacobs, ay paulit-ulit na nakapansin ng mga problema sa mga gumagamit ng Kubernetes sa pag-unawa sa layunin ng liveness (at kahandaan) na mga probe at ang tamang paggamit nito. Samakatuwid, nakolekta niya ang kanyang mga saloobin sa malawak na tala na ito, na sa kalaunan ay magiging bahagi ng dokumentasyon ng K8.

Mga pagsusuri sa kalusugan, na kilala sa Kubernetes bilang liveness probes (ibig sabihin, literal, "mga pagsubok sa kakayahang mabuhay" - tinatayang transl.), ay maaaring maging lubhang mapanganib. Inirerekumenda ko na iwasan ang mga ito kung maaari: ang tanging mga pagbubukod ay kapag sila ay talagang kinakailangan at lubos mong nalalaman ang mga detalye at kahihinatnan ng kanilang paggamit. Tatalakayin ng publikasyong ito ang tungkol sa mga pagsusuri sa kasiglahan at kahandaan, at sasabihin din sa iyo kung anong mga kaso ay at hindi mo dapat gamitin ang mga ito.

Ibinahagi kamakailan ng aking kasamahan na si Sandor sa Twitter ang mga pinakakaraniwang error na nararanasan niya, kabilang ang mga nauugnay sa paggamit ng ready/liveness probes:

Maling na-configure livenessProbe maaaring magpalala sa mga sitwasyong may mataas na karga (snowball shutdown + potensyal na mahabang container/oras ng pagsisimula ng application) at humantong sa iba pang negatibong kahihinatnan gaya ng pagbaba ng dependency (Tingnan din ang aking kamakailang artikulo tungkol sa paglilimita sa bilang ng mga kahilingan sa kumbinasyon ng K3s+ACME). Mas malala pa kapag ang liveness probe ay pinagsama sa isang health check, na isang panlabas na database: isang solong DB failure ang magre-restart sa lahat ng iyong container!

Pangkalahatang mensahe "Huwag gumamit ng liveness probes" sa kasong ito, hindi ito nakakatulong nang malaki, kaya tingnan natin kung para saan ang mga pagsusuri sa pagiging handa at buhay.

Tandaan: Karamihan sa pagsubok sa ibaba ay orihinal na kasama sa dokumentasyon ng internal na developer ng Zalando.

Pagsusuri sa pagiging handa at kasiglahan

Nagbibigay ang Kubernetes ng dalawang mahalagang mekanismo na tinatawag liveness probes at readiness probes. Pana-panahon silang nagsasagawa ng ilang pagkilos—gaya ng pagpapadala ng kahilingan sa HTTP, pagbubukas ng koneksyon sa TCP, o pagsasagawa ng command sa container—upang kumpirmahin na gumagana ang application gaya ng inaasahan.

Ginagamit ng Kubernetes mga probe ng kahandaanupang maunawaan kung kailan handa na ang lalagyan na tumanggap ng trapiko. Ang isang pod ay itinuturing na handa nang gamitin kung ang lahat ng mga lalagyan nito ay handa na. Ang isang paggamit ng mekanismong ito ay upang kontrolin kung aling mga pod ang ginagamit bilang mga backend para sa mga serbisyo ng Kubernetes (at lalo na ang Ingress).

Liveness probes tulungan ang mga Kubernete na maunawaan kung oras na upang i-restart ang container. Halimbawa, binibigyang-daan ka ng naturang tseke na ma-intercept ang deadlock kapag na-stuck ang isang application sa isang lugar. Ang pag-restart ng container sa ganitong estado ay nakakatulong na alisin ang application sa kabila ng mga error, ngunit maaari rin itong humantong sa mga pagkabigo ng cascading (tingnan sa ibaba).

Kung susubukan mong mag-deploy ng update ng application na nabigo sa liveness/readiness checks, ang paglulunsad nito ay mapipigil habang hinihintay ng Kubernetes ang status Ready mula sa lahat ng pods.

Halimbawa

Narito ang isang halimbawa ng isang kahandaang pagsisiyasat ng isang landas /health sa pamamagitan ng HTTP na may mga default na setting (agwat: 10 Segundo, oras: 1 segundo, threshold ng tagumpay: 1, threshold ng kabiguan: 3):

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

Rekomendasyon

Para sa mga microservice na may HTTP endpoint (REST, atbp.) palaging tukuyin ang isang kahandaan probe, na nagsusuri kung ang application (pod) ay handa nang tumanggap ng trapiko.
Siguraduhin na ang kahandaan probe sumasaklaw sa pagkakaroon ng aktwal na port ng web server:
- gamit ang mga port para sa mga layuning pang-administratibo, na tinatawag na "admin" o "pamamahala" (halimbawa, 9090), para sa readinessProbe, tiyaking OK lang ang babalik ng endpoint kung ang pangunahing HTTP port (tulad ng 8080) ay handa nang tumanggap ng trapiko*;
  *Alam ko ang kahit isang kaso sa Zalando kung saan hindi ito nangyari, i.e. readinessProbe Sinuri ko ang port ng "pamamahala", ngunit ang server mismo ay hindi nagsimulang gumana dahil sa mga problema sa paglo-load ng cache.
- Ang pag-attach ng isang ready probe sa isang hiwalay na port ay maaaring humantong sa katotohanan na ang labis na karga sa pangunahing port ay hindi makikita sa pagsusuri sa kalusugan (iyon ay, ang thread pool sa server ay puno, ngunit ang pagsusuri sa kalusugan ay nagpapakita pa rin na ang lahat ay OK. ).
Siguraduhin na Ang ready probe ay nagbibigay-daan sa database initialization/migration;
- Ang pinakamadaling paraan upang makamit ito ay makipag-ugnayan lamang sa HTTP server pagkatapos makumpleto ang pagsisimula (halimbawa, paglilipat ng database mula sa Flyway at iba pa.); ibig sabihin, sa halip na baguhin ang status ng pagsusuri sa kalusugan, huwag lang simulan ang web server hanggang sa makumpleto ang paglilipat ng database*.
  * Maaari ka ring magpatakbo ng mga paglilipat ng database mula sa mga lalagyan ng init sa labas ng pod. Fan pa rin ako ng mga self-contained na application, iyon ay, ang mga kung saan alam ng container ng application kung paano dalhin ang database sa nais na estado nang walang panlabas na koordinasyon.
Gamitin httpGet para sa mga pagsusuri sa kahandaan sa pamamagitan ng karaniwang mga endpoint ng pagsusuri sa kalusugan (halimbawa, /health).
Unawain ang mga default na parameter ng pagsusuri (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- ang mga default na opsyon ay nangangahulugan na ang pod ay magiging Hindi pa handa pagkatapos ng humigit-kumulang 30 segundo (3 nabigong pagsusuri sa katinuan).
Gumamit ng hiwalay na port para sa "admin" o "pamamahala" kung pinapayagan ito ng stack ng teknolohiya (hal. Java/Spring), na paghiwalayin ang pamamahala sa kalusugan at mga sukatan mula sa regular na trapiko:
- ngunit huwag kalimutan ang tungkol sa punto 2.
Kung kinakailangan, ang readiness probe ay maaaring gamitin para magpainit/mag-load ng cache at magbalik ng 503 status code hanggang sa uminit ang container:
- Inirerekomenda ko rin na basahin mo ang bagong tseke startupProbe, lumitaw sa bersyon 1.16 (isinulat namin ang tungkol dito sa Russian dito — tinatayang. transl.).

Mga Caveat

Huwag umasa sa mga panlabas na dependency (tulad ng mga warehouse ng data) kapag nagpapatakbo ng mga pagsubok sa pagiging handa/buhay - ito ay maaaring humantong sa mga pagkabigo ng cascading:
- Bilang halimbawa, kumuha tayo ng stateful REST service na may 10 pods depende sa isang Postgres database: kapag ang check ay depende sa gumaganang koneksyon sa DB, lahat ng 10 pods ay maaaring mabigo kung may pagkaantala sa network/DB side - kadalasan ito lahat ay nagtatapos nang mas masahol pa kaysa sa maaari;
- Pakitandaan na sinusuri ng Spring Data ang koneksyon sa database bilang default*;
  * Ito ang default na pag-uugali ng Spring Data Redis (kahit ito ang huling beses na sinuri ko), na humantong sa isang "catastrophic" na pagkabigo: kapag ang Redis ay hindi magagamit sa maikling panahon, ang lahat ng mga pod ay "nag-crash".
- Ang "panlabas" sa kahulugang ito ay maaari ding mangahulugan ng iba pang mga pod ng parehong aplikasyon, iyon ay, ang tseke ay hindi dapat nakasalalay sa estado ng iba pang mga pod ng parehong kumpol upang maiwasan ang mga cascading crash:
  - maaaring mag-iba ang mga resulta para sa mga application na may distributed state (halimbawa, in-memory caching sa mga pod).
Huwag gumamit ng liveness probe para sa mga pod (ang mga eksepsiyon ay mga kaso kung kailan talagang kinakailangan ang mga ito at lubos mong nalalaman ang mga detalye at kahihinatnan ng paggamit ng mga ito):
- Makakatulong ang liveness probe na mabawi ang mga nakasabit na container, ngunit dahil may ganap kang kontrol sa iyong aplikasyon, ang mga bagay tulad ng mga proseso ng pag-hang at deadlock ay hindi dapat mangyari: ang pinakamagandang alternatibo ay ang sadyang i-crash ang application at ibalik ito sa dating steady state;
- ang isang nabigong liveness probe ay magiging sanhi ng pag-restart ng container, at sa gayon ay potensyal na magpapalala sa mga kahihinatnan ng mga error na nauugnay sa paglo-load: ang pag-restart ng container ay magreresulta sa downtime (hindi bababa sa tagal ng pagsisimula ng application, sabihin nating 30-odd na segundo), na magdudulot ng mga bagong error , pagtaas ng load sa iba pang mga lalagyan at pagtaas ng posibilidad ng kanilang pagkabigo, atbp.;
- Ang mga pagsusuri sa liveness na sinamahan ng isang panlabas na dependency ay ang pinakamasamang posibleng kumbinasyon, na nagbabanta sa mga pagkabigo ng cascading: ang isang bahagyang pagkaantala sa panig ng database ay hahantong sa pag-restart ng lahat ng iyong mga lalagyan!
Mga parameter ng liveness at readiness checks dapat iba:
- maaari kang gumamit ng liveness probe na may parehong pagsusuri sa kalusugan, ngunit mas mataas na threshold ng pagtugon (failureThreshold), halimbawa, italaga ang katayuan Hindi pa handa pagkatapos ng 3 pagtatangka at isaalang-alang na ang liveness probe ay nabigo pagkatapos ng 10 pagtatangka;
Huwag gumamit ng mga exec check, dahil nauugnay ang mga ito sa mga kilalang problema na humahantong sa paglitaw ng mga proseso ng zombie:
- mga detalye: tingnan pagtatanghal ng mga dalubhasa sa Datadog.

Buod

Gumamit ng mga probe ng kahandaan upang matukoy kung ang isang pod ay handa nang tumanggap ng trapiko.
Gumamit lamang ng liveness probes kung talagang kailangan ang mga ito.
Ang hindi wastong paggamit ng mga probe para sa pagiging handa/buhay ay maaaring humantong sa pagbawas ng kakayahang magamit at mga pagkabigo sa cascading.

Karagdagang mga materyales sa paksa

Kubernetes docs: I-configure ang Liveness at Readiness Probes;
Muling binisita ang Kubernetes Liveness and Readiness Probes: Paano Iwasang Mabaril ang Iyong Sarili sa kabilang Paa;
Post-Mortem na Outage ng NRE Labs (kinakausap din niya ang tungkol sa livenessProbe).

Update No. 1 mula 2019-09-29

Tungkol sa mga lalagyan ng init para sa paglipat ng database: Idinagdag ang talababa.

paalala sakin ni EJ tungkol sa PDB: isa sa mga problema sa liveness checks ay ang kawalan ng koordinasyon sa pagitan ng mga pod. Ang Kubernetes ay mayroon Pod Disruption Budgets (PDB) upang limitahan ang bilang ng mga kasabay na pagkabigo na maaaring maranasan ng isang aplikasyon, gayunpaman ang mga pagsusuri ay hindi isinasaalang-alang ang PDB. Sa isip, maaari naming sabihin sa K8s na "I-restart ang isang pod kung nabigo ang pagsubok nito, ngunit huwag i-restart ang lahat upang maiwasang lumala ang mga bagay."

Tamang-tama ang pagkakalagay ni Bryan: “Gumamit ng liveness probing kapag alam mo kung ano mismo ang pinakamagandang gawin ay patayin ang application"(muli, huwag kang madala).

Update No. 2 mula 2019-09-29

Tungkol sa pagbabasa ng dokumentasyon bago gamitin: Nilikha ko ang kaukulang kahilingan (hiling sa tampok) para magdagdag ng dokumentasyon tungkol sa liveness probes.

PS mula sa tagasalin

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Maaaring mapanganib ang liveness probe sa Kubernetes