Mbinu Bora za Vyombo vya Kubernetes: Ukaguzi wa Afya

TL; DR

• Ili kufikia uangalizi wa juu wa vyombo na huduma ndogo, kumbukumbu na metriki za msingi hazitoshi.
• Kwa urejeshaji haraka na uthabiti ulioongezeka, programu tumizi zinapaswa kutumia Kanuni ya Juu ya Uangalizi (HOP).
• Katika kiwango cha maombi, NOP inahitaji: ukataji miti ifaayo, ufuatiliaji wa karibu, ukaguzi wa utimamu wa akili, na ufuatiliaji wa utendaji/mpito.
• Tumia hundi kama kipengele cha NOR utayariProbe и livenessProbe Kubernetes.

Je, Kiolezo cha Kukagua Afya ni nini?

Wakati wa kubuni programu-tumizi muhimu sana na inayopatikana sana, ni muhimu sana kufikiria juu ya kipengele kama vile uvumilivu wa makosa. Programu inachukuliwa kuwa ya kustahimili makosa ikiwa itapona haraka kutokana na kutofaulu. Programu ya kawaida ya wingu hutumia usanifu wa microservices - ambapo kila sehemu huwekwa kwenye chombo tofauti. Na ili kuhakikisha kuwa programu kwenye k8s inapatikana sana unapotengeneza nguzo, unahitaji kufuata mifumo fulani. Miongoni mwao ni Kiolezo cha Kuangalia Afya. Inafafanua jinsi programu inavyowasiliana na k8s kwamba ni nzuri. Hii sio habari tu kuhusu ikiwa pod inaendesha, lakini pia kuhusu jinsi inavyopokea na kujibu maombi. Kadiri Kubernetes anavyojua kuhusu afya ya ganda hilo, ndivyo inavyofanya maamuzi nadhifu kuhusu uelekezaji wa trafiki na kusawazisha mizigo. Kwa hivyo, Kanuni ya Uangalizi wa Juu inaruhusu programu kujibu maombi kwa wakati ufaao.

Kanuni ya Uangalifu wa Juu (HOP)

Kanuni ya uchunguzi wa juu ni mojawapo ya kanuni za kubuni programu zilizo na vyombo. Katika usanifu wa huduma ndogo, huduma hazijali jinsi ombi lao linashughulikiwa (na ni sawa), lakini cha muhimu ni jinsi wanavyopokea majibu kutoka kwa huduma zinazopokea. Kwa mfano, ili kuthibitisha mtumiaji, chombo kimoja hutuma ombi la HTTP kwa mwingine, kutarajia jibu katika muundo fulani - ndivyo tu. PythonJS inaweza pia kushughulikia ombi, na Flask ya Python inaweza kujibu. Vyombo ni kama visanduku vyeusi vilivyofichwa kwa kila kimoja. Hata hivyo, kanuni ya NOP inahitaji kila huduma kufichua ncha nyingi za API ambazo zinaonyesha jinsi ilivyo afya, pamoja na utayari wake na hali ya kustahimili makosa. Kubernetes anaomba viashirio hivi ili kufikiria hatua zinazofuata za uelekezaji na kusawazisha upakiaji.

Programu ya wingu iliyoundwa vizuri hurekodi matukio yake makuu kwa kutumia mitiririko ya kawaida ya I/O STDERR na STDOUT. Inayofuata inakuja huduma ya usaidizi, kwa mfano mpigo wa faili, logstash au ufasaha, kutoa kumbukumbu kwa mfumo wa ufuatiliaji wa kati (kwa mfano Prometheus) na mfumo wa kukusanya kumbukumbu (ELK programu suite). Mchoro ulio hapa chini unaonyesha jinsi programu ya wingu inavyofanya kazi kulingana na Mchoro wa Jaribio la Afya na Kanuni ya Juu ya Kuzingatiwa.

Jinsi ya kutumia Mchoro wa Kuangalia Afya katika Kubernetes?

Nje ya kisanduku, k8s hufuatilia hali ya maganda kwa kutumia moja ya vidhibiti (Mipango, ReplicaSets, DaemonSets, StatefulSets nk., nk). Baada ya kugundua kuwa pod imeanguka kwa sababu fulani, mtawala anajaribu kuifungua upya au kuihamisha kwenye nodi nyingine. Walakini, ganda linaweza kuripoti kuwa iko na inafanya kazi, lakini yenyewe haifanyi kazi. Wacha tutoe mfano: programu yako hutumia Apache kama seva ya wavuti, umesakinisha kijenzi kwenye maganda kadhaa ya nguzo. Kwa kuwa maktaba ilisanidiwa vibaya, maombi yote kwa programu hujibu na nambari 500 (kosa la seva ya ndani). Wakati wa kuangalia utoaji, kuangalia hali ya maganda hutoa matokeo mafanikio, lakini wateja wanafikiri tofauti. Tutaelezea hali hii isiyofaa kama ifuatavyo:

Katika mfano wetu, k8s hufanya ukaguzi wa utendaji. Katika aina hii ya uthibitishaji, kubelet hukagua kila wakati hali ya mchakato kwenye kontena. Mara tu akielewa kuwa mchakato umesimama, ataanzisha tena. Ikiwa hitilafu inaweza kutatuliwa kwa kuanzisha upya programu tu, na programu imeundwa kuzima hitilafu yoyote, basi ukaguzi wa afya wa mchakato ndio unahitaji tu kufuata NOP na Muundo wa Mtihani wa Afya. Huruma pekee ni kwamba sio makosa yote yanaondolewa kwa kuanza tena. Katika kesi hii, k8s inatoa njia 2 za kina za kutambua shida na ganda: livenessProbe и utayariProbe.

LivenessProbe

Wakati wa livenessProbe kubelet hufanya ukaguzi wa aina 3: sio tu huamua ikiwa ganda linaendelea, lakini pia ikiwa iko tayari kupokea na kujibu maombi vya kutosha:

• Sanidi ombi la HTTP kwenye ganda. Jibu lazima liwe na msimbo wa majibu wa HTTP katika safu kutoka 200 hadi 399. Kwa hivyo, misimbo 5xx na 4xx inaashiria kuwa ganda lina matatizo, ingawa mchakato unaendelea.
• Ili kujaribu maganda na huduma zisizo za HTTP (kwa mfano, seva ya barua ya Postfix), unahitaji kuanzisha muunganisho wa TCP.
• Tekeleza amri ya kiholela kwa ganda (ndani). Cheki inachukuliwa kuwa imefanikiwa ikiwa nambari ya kukamilisha amri ni 0.

Mfano wa jinsi hii inavyofanya kazi. Ufafanuzi unaofuata wa ganda una programu ya NodeJS inayotuma hitilafu 500 kwenye maombi ya HTTP. Ili kuhakikisha kuwa kontena limewashwa upya wakati wa kupokea hitilafu kama hiyo, tunatumia kigezo cha livenessProbe:

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

Hii sio tofauti na ufafanuzi mwingine wowote wa ganda, lakini tunaongeza kitu .spec.containers.livenessProbe. Kigezo httpGet inakubali njia ambayo ombi la HTTP GET linatumwa (kwa mfano wetu hii ni /, lakini katika matukio ya kupambana kunaweza kuwa na kitu kama /api/v1/status) LivenessProbe nyingine inakubali kigezo initialDelaySeconds, ambayo inaagiza operesheni ya uthibitishaji kusubiri idadi maalum ya sekunde. Ucheleweshaji unahitajika kwa sababu chombo kinahitaji muda ili kuanza, na kikiwashwa upya hakitapatikana kwa muda fulani.

Ili kutumia mpangilio huu kwa nguzo, tumia:

kubectl apply -f pod.yaml

Baada ya sekunde chache, unaweza kuangalia yaliyomo kwenye ganda kwa kutumia amri ifuatayo:

kubectl describe pods node500

Mwishoni mwa pato, pata ndio nini.

Kama unavyoona, livenessProbe ilianzisha ombi la HTTP GET, kontena ikatoa hitilafu 500 (ambayo ndiyo ilipangwa kufanya), na kubelet ikaanzisha upya.

Ikiwa unashangaa jinsi programu ya NideJS ilivyopangwa, hapa kuna programu.js na Dockerfile ambazo zilitumika:

programu

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

Dockerfile

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

Ni muhimu kutambua hili: livenessProbe itaanzisha tena kontena ikiwa itashindwa. Ikiwa kuwasha upya hakurekebisha hitilafu ambayo inazuia kontena kufanya kazi, kubelet haitaweza kuchukua hatua kurekebisha tatizo.

utayariProbe

ReadinessProbe hufanya kazi sawa na livenessProbes (maombi ya GET, mawasiliano ya TCP na utekelezaji wa amri), isipokuwa kwa vitendo vya utatuzi. Chombo ambacho hitilafu imegunduliwa haijaanzishwa upya, lakini imetengwa na trafiki inayoingia. Fikiria kwamba moja ya chombo kinafanya mahesabu mengi au iko chini ya mzigo mkubwa, na kusababisha muda wa majibu kuongezeka. Katika kesi ya livenessProbe, ukaguzi wa upatikanaji wa majibu huanzishwa (kupitia kigezo cha ukaguzi cha timeoutSeconds), baada ya hapo kubelet huwasha tena kontena. Inapoanzishwa, chombo huanza kufanya kazi zinazohitaji rasilimali nyingi na huwashwa tena. Hii inaweza kuwa muhimu kwa programu zinazohitaji kasi ya majibu. Kwa mfano, gari likiwa barabarani linangojea jibu kutoka kwa seva, jibu limechelewa - na gari linapata ajali.

Hebu tuandike ufafanuzi wa redinessProbe ambao utaweka muda wa kujibu ombi la GET usiwe zaidi ya sekunde mbili, na programu itajibu ombi la GET baada ya sekunde 5. Faili ya pod.yaml inapaswa kuonekana kama hii:

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

Wacha tuweke ganda na kubectl:

kubectl apply -f pod.yaml

Wacha tusubiri sekunde chache kisha tuone jinsi ReadinessProbe ilivyofanya kazi:

kubectl describe pods nodedelayed

Mwisho wa matokeo unaweza kuona kuwa baadhi ya matukio yanafanana huyu.

Kama unavyoona, kubectl haikuanzisha tena ganda wakati muda wa kuangalia ulizidi sekunde 2. Badala yake, alighairi ombi hilo. Mawasiliano zinazoingia huelekezwa kwa maganda mengine yanayofanya kazi.

Kumbuka kwamba kwa kuwa sasa ganda limepakuliwa, njia za kubectl zinaiomba tena: majibu kwa maombi ya GET hayacheleweshwa tena.

Kwa kulinganisha, hapa chini kuna faili ya app.js iliyorekebishwa:

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

TL; DR
Kabla ya ujio wa programu za wingu, kumbukumbu zilikuwa njia kuu za ufuatiliaji na kuangalia afya ya programu. Walakini, hakukuwa na njia ya kuchukua hatua yoyote ya kurekebisha. Kumbukumbu bado ni muhimu leo; zinahitaji kukusanywa na kutumwa kwa mfumo wa kukusanya kumbukumbu kwa ajili ya kuchanganua hali za dharura na kufanya maamuzi. [Yote hii inaweza kufanyika bila maombi ya wingu kwa kutumia monit, kwa mfano, lakini kwa k8s ikawa rahisi zaidi :) - maelezo ya mhariri. ]

Leo, marekebisho yanapaswa kufanywa karibu kwa wakati halisi, kwa hivyo programu hazipaswi tena kuwa masanduku nyeusi. Hapana, zinapaswa kuonyesha vidokezo vinavyoruhusu mifumo ya ufuatiliaji kuuliza na kukusanya data muhimu kuhusu hali ya michakato ili iweze kujibu papo hapo inapohitajika. Hii inaitwa Muundo wa Muundo wa Mtihani wa Utendaji, unaofuata Kanuni ya Juu ya Uangalizi (HOP).

Kubernetes inatoa aina 2 za ukaguzi wa afya kwa chaguo-msingi: ReadinessProbe na livenessProbe. Zote mbili hutumia aina sawa za ukaguzi (maombi ya HTTP GET, mawasiliano ya TCP na utekelezaji wa amri). Wanatofautiana katika maamuzi wanayofanya katika kukabiliana na matatizo katika maganda. livenessProbe huwasha tena kontena kwa matumaini kwamba hitilafu haitatokea tena, na ReadinessProbe hutenganisha ganda na trafiki inayoingia hadi sababu ya tatizo kutatuliwa.

Muundo unaofaa wa programu unapaswa kujumuisha aina zote mbili za ukaguzi na kuhakikisha kuwa zinakusanya data ya kutosha, haswa wakati ubaguzi unatupwa. Inapaswa pia kuonyesha vidokezo muhimu vya API ambavyo vinatoa mfumo wa ufuatiliaji (Prometheus) na vipimo muhimu vya afya.

Chanzo: mapenzi.com