Pratîkên çêtirîn ên ji bo Konteynirên Kubernetes: Kontrolên Tenduristî

TL; DR

• Ji bo bidestxistina çavdêriya bilind a konteynir û mîkroservîsan, têketin û metrîkên bingehîn ne bes in.
• Ji bo başbûnek zûtir û zêdebûna berxwedêriyê, serîlêdan divê Prensîba Çavdêriya Bilind (HOP) bicîh bînin.
• Di asta serîlêdanê de, NOP hewce dike: têketinek rast, çavdêriya nêzîk, kontrolên hişmendiyê, û şopandina performansê / veguheztinê.
• Kontrolan wekî hêmanek NOR bikar bînin ReadinessProbe и livenessProbe Kubernetes.

Şablonek Kontrolkirina Tenduristî çi ye?

Dema ku hûn serîlêdanek mîsyonek krîtîk û pir berdest têne sêwirandin, pir girîng e ku meriv li ser aliyek wekî tolerasyona xeletiyê bifikire. Serlêdanek bi xeletî tête hesibandin heke ew zû ji têkçûnê xelas bibe. Serlêdanek ewr a tîpîk mîmariya mîkroxizmetê bikar tîne - ku her pêkhateyek di konteynerek cûda de tê danîn. Û ji bo ku hûn pê ewle bin ku dema ku hûn komek sêwiran dikin serîlêdana li ser k8 pir berdest e, hûn hewce ne ku hin qalibên bişopînin. Di nav wan de Şablona Kontrolkirina Tenduristiyê ye. Ew diyar dike ka serîlêdan çawa bi k8s re ragihîne ku ew saxlem e. Ev ne tenê agahdarî di derbarê ka pod dimeşe, lê di heman demê de di derbarê ka ew çawa daxwaziyan distîne û bersivê dide. Kubernetes her ku di derbarê tenduristiya pod de dizane, ew qas biryarên biaqiltir di derbarê rêvekirina trafîkê û hevsengkirina barkirinê de dide. Bi vî rengî, Prensîba Çavdêriya Bilind destûrê dide serîlêdanê ku di wextê xwe de bersivê bide daxwazan.

Prensîba Çavdêriya Bilind (HOP)

Prensîba çavdêriya bilind yek ji wan e prensîbên ji bo sêwirana sepanên konteynirkirî. Di mîmariya mîkroxizmetan de, karûbar guh nadin ka daxwaziya wan çawa tê pêvajo kirin (û rast e), lê ya girîng ev e ku ew çawa bersivên ji karûbarên wergirtinê digirin. Mînakî, ji bo rastkirina bikarhênerek, konteynerek daxwazek HTTP ji yekî din re dişîne, li benda bersivek bi rengek diyarkirî ye - ew hemî. PythonJS jî dikare daxwazê ​​bike, û Python Flask dikare bersivê bide. Konteyner mîna qutiyên reş in ku naverokên wan veşartî li ser hev in. Lêbelê, prensîba NOP-ê hewce dike ku her karûbar gelek xalên dawiya API-ê yên ku destnîşan dikin ka ew çiqas saxlem e, û her weha amadebûna wê û rewşa tolerasyona xeletiyê eşkere dike. Kubernetes van nîşanan daxwaz dike da ku li gavên paşîn ên ji bo rêkirin û hevsengkirina barkirinê bifikire.

Serlêdanek ewr a xweş sêwirandî bûyerên xwe yên sereke bi karanîna stendeyên I/O yên STDERR û STDOUT tomar dike. Dûv re karûbarek alîkar tê, mînakî pelêbeat, logstash an fluentd, ku têketin radestî pergalek çavdêriya navendî (mînakî Prometheus) û pergalek berhevkirina têketinê (komika nermalava ELK) dike. Diagrama jêrîn nîşan dide ka serîlêdanek ewr çawa li gorî Nimûneya Testa Tenduristiyê û Prensîba Çavdêriya Bilind dixebite.

Meriv çawa Nimûneya Kontrolkirina Tenduristiyê li Kubernetes bicîh tîne?

Ji derveyî qutikê, k8s bi karanîna yek ji kontrolkeran rewşa podan dişopîne (Dezgehan, ReplicaSets, DaemonSets, StatefulSets hwd., hwd.). Piştî ku fêhm kir ku pod ji ber hin sedeman ketiye, kontrolker hewl dide ku wê ji nû ve bide destpêkirin an veguhezîne nodek din. Lêbelê, podek dikare rapor bike ku ew bi rê ve ye, lê ew bixwe ne kar dike. Werin em mînakek bidin: serîlêdana we Apache wekî serverek webê bikar tîne, we hêman li ser çend podên komê saz kir. Ji ber ku pirtûkxane bi xeletî hate mîheng kirin, hemî daxwazên serîlêdanê bi koda 500 (çewtiya servera hundurîn) bersiv didin. Dema ku radestkirinê kontrol dikin, kontrolkirina rewşa podan encamek serfiraz dide, lê xerîdar cûda difikirin. Em ê vê rewşa nexwestî wiha rave bikin:

Di mînaka me de, k8s dike kontrolkirina fonksiyonê. Di vî rengî verastkirinê de, kubelet bi domdarî rewşa pêvajoyê di konteynerê de kontrol dike. Dema ku ew fêm kir ku pêvajo rawestiyaye, ew ê ji nû ve dest pê bike. Ger xeletî bi tenê ji nû ve destpêkirina serîlêdanê were çareser kirin, û bername ji bo sekinandina her xeletiyek hatî çêkirin, wê hingê hûn hewce ne ku hûn NOP û Nimûneya Testa Tenduristiyê bişopînin kontrolkirina tenduristiya pêvajoyê ye. Tenê mixabin ev e ku ne hemî xeletî bi ji nû ve destpêkirinê têne rakirin. Di vê rewşê de, k8s 2 awayên kûrtir pêşkêşî dike ku pirsgirêkên bi pod re nas bike: livenessProbe и ReadinessProbe.

LivenessProbe

Dema livenessProbe kubelet 3 celeb kontrolan pêk tîne: ne tenê diyar dike ka pod dimeşe, lê di heman demê de ew amade ye ku wergire û bi têra xwe bersivê bide daxwazan:

• Daxwazek HTTP li ser podê saz bikin. Bersiv divê kodek bersivê ya HTTP-ê di navbera 200 heta 399 de hebe. Bi vî rengî, kodên 5xx û 4xx nîşan didin ku pod pirsgirêk heye, her çend pêvajo dimeşe.
• Ji bo ceribandina podên bi karûbarên ne-HTTP (mînak, servera posta Postfix), hûn hewce ne ku pêwendiyek TCP saz bikin.
• Ji bo podek (navxweyî) fermanek kêfî bicîh bînin. Ger koda qedandina fermanê 0 be, kontrol serkeftî tê hesibandin.

Mînakek çawa ev kar dike. Di pênaseya podê ya paşîn de serîlêdanek NodeJS heye ku xeletiyek 500 davêje ser daxwazên HTTP. Ji bo ku pê ewle bibin ku konteynir dema ku xeletiyek weha werdigire ji nû ve dest pê dike, em parametreya livenessProbe bikar tînin:

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

Ev ji ti pênase podên din ne cûda ye, lê em hêmanek lê zêde dikin .spec.containers.livenessProbe. Parametre httpGet riya ku daxwaza HTTP GET tê şandin qebûl dike (di mînaka me de ev e /, lê di senaryoyên şer de dibe ku tiştek wusa hebe /api/v1/status). LivenessProbe din pîvanek qebûl dike initialDelaySeconds, ku ferman dide operasyona verastkirinê ku li benda hejmarek diyarkirî ya saniyeyan bimîne. Dereng hewce ye ji ber ku konteynir ji bo destpêkirinê dem hewce dike, û dema ku ji nû ve were destpêkirin dê ji bo demekî ne amade be.

Ji bo sepandina vê mîhengê li komekê, bikar bînin:

kubectl apply -f pod.yaml

Piştî çend hûrdeman, hûn dikarin naveroka podê bi karanîna fermana jêrîn kontrol bikin:

kubectl describe pods node500

Di dawiya encam de, bibînin ew çi ye.

Wekî ku hûn dikarin bibînin, livenessProbe daxwazek HTTP GET da destpêkirin, konteynir xeletiyek 500 çêkir (ya ku ew bername hatî bernamekirin ev e), û kubelet ew ji nû ve da destpêkirin.

Heke hûn meraq dikin ka serîlêdana NideJS çawa hate bernamekirin, li vir app.js û Dockerfile hene ku hatine bikar anîn:

app.js

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" ]

Girîng e ku vê yekê bala xwe bidinê: livenessProbe dê tenê konteynerê ji nû ve dest pê bike heke ew têk biçe. Ger ji nû ve destpêkek xeletiya ku rê li ber xebitandina konteynerê digire rast neke, kubelet dê nikaribe ji bo rastkirina pirsgirêkê tevbigere.

ReadinessProbe

ReadinessProbe bi livenessProbes (daxwazên GET, ragihandina TCP û pêkanîna fermanê) bi heman rengî dixebite, ji bilî kiryarên çareserkirinê. Konteynera ku tê de têkçûn tê tesbît kirin ji nû ve nayê destpêkirin, lê ji seyrûsefera hatinê tê veqetandin. Bifikirin ku yek ji konteyneran gelek hesaban dike an di bin barek giran de ye, dibe sedema ku demên bersivdanê zêde bibin. Di doza livenessProbe de, kontrolkirina hebûna bersivê (bi riya parametreya kontrolê ya timeoutSeconds) tê dest pê kirin, pişt re kubelet konteynerê ji nû ve dide destpêkirin. Dema ku dest pê kir, konteynir dest pê dike ku karên çavkanî-dijwar pêk bîne û ji nû ve tê destpêkirin. Ev dikare ji bo serîlêdanên ku hewceyê leza bersivê girîng be. Mînakî, otomobîlek dema ku li ser rê ye li benda bersivek serverê ye, bersiv dereng dimîne - û otomobîl dikeve qezayekê.

Ka em pênaseyek redinessProbe binivîsin ku dê dema bersivdana daxwaza GET ji du saniyeyan zêdetir neke, û serîlêdan dê piştî 5 çirkeyan bersivê bide daxwaza GET. Pelê pod.yaml divê bi vî rengî xuya bike:

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

Ka em bi kubectl re podek saz bikin:

kubectl apply -f pod.yaml

Ka em çend saniyan bisekinin û dûv re bibînin ka amadebûnaProbe çawa xebitî:

kubectl describe pods nodedelayed

Di dawiya derketinê de hûn dikarin bibînin ku hin bûyer dişibin hev ev yek.

Wekî ku hûn dibînin, kubectl dema ku dema kontrolê ji 2 çirkeyan derbas bû, pod ji nû ve dest pê nekir. Di şûna wê de, wî daxwaz betal kir. Danûstandinên hatinî ber bi pêlên din ên xebatê ve têne rêve kirin.

Bala xwe bidinê ku naha ku pod hatiye barkirin, kubectl dîsa daxwazan jê re rê dike: bersivên daxwazên GET êdî dereng nakevin.

Ji bo berhevdanê, li jêr pelê app.js-ê hatî guherandin heye:

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
Berî hatina serîlêdanên ewr, têketin navgînên bingehîn ên şopandin û kontrolkirina tenduristiya serîlêdanê bûn. Lêbelê, ti rêyek ku meriv tedbîrek rastker bike tune bû. Têketin îro hîn jî bikêr in; ji bo analîzkirina rewşên awarte û girtina biryaran pêdivî ye ku ew werin berhev kirin û bişînin pergala berhevkirina têketinê. [Hemî ev dikare bêyî serîlêdanên ewr bi karanîna monit, mînakî, were kirin, lê bi k8-an re ew pir hêsantir bû :) - nîşeya edîtor. ]

Îro, sererastkirin divê hema hema di wextê rast de bêne kirin, ji ber vê yekê serlêdan êdî ne qutiyên reş bin. Na, divê ew xalên dawîn nîşan bidin ku destûrê didin pergalên çavdêriyê ku di derbarê rewşa pêvajoyan de lêpirsîn û berhevkirina daneyên hêja berhev bikin da ku ger hewce bike ew tavilê bersivê bidin. Ji vê re tê gotin Modela Sêwirana Testa Performansê, ku Prensîba Çavdêriya Bilind (HOP) dişopîne.

Kubernetes ji hêla xwerû ve 2 celeb kontrolên tenduristiyê pêşkêşî dike: ReadinessProbe û livenessProbe. Her du jî heman cûreyên kontrolê bikar tînin (daxwazên HTTP GET, ragihandina TCP û pêkanîna fermanê). Ew di çi biryarên ku ew di bersivê de pirsgirêkên di potan de digirin cûda dibin. livenessProbe konteynerê ji nû ve dest pê dike bi hêviya ku xeletî careke din neqewime, û ReadinessProbe pod ji seyrûsefera hatinê veqetîne heya ku sedema pirsgirêkê çareser bibe.

Pêdivî ye ku sêwirana serîlêdanê ya rast her du celeb kontrolê pêk bîne û piştrast bike ku ew daneya têr berhev dikin, nemaze dema ku îstîsnayek were avêtin. Di heman demê de pêdivî ye ku ew xalên dawiya API-ê yên pêwîst ên ku pergala çavdêriyê (Prometheus) bi pîvanên tenduristiyê yên girîng peyda dikin jî nîşan bide.

Source: www.habr.com