Ang liveness probe sa Kubernetes mahimong delikado

Nota. transl.: Ang nanguna nga inhenyero gikan sa Zalando, Henning Jacobs, balik-balik nga nakamatikod sa mga problema sa mga tiggamit sa Kubernetes sa pagsabot sa katuyoan sa liveness (ug pagkaandam) nga mga pagsusi ug sa hustong paggamit niini. Busa, gikolekta niya ang iyang mga hunahuna niining lapad nga nota, nga sa kadugayan mahimong bahin sa dokumentasyon sa K8s.

Ang mga pagsusi sa kahimsog, nailhan sa Kubernetes nga liveness probes (i.e., sa literal, “mga pagsulay nga mabuhi” - gibanabana nga transl.), mahimong delikado kaayo. Girekomenda ko nga likayan kini kung mahimo: ang mga eksepsiyon ra kung kini kinahanglan gyud ug nahibal-an nimo ang mga detalye ug sangputanan sa paggamit niini. Kini nga publikasyon maghisgot bahin sa liveness ug kaandam nga mga pagsusi, ug isulti usab kanimo kung unsang mga kaso bililhon ug dili nimo kini gamiton.

Bag-o lang gipaambit sa akong kauban nga si Sandor sa Twitter ang labing kasagarang mga sayup nga iyang nasugatan, lakip ang mga may kalabutan sa paggamit sa mga pagsusi sa pagkaandam/kabuhayan:

Sayop nga na-configure livenessProbe mahimong makapasamot sa mga sitwasyon nga taas ang karga (snowball shutdown + posibleng taas nga container/application startup time) ug mosangpot sa uban pang negatibong resulta sama sa dependency drops (tan-awa usab akong bag-o nga artikulo mahitungod sa paglimit sa gidaghanon sa mga hangyo sa kombinasyon sa K3s+ACME). Mas grabe pa kung ang liveness probe gihiusa sa usa ka pagsusi sa kahimsog, nga usa ka eksternal nga database: usa ka kapakyasan sa DB ang mag-restart sa tanan nimong mga sulud!

Kinatibuk-ang mensahe "Ayaw gamita ang liveness probes" sa niini nga kaso kini dili makatabang kaayo, mao nga atong tan-awon sa unsa ang kaandam ug liveness pagsusi alang sa.

Hinumdomi: Kadaghanan sa pagsulay sa ubos orihinal nga gilakip sa dokumentasyon sa internal nga developer sa Zalando.

Kaandam ug Liveness checks

Ang Kubernetes naghatag og duha ka importante nga mekanismo nga gitawag liveness probes ug ready probes. Kanunay nilang gihimo ang pipila ka aksyon—sama sa pagpadala og HTTP nga hangyo, pag-abli og koneksyon sa TCP, o pagpatuman og command sa sudlanan—aron makumpirma nga ang aplikasyon nagtrabaho sama sa gipaabot.

Gigamit sa Kubernetes mga pagsusi sa pagkaandamaron masabtan kung ang sudlanan andam na nga modawat sa trapiko. Ang usa ka pod gikonsiderar nga andam na gamiton kung ang tanan nga mga sudlanan niini andam na. Usa ka paggamit niini nga mekanismo mao ang pagkontrolar kung unsang mga pod ang gigamit isip mga backend para sa mga serbisyo sa Kubernetes (ug ilabina sa Ingress).

Liveness nga pagsusi tabangi ang mga Kubernetes nga masabtan kung panahon na nga i-restart ang sudlanan. Pananglitan, ang ingon nga tseke nagtugot kanimo sa pag-intercept sa usa ka deadlock kung ang usa ka aplikasyon ma-stuck sa usa ka lugar. Ang pag-restart sa sudlanan niini nga estado makatabang sa pagkuha sa aplikasyon gikan sa yuta bisan pa sa mga kasaypanan, apan mahimo usab kini nga mosangpot sa mga kapakyasan sa cascading (tan-awa sa ubos).

Kung mosulay ka sa pag-deploy og update sa aplikasyon nga mapakyas sa liveness/readiness checks, ang rollout niini mahunong samtang ang Kubernetes naghulat sa status Ready gikan sa tanang pod.

Pananglitan:

Ania ang usa ka pananglitan sa usa ka kaandam nga pagsusi sa usa ka agianan /health pinaagi sa HTTP nga adunay default setting (agianan: 10 segundos, timeout: 1 segundos, sukdanan sa kalampusan: 1, kapakyasan threshold:3):

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

rekomendasyon

1. Para sa mga microservice nga adunay HTTP endpoint (REST, etc.) kanunay ipasabut ang usa ka probe sa pagkaandam, nga nagsusi kung ang aplikasyon (pod) andam na nga modawat sa trapiko.
2. Siguroha ang pagkaandam probe naglangkob sa pagkaanaa sa aktuwal nga web server port:
   • gamit ang mga pantalan alang sa administratibo nga katuyoan, gitawag nga "admin" o "pagdumala" (pananglitan, 9090), alang sa readinessProbe, siguroha nga ang endpoint mobalik lang og OK kung ang nag-unang HTTP port (sama sa 8080) andam na nga modawat sa trapiko*;

     *Nakahibalo ko nga bisan usa ka kaso sa Zalando kung diin wala kini nahitabo, i.e. readinessProbe Gisusi nako ang "pagdumala" nga pantalan, apan ang server mismo wala magsugod sa pagtrabaho tungod sa mga problema sa pagkarga sa cache.

   • Ang paglakip sa usa ka andam nga pagsusi sa usa ka lahi nga pantalan mahimong mosangpot sa kamatuoran nga ang sobra nga gibug-aton sa main port dili makita sa pagsusi sa kahimsog (nga mao, ang thread pool sa server puno, apan ang pagsusi sa kahimsog nagpakita gihapon nga OK ra ang tanan. ).
3. Siguruha nga Ang pagkaandam nga pagsusi makahimo sa database initialization/migration;
   • Ang pinakasayon ​​nga paagi aron makab-ot kini mao ang pagkontak sa HTTP server human lang makompleto ang initialization (pananglitan, pagbalhin sa database gikan sa Flyway ug uban pa.); kana mao, imbes nga usbon ang kahimtang sa pagsusi sa kahimsog, ayaw lang pagsugod sa web server hangtod mahuman ang pagbalhin sa database.

     * Mahimo ka usab magpadagan sa mga pagbalhin sa database gikan sa mga sulud sa init sa gawas sa pod. Usa pa ako ka fan sa mga aplikasyon nga adunay kaugalingon nga kaugalingon, nga mao, kung diin nahibal-an sa sudlanan sa aplikasyon kung giunsa ang pagdala sa database sa gusto nga estado nga wala’y koordinasyon sa gawas.

4. Paggamit httpGet alang sa mga pagsusi sa kaandam pinaagi sa kasagaran nga mga endpoint sa pagsusi sa kahimsog (pananglitan, /health).
5. Sabta ang default check parameters (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ang default nga mga kapilian nagpasabot nga ang pod mahimong dili andam human sa mga 30 segundos (3 napakyas sa sanity checks).
6. Paggamit ug bulag nga pantalan para sa "admin" o "pagdumala" kung ang teknolohiya stack (e.g. Java/Spring) nagtugot niini, sa pagbulag sa panglawas ug metrics management gikan sa regular nga trapiko:
   • pero ayaw kalimti ang point 2.
7. Kung gikinahanglan, ang probe sa pagkaandam mahimong gamiton sa pagpainit/pagkarga sa cache ug pagbalik sa 503 status code hangtud nga ang sudlanan moinit:
   • Girekomenda ko usab nga basahon nimo ang bag-ong tseke startupProbe, nagpakita sa bersyon 1.16 (Gisulat namon kini sa Russian dinhi - gibanabana. transl.).

Mga Kaayuhan

1. Ayaw pagsalig sa mga eksternal nga dependency (sama sa mga bodega sa datos) kung nagpadagan sa mga pagsulay sa pagkaandam/kabuhayan - mahimo’g mosangput kini sa mga kapakyasan sa kaskad:
   • Isip usa ka pananglitan, atong kuhaon ang usa ka stateful nga REST nga serbisyo nga adunay 10 pods depende sa usa ka Postgres database: kung ang tseke nagdepende sa usa ka nagtrabaho nga koneksyon sa DB, ang tanan nga 10 pods mahimong mapakyas kung adunay usa ka paglangan sa network / DB nga bahin - kasagaran kini ang tanan matapos nga mas grabe pa kay sa mahimo;
   • Palihug timan-i nga ang Spring Data nagsusi sa database connection pinaagi sa default*;

     * Kini ang default nga kinaiya sa Spring Data Redis (labing menos kini ang katapusan nga higayon nga akong gisusi), nga misangpot sa usa ka "katalagman" nga kapakyasan: sa dihang ang Redis wala magamit sa mubo nga panahon, ang tanan nga mga pod "nahagsa".

   • Ang "eksternal" niini nga diwa mahimo usab nga magpasabot sa ubang mga pod nga parehas nga aplikasyon, nga mao, ang tseke kinahanglan dili magdepende sa kahimtang sa ubang mga pod sa parehas nga cluster aron malikayan ang mga pag-crash sa cascading:
     • Ang mga resulta mahimong magkalainlain alang sa mga aplikasyon nga adunay giapod-apod nga estado (pananglitan, in-memorya nga pag-cache sa mga pod).
2. Ayaw paggamit ug liveness probe alang sa mga pod (mga eksepsiyon kay mga kaso kung gikinahanglan gyud kini ug hingpit ka nga nakahibalo sa mga detalye ug mga sangputanan sa ilang paggamit):
   • Ang liveness probe makatabang sa pagbawi sa gibitay nga mga sudlanan, apan tungod kay ikaw adunay bug-os nga kontrol sa imong aplikasyon, ang mga butang sama sa gibitay nga mga proseso ug mga deadlock kinahanglan nga dili mahitabo: ang labing maayo nga alternatibo mao ang tinuyo nga pag-crash sa aplikasyon ug ibalik kini sa kaniadto nga makanunayon nga kahimtang;
   • ang usa ka napakyas nga liveness probe magpahinabo sa sudlanan nga ma-restart, sa ingon mahimo’g makapasamot sa mga sangputanan sa mga sayup nga may kalabutan sa pagkarga: ang pag-restart sa sudlanan magresulta sa downtime (labing menos sa gidugayon sa pagsugod sa aplikasyon, ingnon ta 30-odd segundos), hinungdan sa mga bag-ong sayup , pagdugang sa load sa ubang mga sudlanan ug sa pagdugang sa kalagmitan sa ilang kapakyasan, ug uban pa;
   • liveness checks inubanan sa usa ka eksternal nga dependency mao ang pinakagrabe nga posible nga kombinasyon, nga naghulga sa mga kapakyasan sa cascading: ang usa ka gamay nga paglangan sa database nga bahin mosangpot sa pag-restart sa tanan nimong mga sudlanan!
3. Parameter sa liveness ug kaandam checks kinahanglan nga lahi:
   • mahimo nimong gamiton ang liveness probe nga adunay parehas nga pagsusi sa kahimsog, apan mas taas nga sukaranan sa pagtubag (failureThreshold), pananglitan, i-assign ang status dili andam human sa 3 ka pagsulay ug hunahunaa nga ang liveness probe napakyas human sa 10 ka pagsulay;
4. Ayaw gamita ang mga exec check, tungod kay nakig-uban sila sa nahibal-an nga mga problema nga nagdala sa dagway sa mga proseso sa zombie:
   • mga detalye: tan-awa presentasyon sa mga espesyalista sa Datadog.

Sumaryo

• Gamita ang mga probe sa pagkaandam aron mahibal-an kung ang usa ka pod andam na nga makadawat sa trapiko.
• Gamita lang ang liveness probes kung gikinahanglan gyud kini.
• Ang dili husto nga paggamit sa mga probe sa pagkaandam/liveness mahimong mosangpot sa pagkunhod sa pagkaanaa ug mga kapakyasan sa cascading.

Dugang nga mga materyal sa hilisgutan

• Kubernetes docs: I-configure ang Liveness ug Readiness Probes;
• Ang Kubernetes Liveness ug Readiness Probes Gisusi pag-usab: Unsaon Paglikay sa Pagpusil sa Imong Kaugalingon sa Ubang Tiil;
• Ang NRE Labs Outage Post-Mortem (naghisgot usab siya bahin sa livenessProbe).

Update No. 1 gikan sa 2019-09-29

Mahitungod sa init nga mga sudlanan alang sa paglalin sa database: Gidugang ang footnote.

Gipahinumdoman ko ni EJ bahin sa PDB: usa sa mga problema sa liveness checks mao ang kakuwang sa koordinasyon tali sa mga pod. Ang Kubernetes adunay Pod Disruption Budgets (PDB) aron limitahan ang gidaghanon sa dungan nga mga kapakyasan nga masinati sa usa ka aplikasyon, bisan pa ang mga tseke wala magtagad sa PDB. Sa tinuud, mahimo namon isulti ang mga K8 nga "I-restart ang usa ka pod kung mapakyas ang pagsulay niini, apan ayaw i-restart silang tanan aron malikayan ang paghimo sa mga butang nga mas grabe."

Gibutang kini ni Bryan sa hingpit: "Gamita ang liveness probing kung nahibal-an nimo kung unsa ang labing maayo nga butang nga buhaton mao ang pagpatay sa aplikasyon"(pag-usab, ayaw pagpadalin-as).

Update No. 2 gikan sa 2019-09-29

Mahitungod sa pagbasa sa dokumentasyon sa dili pa gamiton: Gibuhat nako ang katugbang nga hangyo (hangyo sa bahin) aron idugang ang dokumentasyon bahin sa liveness probes.

PS gikan sa tighubad

Basaha usab sa among blog:

• «Kubernetes: Pod Life";
• «7 labing maayo nga mga gawi sa paggamit sa mga sudlanan sumala sa Google";
• «7 Mga Prinsipyo sa Pagdesinyo sa mga Aplikasyon nga Gibase sa Container".

Source: www.habr.com