Izindlela Ezinhle Kakhulu Zeziqukathi ze-Kubernetes: Ukuhlolwa Kwezempilo

TL; DR

• Ukuze kuzuzwe ukubonakala okuphezulu kweziqukathi nama-microservices, amalogi namamethrikhi ayisisekelo akwanele.
• Ukuze ululame ngokushesha kanye nokukhula kokuqina, izinhlelo zokusebenza kufanele zisebenzise Isimiso Sokuqaphela Okuphezulu (HOP).
• Ezingeni lohlelo lokusebenza, i-NOP idinga: ukugawulwa kwemithi okufanele, ukugadwa eduze, ukuhlolwa kokuhlanzeka kwengqondo, kanye nokulandela ukusebenza/ushintsho.
• Sebenzisa amasheke njengengxenye ye-NOR ReadinessProbe и livenessProbe Kubernetes.

Siyini Isifanekiso Sokuhlola Impilo?

Lapho uklama uhlelo lokusebenza olubaluleke kakhulu futhi olutholakala kakhulu, kubaluleke kakhulu ukucabanga ngesici esinjengokubekezelela amaphutha. Uhlelo lokusebenza lubhekwa njengolubekezelela amaphutha uma lululama ngokushesha ekwehlulekeni. Uhlelo lokusebenza lwamafu olujwayelekile lusebenzisa i-microservices architecture - lapho ingxenye ngayinye ibekwe esitsheni esihlukile. Futhi ukuze uqiniseke ukuthi uhlelo lokusebenza kuma-k8s lutholakala kakhulu uma uklama iqoqo, udinga ukulandela amaphethini athile. Phakathi kwazo kuneHealth Check Template. Ichaza ukuthi uhlelo lokusebenza luxhumana kanjani nama-k8s ukuthi lunempilo. Lokhu akulona nje ulwazi mayelana nokuthi i-pod iyasebenza, kodwa futhi mayelana nokuthi ithola futhi iphendule kanjani izicelo. Lapho u-Kubernetes ekwazi okwengeziwe ngempilo ye-pod, izinqumo ezihlakaniphile azenzayo mayelana nomzila wethrafikhi nokulinganisa komthwalo. Ngakho-ke, Umgomo Wokubonwa Okuphezulu uvumela uhlelo lokusebenza ukuthi luphendule izicelo ngesikhathi esifanele.

Isimiso Sokubona Okuphezulu (HOP)

Umgomo wokuqashelwa okuphezulu ungomunye we imigomo yokuklama izinhlelo zokusebenza ezifakwe emabhokisini. Ezakhiweni zama-microservices, izinsiza azikhathali ukuthi isicelo sazo sicutshungulwa kanjani (futhi kufanele), kodwa okubalulekile ukuthi zizithola kanjani izimpendulo kumasevisi abamukelayo. Isibonelo, ukuze uqinisekise umsebenzisi, isiqukathi esisodwa sithumela isicelo se-HTTP kwesinye, silindele impendulo ngefomethi ethile - yilokho kuphela. I-PythonJS ingaphinda icubungule isicelo, futhi i-Python Flask ingaphendula. Iziqukathi zifana namabhokisi amnyama anokuqukethwe okufihliwe komunye nomunye. Kodwa-ke, isimiso se-NOP sidinga ukuthi insizakalo ngayinye iveze amaphuzu amaningi e-API abonisa ukuthi inempilo kangakanani, kanye nokulungela kwayo kanye nesimo sokubekezelela amaphutha. U-Kubernetes ucela lezi zinkomba ukuze acabange ngezinyathelo ezilandelayo zokuqondisa nokulinganisa ukulayisha.

Uhlelo lokusebenza lwamafu oluklanywe kahle luloba imicimbi yalo eyinhloko lisebenzisa ukusakaza kwe-I/O okujwayelekile STDERR kanye ne-STDOUT. Okulandelayo kuza isevisi eyisizayo, isibonelo ibhithi yefayela, i-logstash noma i-logstash, ukuletha amalogi ohlelweni lokuqapha olumaphakathi (ngokwesibonelo i-Prometheus) kanye nohlelo lokuqoqwa kwelogi (ELK software suite). Umdwebo ongezansi ubonisa ukuthi uhlelo lokusebenza lwefu lusebenza kanjani ngokuya Ngephethini Yokuhlola Impilo kanye Nomgomo Wokuqaphela Okuphezulu.

Ungayisebenzisa kanjani i-Health Check Pattern ku-Kubernetes?

Ngaphandle kwebhokisi, ama-k8s aqapha isimo se-pods esebenzisa esinye sezilawuli (Ukuhanjiswa, I-ReplicaSets, I-DaemonSets, StatefulSets njll., njll.). Ngemva kokuthola ukuthi i-pod iwe ngesizathu esithile, isilawuli sizama ukuyiqalisa kabusha noma ukuyihambisa kwenye indawo. Kodwa-ke, i-pod ingase ibike ukuthi iyasebenza, kodwa yona ngokwayo ayisebenzi. Ake sinikeze isibonelo: uhlelo lwakho lokusebenza lisebenzisa i-Apache njengeseva yewebhu, ufake ingxenye kumaphodi amaningana eqoqo. Njengoba umtapo wezincwadi wawulungiselelwe ngokungalungile, zonke izicelo zohlelo lokusebenza ziphendula ngekhodi 500 (iphutha leseva yangaphakathi). Lapho uhlola ukulethwa, ukuhlola isimo sama-pods kunikeza umphumela ophumelelayo, kodwa amakhasimende acabanga ngendlela ehlukile. Lesi simo esingathandeki sizosichaza kanje:

Esibonelweni sethu, i-k8s iyakwenza ukuhlola ukusebenza. Kulolu hlobo lokuqinisekisa, i-kubelet ihlola ngokuqhubekayo isimo senqubo esitsheni. Uma eseqonda ukuthi uhlelo lumile, uzoluqala kabusha. Uma iphutha lingaxazululwa ngokumane uqalise kabusha uhlelo lokusebenza, futhi uhlelo ludizayinelwe ukuvala noma yiliphi iphutha, khona-ke ukuhlola impilo yenqubo yikho konke okudingayo ukuze ulandele i-NOP kanye Nephethini Yokuhlola Impilo. Okudabukisayo nje ukuthi akuwona wonke amaphutha aqedwa ngokuqala kabusha. Kulokhu, i-k8s inikeza izindlela ezi-2 ezijulile zokubona izinkinga nge-pod: livenessProbe и ReadinessProbe.

I-LivenessProbe

Ngesikhathi livenessProbe I-kubelet yenza izinhlobo ezi-3 zokuhlola: ayigcini nje ngokunquma ukuthi i-pod iyasebenza, kodwa futhi ukuthi isilungele yini ukwamukela nokuphendula ngokufanele izicelo:

• Setha isicelo se-HTTP ku-pod. Impendulo kufanele iqukathe ikhodi yokuphendula ye-HTTP ebangeni elisuka ku-200 ukuya ku-399. Ngakho, amakhodi amakhodi 5xx kanye ne-4xx abonisa ukuthi i-pod inezinkinga, nakuba inqubo isebenza.
• Ukuze uhlole ama-pod ngamasevisi angewona awe-HTTP (isibonelo, iseva yeposi ye-Postfix), udinga ukusungula uxhumano lwe-TCP.
• Yenza umyalo ongekho emthethweni we-pod (ngaphakathi). Isheke libhekwa njengeliyimpumelelo uma ikhodi yokuqedela umyalo ingu-0.

Isibonelo sokuthi lokhu kusebenza kanjani. Incazelo elandelayo ye-pod iqukethe uhlelo lokusebenza lwe-NodeJS oluphonsa iphutha elingu-500 ezicelweni ze-HTTP. Ukuqinisekisa ukuthi isiqukathi siqalwa kabusha lapho sithola iphutha elinjalo, sisebenzisa ipharamitha ye-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

Lokhu akuhlukile kunoma iyiphi enye incazelo ye-pod, kodwa sengeza into .spec.containers.livenessProbe. Ipharamitha httpGet yamukela indlela esithunyelwa kuyo isicelo se-HTTP GET (esibonelweni sethu yilokhu /, kodwa ezimweni zokulwa kungase kube khona into efana nayo /api/v1/status). Enye i-livenessProbe yamukela ipharamitha initialDelaySeconds, eyalela umsebenzi wokuqinisekisa ukuthi ulinde inombolo ethile yamasekhondi. Ukubambezeleka kuyadingeka ngoba isiqukathi sidinga isikhathi ukuze siqale, futhi lapho siqaliswa kabusha ngeke sitholakale isikhathi esithile.

Ukuze usebenzise lesi silungiselelo kuqoqo, sebenzisa:

kubectl apply -f pod.yaml

Ngemuva kwemizuzwana embalwa, ungabheka okuqukethwe kwe-pod usebenzisa umyalo olandelayo:

kubectl describe pods node500

Ekupheleni kokukhiphayo, thola yilokho.

Njengoba ubona, i-livenessProbe iqalise isicelo se-HTTP GET, isiqukathi sikhiqize iphutha elingu-500 (okuyinto eyayihlelelwe ukuthi siyenze), futhi i-kubelet yaqala kabusha.

Uma uzibuza ukuthi uhlelo lwe-NideJS lwahlelwa kanjani, nansi i-app.js ne-Dockerfile ezasetshenziswa:

uhlelo lokusebenza

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')
})

I-Dockerfile

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

Kubalulekile ukuqaphela lokhu: i-livenessProbe izoqala kabusha kuphela isiqukathi uma sehluleka. Uma ukuqalisa kabusha kungalungisi iphutha elivimbela isiqukathi ukuthi sisebenze, i-kubelet ngeke ikwazi ukuthatha isinyathelo sokulungisa inkinga.

ReadinessProbe

ReadinessProbe isebenza ngendlela efanayo ne-livenessProbes (izicelo ze-GET, ukuxhumana kwe-TCP nokusebenzisa umyalo), ngaphandle kwezenzo zokuxazulula inkinga. Isiqukathi okutholwe kuso ukwehluleka asiqalwa kabusha, kodwa sihlukanisiwe nethrafikhi engenayo. Cabanga ukuthi esinye seziqukathi senza izibalo eziningi noma sithwele kanzima, okwenza izikhathi zokuphendula zikhule. Esimeni se-livenessProbe, ukuhlola ukutholakala kwempendulo kuyaqaliswa (ngepharamitha yokuhlola i-timeoutSeconds), ngemva kwalokho i-kubelet iqala kabusha isiqukathi. Uma isiqaliwe, isiqukathi siqala ukwenza imisebenzi edinga izinsiza futhi siqalwa kabusha futhi. Lokhu kungabaluleka ezinhlelweni zokusebenza ezidinga isivinini sokuphendula. Isibonelo, imoto ngenkathi isendleleni ilinde impendulo evela kuseva, impendulo ibambezelekile - futhi imoto ingena engozini.

Masibhale incazelo ye-redinessProbe ezosetha isikhathi sokuphendula sesicelo se-GET singabi ngaphezu kwamasekhondi amabili, futhi uhlelo lokusebenza luzophendula isicelo se-GET ngemva kwamasekhondi angu-5. Ifayela le-pod.yaml kufanele libukeke kanje:

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

Masisebenzise i-pod nge-kubectl:

kubectl apply -f pod.yaml

Ake silinde imizuzwana embalwa bese sibona ukuthi i-readinessProbe isebenze kanjani:

kubectl describe pods nodedelayed

Ekupheleni kokukhiphayo ungabona ukuthi eminye imicimbi iyafana Lena.

Njengoba ubona, i-kubectl ayizange iqale kabusha i-pod lapho isikhathi sokuhlola sidlula imizuzwana emi-2. Kunalokho, wasichitha isicelo. Ukuxhumana okungenayo kuqondiswa kabusha kwamanye ama-pods asebenzayo.

Qaphela ukuthi njengoba manje i-pod isilayishiwe, imizila ye-kubectl icela kuyo futhi: izimpendulo zezicelo ze-GET azisabambezeleki.

Ukuze uqhathanise, ngezansi ifayela eliguquliwe le-app.js:

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
Ngaphambi kokufika kwezinhlelo zokusebenza zamafu, amalogi ayeyizindlela eziyinhloko zokuqapha nokuhlola impilo yohlelo lokusebenza. Nokho, yayingekho indlela yokuthatha isinyathelo sokulungisa. Amalogi asewusizo nanamuhla; adinga ukuqoqwa futhi athunyelwe ohlelweni lokuqoqwa kwamalogi ukuze kuhlaziywe izimo eziphuthumayo nokwenza izinqumo. [Konke lokhu kungenziwa ngaphandle kwezinhlelo zokusebenza zefu usebenzisa i-monit, isibonelo, kodwa nge-k8s kwaba lula kakhulu :) - inothi lomhleli. ]

Namuhla, ukulungiswa kufanele kwenziwe cishe ngesikhathi sangempela, ngakho-ke izinhlelo zokusebenza akusadingeki zibe amabhokisi amnyama. Cha, kufanele babonise izindawo zokugcina ezivumela amasistimu okuqapha ukuthi abuze futhi aqoqe idatha ebalulekile mayelana nesimo sezinqubo ukuze akwazi ukuphendula ngokushesha uma kunesidingo. Lokhu kubizwa ngokuthi Iphethini Yomklamo Wokuhlola Ukusebenza, elandela Umgomo Wokuqaphela Okuphezulu (HOP).

I-Kubernetes inikeza izinhlobo ezi-2 zokuhlolwa kwezempilo ngokuzenzakalela: ReadinessProbe kanye ne-livenessProbe. Kokubili kusebenzisa izinhlobo ezifanayo zokuhlola (izicelo ze-HTTP GET, ukuxhumana kwe-TCP nokwenza umyalo). Zihlukene ngokuthi yiziphi izinqumo abazenzayo ekuphenduleni izinkinga ezikhona. I-livenessProbe iqala kabusha isiqukathi ngethemba lokuthi iphutha ngeke liphinde lenzeke, futhi i-readinessProbe ihlukanisa i-pod kuthrafikhi engenayo kuze kube yilapho imbangela yenkinga isixazululiwe.

Idizayini yohlelo lokusebenza efanele kufanele ifake zombili izinhlobo zokuhlola futhi iqinisekise ukuthi iqoqa idatha eyanele, ikakhulukazi uma okuhlukile kwenziwa. Kufanele futhi ibonise izindawo zokugcina ze-API ezidingekayo ezinikeza isistimu yokuqapha (i-Prometheus) ngamamethrikhi ezempilo abalulekile.

Source: www.habr.com