Uchunguzi wa maisha katika Kubernetes unaweza kuwa hatari

Kumbuka. tafsiri.: Mhandisi mkuu kutoka Zalando, Henning Jacobs, amegundua mara kwa mara matatizo miongoni mwa watumiaji wa Kubernetes katika kuelewa madhumuni ya uchunguzi hai (na utayari) na matumizi yao sahihi. Kwa hivyo, alikusanya mawazo yake katika noti hii ya uwezo, ambayo hatimaye itakuwa sehemu ya nyaraka za K8s.

Ukaguzi wa afya, unaojulikana katika Kubernetes kama uchunguzi wa uhai (yaani, kihalisi, "majaribio ya uwezekano" - takriban transl.), inaweza kuwa hatari sana. Ninapendekeza kuziepuka ikiwezekana: isipokuwa pekee ni wakati zinahitajika sana na unafahamu kikamilifu maalum na matokeo ya matumizi yao. Mchapishaji huu utazungumza juu ya uchanganuzi wa uhai na utayari, na pia utakuambia katika hali gani ni na hupaswi kuzitumia.

Mwenzangu Sandor hivi majuzi alishiriki kwenye Twitter makosa ya kawaida anayokumbana nayo, yakiwemo yale yanayohusiana na utumiaji wa uchunguzi wa utayari/uhai:

Imesanidiwa vibaya livenessProbe inaweza kuzidisha hali ya upakiaji wa juu (kuzima kwa mpira wa theluji + chombo kirefu kinachoweza kuwa na muda wa kuanza kwa programu) na kusababisha matokeo mengine mabaya kama vile kushuka kwa utegemezi. (Angalia pia makala yangu ya hivi karibuni kuhusu kupunguza idadi ya maombi katika mchanganyiko wa K3s+ACME). Ni mbaya zaidi wakati uchunguzi wa uhai unapojumuishwa na ukaguzi wa afya, ambao ni hifadhidata ya nje: kushindwa kwa DB moja kutaanzisha tena vyombo vyako vyote!

Ujumbe wa jumla "Usitumie uchunguzi wa uhai" katika kesi hii haina msaada sana, basi hebu tuangalie ni nini utayari na hundi za uhai ni za.

Kumbuka: Majaribio mengi yaliyo hapa chini yalijumuishwa katika hati za msanidi wa ndani wa Zalando.

Hundi za Utayari na Uhai

Kubernetes hutoa njia mbili muhimu zinazoitwa uchunguzi wa uhai na uchunguzi wa utayari. Mara kwa mara hufanya kitendo fulani—kama vile kutuma ombi la HTTP, kufungua muunganisho wa TCP, au kutekeleza amri kwenye chombo—ili kuthibitisha kwamba programu inafanya kazi inavyotarajiwa.

Kubernetes hutumia uchunguzi wa utayarikuelewa wakati kontena iko tayari kukubali trafiki. Poda inachukuliwa kuwa tayari kutumika ikiwa vyombo vyake vyote viko tayari. Matumizi moja ya utaratibu huu ni kudhibiti ni maganda yapi yanatumika kama viambajengo vya huduma za Kubernetes (na hasa Ingress).

Uchunguzi wa maisha msaidie Kubernetes kuelewa ni wakati gani wa kuwasha tena kontena. Kwa mfano, hundi kama hiyo hukuruhusu kukatiza kizuizi wakati programu inakwama katika sehemu moja. Kuanzisha tena kontena katika hali hii husaidia kuondoa programu chini licha ya makosa, lakini kunaweza pia kusababisha hitilafu za kuporomoka (tazama hapa chini).

Ukijaribu kupeleka sasisho la programu ambalo litashindwa ukaguzi wa uhai/utayari, uchapishaji wake utasitishwa huku Kubernetes ikisubiri hali hiyo. Ready kutoka kwa maganda yote.

Mfano

Hapa kuna mfano wa uchunguzi wa utayari kuangalia njia /health kupitia HTTP na mipangilio chaguo-msingi (Interval: Sekunde 10, muda umeisha: sekunde 1, kizingiti cha mafanikio: 1, kizingiti cha kushindwa: 3):

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

Mapendekezo

1. Kwa huduma ndogo zilizo na mwisho wa HTTP (REST, nk.) daima fafanua uchunguzi wa utayari, ambayo hukagua ikiwa programu (pod) iko tayari kukubali trafiki.
2. Hakikisha uchunguzi wa utayari inashughulikia upatikanaji wa bandari halisi ya seva ya wavuti:
   • kutumia bandari kwa madhumuni ya kiutawala, inayoitwa "admin" au "usimamizi" (kwa mfano, 9090), kwa readinessProbe, hakikisha kuwa sehemu ya mwisho inarudi sawa ikiwa lango msingi la HTTP (kama 8080) liko tayari kukubali trafiki*;

     *Ninafahamu angalau kisa kimoja kule Zalando ambapo hili halikufanyika, i.e. readinessProbe Niliangalia bandari ya "usimamizi", lakini seva yenyewe haikuanza kufanya kazi kutokana na matatizo ya kupakia cache.

   • kushikilia uchunguzi wa utayari kwenye bandari tofauti kunaweza kusababisha ukweli kwamba upakiaji mwingi kwenye bandari kuu hautaonyeshwa kwenye ukaguzi wa afya (ambayo ni, dimbwi la nyuzi kwenye seva limejaa, lakini ukaguzi wa afya bado unaonyesha kuwa kila kitu ni sawa. )
3. Hakikisha kwamba uchunguzi wa utayari huwezesha uanzishaji/uhamiaji wa hifadhidata;
   • Njia rahisi zaidi ya kufikia hili ni kuwasiliana na seva ya HTTP tu baada ya uanzishaji kukamilika (kwa mfano, kuhamisha hifadhidata kutoka Njia ya kuruka Nakadhalika.); yaani, badala ya kubadilisha hali ya ukaguzi wa afya, usianzishe seva ya wavuti hadi uhamishaji wa hifadhidata ukamilike*.

     * Unaweza pia kuendesha uhamishaji wa hifadhidata kutoka kwa vyombo vya init nje ya ganda. Mimi bado ni shabiki wa programu zinazojitegemea, yaani, zile ambazo chombo cha maombi kinajua jinsi ya kuleta hifadhidata katika hali inayotakiwa bila uratibu wa nje.

4. Tumia httpGet kwa ukaguzi wa utayari kupitia vituo vya kawaida vya ukaguzi wa afya (kwa mfano, /health).
5. Kuelewa vigezo vya kuangalia chaguo-msingi (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • chaguzi chaguo-msingi inamaanisha kuwa ganda litakuwa si-tayari baada ya sekunde 30 (kaguzi 3 za akili zilizoshindwa).
6. Tumia mlango tofauti wa "msimamizi" au "usimamizi" ikiwa safu ya teknolojia (k.m. Java/Spring) inaruhusu, kutenganisha usimamizi wa afya na vipimo kutoka kwa trafiki ya kawaida:
   • lakini usisahau kuhusu point 2.
7. Ikihitajika, uchunguzi wa utayari unaweza kutumika kupasha/kupakia kashe na kurudisha msimbo wa hali 503 hadi chombo kipate joto:
   • Ninapendekeza pia usome hundi mpya startupProbe, ilionekana katika toleo la 1.16 (tuliandika juu yake kwa Kirusi hapa - takriban. tafsiri.).

Mimba

1. Usitegemee utegemezi wa nje (kama vile maghala ya data) wakati wa kufanya majaribio ya utayari/uhai - hii inaweza kusababisha kushindwa kwa kasi:
   • Kama mfano, wacha tuchukue huduma ya hali ya juu ya REST na ganda 10 kulingana na hifadhidata moja ya Postgres: wakati cheki inategemea unganisho la kufanya kazi kwa DB, maganda yote 10 yanaweza kushindwa ikiwa kuna kucheleweshwa kwa upande wa mtandao/DB - kawaida ni. yote mwisho mbaya zaidi kuliko inaweza;
   • Tafadhali kumbuka kuwa Data ya Spring hukagua muunganisho wa hifadhidata kwa chaguo-msingi*;

     * Hii ni tabia ya chaguo-msingi ya Spring Data Redis (angalau ilikuwa mara ya mwisho nilipoangalia), ambayo ilisababisha kushindwa kwa "janga": wakati Redis haikupatikana kwa muda mfupi, maganda yote "yalianguka".

   • "ya nje" kwa maana hii inaweza pia kumaanisha maganda mengine ya matumizi sawa, yaani, cheki haipaswi kutegemea hali ya maganda mengine ya nguzo sawa ili kuzuia ajali zinazotokea:
     • matokeo yanaweza kutofautiana kwa programu zilizo na hali iliyosambazwa (kwa mfano, akiba ya kumbukumbu kwenye maganda).
2. Usitumie uchunguzi wa uhai kwa maganda (isipokuwa ni kesi wakati zinahitajika sana na unajua kabisa maalum na matokeo ya matumizi yao):
   • Uchunguzi wa uhai unaweza kusaidia kurejesha vyombo vilivyoning'inia, lakini kwa kuwa una udhibiti kamili wa programu yako, mambo kama vile michakato ya kuning'inia na mikwaruzo haifai kutokea: njia bora zaidi ni kuvunja programu kimakusudi na kuirejesha katika hali thabiti ya awali;
   • uchunguzi wa uhai ulioshindwa utasababisha kontena kuanza upya, na hivyo basi kuzidisha matokeo ya makosa yanayohusiana na upakiaji: kuwasha tena kontena kutasababisha muda wa chini (angalau kwa muda wa uanzishaji wa programu, sema sekunde 30-isiyo ya kawaida), na kusababisha makosa mapya. , kuongeza mzigo kwenye vyombo vingine na kuongeza uwezekano wa kushindwa kwao, nk;
   • ukaguzi wa uhai pamoja na utegemezi wa nje ndio mchanganyiko mbaya zaidi unaowezekana, unaotishia kutofaulu: kucheleweshwa kidogo kwa upande wa hifadhidata kutasababisha kuanza tena kwa vyombo vyako vyote!
3. Vigezo vya uchanganuzi wa uhai na utayari lazima iwe tofauti:
   • unaweza kutumia uchunguzi wa uhai na ukaguzi sawa wa afya, lakini kiwango cha juu cha majibu (failureThreshold), kwa mfano, weka hali si-tayari baada ya majaribio 3 na kuzingatia kwamba uchunguzi wa uhai umeshindwa baada ya majaribio 10;
4. Usitumie ukaguzi wa exec, kwa kuwa zinahusishwa na shida zinazojulikana ambazo husababisha kuonekana kwa michakato ya zombie:
   • maelezo: tazama uwasilishaji na wataalamu wa Datadog.

Muhtasari

• Tumia uchunguzi wa utayari kubaini wakati ganda liko tayari kupokea trafiki.
• Tumia uchunguzi wa uhai wakati tu zinahitajika sana.
• Utumizi usiofaa wa uchunguzi wa utayari/uhuishaji unaweza kusababisha kupungua kwa upatikanaji na kushindwa kwa kasi.

Vifaa vya ziada kwenye mada

• Hati za Kubernetes: Sanidi Uchambuzi wa Uhai na Utayari;
• Uchunguzi wa Uhai na Utayari wa Kubernetes Umekaguliwa upya: Jinsi ya Kuepuka Kujipiga Risasi kwenye Mguu Mwingine;
• Maabara ya NRE yamezimika baada ya kifo (pia anazungumzia livenessProbe).

Sasisha nambari 1 kutoka 2019-09-29

Kuhusu vyombo vya init vya uhamishaji wa hifadhidata: Tanbihi imeongezwa.

EJ alinikumbusha kuhusu PDB: mojawapo ya matatizo ya ukaguzi wa uhai ni ukosefu wa uratibu kati ya maganda. Kubernetes ana Bajeti za Usumbufu wa Pod (PDB) ili kupunguza idadi ya kushindwa kwa wakati mmoja ambayo programu inaweza kupata, hata hivyo ukaguzi hauzingatii PDB. Kwa hakika, tunaweza kuwaambia K8s "Anzisha upya ganda moja ikiwa jaribio lake litafeli, lakini usizizinze upya zote ili kuepuka kufanya mambo kuwa mabaya zaidi."

Bryan aliiweka kikamilifu: “Tumia uchanganuzi hai wakati unajua ni nini hasa jambo bora kufanya ni kuua maombi"(tena, usichukuliwe).

Sasisha nambari 2 kutoka 2019-09-29

Kuhusu kusoma nyaraka kabla ya matumizi: Niliunda ombi linalolingana (ombi la huduma) kuongeza hati kuhusu uchunguzi wa uhai.

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

• «Kubernetes: Maisha ya Pod";
• «Mbinu 7 bora za kutumia vyombo kulingana na Google";
• «Kanuni 7 za Kubuni Programu Zinazotegemea Kontena'.

Chanzo: mapenzi.com