Cleachtais is Fearr le haghaidh Coimeádáin Kubernetes: Seiceálacha Sláinte

TL; DR

• Chun inbhraiteacht ard coimeádáin agus microservices a bhaint amach, ní leor logaí agus méadracht phríomhúil.
• Ar mhaithe le téarnamh níos tapúla agus le hathléimneacht mhéadaithe, ba cheart d’iarratais an Ardphrionsabal Inbhraite (HOP) a chur i bhfeidhm.
• Ag leibhéal an fheidhmchláir, éilíonn NOP: logáil cheart, dlúthfhaireachán, seiceálacha sláintíochta, agus rianú feidhmíochta/aistrithe.
• Úsáid seiceálacha mar eilimint de NOR ullmhachtProbe и slite beatha Cubernetes.

Cad is Teimpléad Seiceála Sláinte ann?

Agus feidhmchlár atá ríthábhachtach ó thaobh misin á dhearadh agus atá ar fáil go mór, tá sé an-tábhachtach smaoineamh ar ghné den sórt sin mar lamháltas locht. Meastar go bhfuil iarratas fulangach ar locht má thagann sé ar ais go tapa ó chliseadh. Úsáideann feidhmchlár scamall tipiciúil ailtireacht microservices - áit a gcuirtear gach comhpháirt i gcoimeádán ar leith. Agus d'fhonn a chinntiú go bhfuil an t-iarratas ar k8s ar fáil go mór agus tú ag dearadh braisle, ní mór duit patrúin áirithe a leanúint. Ina measc tá an Teimpléad Seiceála Sláinte. Sainmhíníonn sé conas a chuireann an feidhmchlár in iúl do k8s go bhfuil sé sláintiúil. Ní hamháin faisnéis é seo faoi cé acu an bhfuil an pod ag rith, ach freisin faoin gcaoi a bhfaigheann sé agus a bhfreagraíonn sé iarratais. Dá mhéad atá ar eolas ag Kubernetes faoi shláinte an phota, is ea is cliste a dhéanann sé cinntí maidir le ródú tráchta agus cothromaíocht ualaigh. Mar sin, ceadaíonn an Príomhphrionsabal Ard-Infheictheachta don iarratas freagra a thabhairt ar iarratais ar bhealach tráthúil.

Ardphrionsabal Inbhraite (HOP)

Tá prionsabal na hard-inbhraite ar cheann de prionsabail chun feidhmchláir coimeádaithe a dhearadh. I ailtireacht na micrisheirbhísí, is cuma le seirbhísí conas a phróiseáiltear a n-iarratas (agus mar is ceart), ach is é an rud is tábhachtaí ná conas a fhaigheann siad freagraí ó na seirbhísí glactha. Mar shampla, chun úsáideoir a fhíordheimhniú, seolann coimeádán amháin iarratas HTTP chuig ceann eile, ag súil le freagra i bhformáid áirithe - sin é go léir. Is féidir le PythonJS an t-iarratas a phróiseáil freisin, agus is féidir le Python Flask freagra a thabhairt. Tá coimeádáin cosúil le boscaí dubha le hábhar i bhfolach dá chéile. Éilíonn prionsabal NOP, áfach, go nochtfadh gach seirbhís roinnt críochphointí API a léiríonn cé chomh sláintiúil agus atá sé, chomh maith lena stádas ullmhachta agus lamháltais lochtanna. Iarrann Kubernetes na táscairí seo chun smaoineamh ar na chéad chéimeanna eile maidir le ródú agus cothromaíocht ualaigh.

Déanann feidhmchlár néal dea-dheartha a phríomhimeachtaí a logáil ag baint úsáide as na sruthanna caighdeánacha I/O STDERR agus STDOUT. Next thagann seirbhís chúnta, mar shampla filebeat, logstash nó fluentd, logs a sheachadadh chuig córas monatóireachta láraithe (mar shampla Prometheus) agus córas bailithe loga (sraith bogearraí ELK). Taispeánann an léaráid thíos conas a oibríonn feidhmchlár scamall de réir an Phatrún Tástála Sláinte agus an Phrionsabail Ard-Inbhraite.

Conas an Patrún Seiceála Sláinte a chur i bhfeidhm i Kubernetes?

Lasmuigh den bhosca, déanann k8s monatóireacht ar stádas na pods ag baint úsáide as ceann de na rialaitheoirí (Imscaradh, MacasamhailSets, DaemonSets, Sraitheanna Stáit srl., etc.). Tar éis a fháil amach go bhfuil an pod tar éis titim ar chúis éigin, déanann an rialtóir iarracht é a atosú nó é a aistriú chuig nód eile. Mar sin féin, féadfaidh pod a thuairisciú go bhfuil sé ar bun agus ag feidhmiú, ach nach bhfuil sé féin ag feidhmiú. Tabhair sampla: úsáideann d'iarratas Apache mar fhreastalaí gréasáin, shuiteáil tú an chomhpháirt ar roinnt pods den bhraisle. Ós rud é go raibh an leabharlann cumraithe go mícheart, freagraíonn gach iarratas ar an bhfeidhmchlár le cód 500 (earráid fhreastalaí inmheánach). Agus an seachadadh á sheiceáil, tugann seiceáil stádas na pods toradh rathúil, ach smaoiníonn custaiméirí ar bhealach difriúil. Déanfaimid cur síos ar an staid neamh-inmhianaithe seo mar seo a leanas:

In ár sampla, déanann k8s seiceáil feidhmiúlacht. Sa chineál seo fíoraithe, seiceann an kubelet go leanúnach staid an phróisis sa choimeádán. Nuair a thuigeann sé go bhfuil an próiseas stoptha, atosóidh sé é. Más féidir an earráid a réiteach ach an t-iarratas a atosú, agus go bhfuil an clár deartha chun aon earráid a dhúnadh, ansin is é seiceáil sláinte próisis a theastaíonn uait chun an NOP agus an Patrún Tástála Sláinte a leanúint. Is é an t-aon trua nach gcuirtear deireadh le gach earráid trí atosú. Sa chás seo, cuireann k8s 2 bhealach níos doimhne ar fáil chun fadhbanna leis an pod a aithint: slite beatha и ullmhachtProbe.

Probe Beo

I rith na slite beatha Déanann kubelet 3 chineál seiceálacha: ní hamháin go gcinnfidh sé an bhfuil an pod ag rith, ach freisin an bhfuil sé réidh le hiarratais a fháil agus freagra leordhóthanach a thabhairt orthu:

• Socraigh iarratas HTTP chuig an pod. Ní mór cód freagartha HTTP a bheith sa fhreagra sa raon ó 200 go 399. Mar sin, comharthaíonn cóid 5xx agus 4xx go bhfuil fadhbanna ag an pod, cé go bhfuil an próiseas ar siúl.
• Chun pods a thástáil le seirbhísí neamh-HTTP (mar shampla, an freastalaí ríomhphoist Postfix), ní mór duit nasc TCP a bhunú.
• Déan ordú treallach le haghaidh pod (go hinmheánach). Meastar go n-éiríonn leis an tseiceáil más é 0 an cód críochnaithe ordaithe.

Sampla de conas a oibríonn sé seo. Sa chéad sainmhíniú pod eile tá feidhmchlár NodeJS a chaitheann earráid 500 ar iarratais HTTP Chun a chinntiú go ndéantar an coimeádán a atosú nuair a fhaightear earráid den sórt sin, úsáidimid an paraiméadar 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

Níl sé seo difriúil ó aon sainmhíniú pod eile, ach táimid ag cur réad leis .spec.containers.livenessProbe... Paraiméadar httpGet glacann sé leis an cosán a seoltar an t-iarratas HTTP GET (inár sampla tá sé seo /, ach i gcásanna comhraic d'fhéadfadh go mbeadh rud éigin cosúil le /api/v1/status). Glacann livenessProbe eile le paraiméadar initialDelaySeconds, a thugann treoir don oibríocht fíoraithe fanacht ar líon sonraithe soicind. Tá an mhoill ag teastáil mar go dteastaíonn am ón gcoimeádán le tosú, agus nuair a atosófar é ní bheidh sé ar fáil ar feadh tamaill.

Chun an socrú seo a chur i bhfeidhm ar bhraisle, úsáid:

kubectl apply -f pod.yaml

Tar éis cúpla soicind, is féidir leat inneachar an phota a sheiceáil leis an ordú seo a leanas:

kubectl describe pods node500

Ag deireadh an aschuir, faigh sin an méid.

Mar a fheiceann tú, chuir livenessProbe tús le hiarratas HTTP GET, ghin an coimeádán earráid 500 (is é sin an méid a cláraíodh é a dhéanamh), agus d'atosaigh an kubelet é.

Má tá tú ag smaoineamh ar conas a ríomhchláraíodh an feidhmchlár NideJS, seo é an app.js agus Dockerfile a úsáideadh:

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

Tá sé tábhachtach é seo a thabhairt faoi deara: ní atosóidh livenessProbe an coimeádán ach amháin má theipeann air. Mura gceartaíonn atosú an earráid a chuireann cosc ​​ar an gcoimeádán a rith, ní bheidh an kubelet in ann beart a dhéanamh chun an fhadhb a cheartú.

ullmhachtProbe

Oibríonn readynessProbe mar an gcéanna le livenessProbes (iarratais GET, cumarsáid TCP agus forghníomhú orduithe), ach amháin i gcás gníomhartha fabhtcheartaithe. Ní dhéantar an coimeádán ina n-aimsítear an teip a atosú, ach tá sé scoite amach ón trácht ag teacht isteach. Samhlaigh go bhfuil go leor ríomh á dhéanamh ag ceann de na coimeádáin nó go bhfuil sé faoi ualach trom, rud a fhágann go dtiocfaidh méadú ar amanna freagartha. I gcás livenessProbe, spreagtar an tseiceáil infhaighteachta freagartha (tríd an bparaiméadar seiceála timeoutSeconds), agus atosóidh an kubelet an coimeádán ina dhiaidh sin. Nuair a chuirtear tús leis, tosaíonn an coimeádán ag déanamh tascanna atá dian ar acmhainní agus déantar é a atosú arís. D’fhéadfadh sé seo a bheith ríthábhachtach d’fheidhmchláir a dteastaíonn luas freagartha uathu. Mar shampla, tá carr agus é ar an mbóthar ag fanacht le freagra ón bhfreastalaí, cuirtear moill ar an bhfreagra - agus bíonn timpiste ag an gcarr.

Scríobhfaimid sainmhíniú redinessProbe a shocróidh am freagartha an iarratais GET níos faide ná dhá shoicind, agus freagróidh an t-iarratas ar iarratas GET tar éis 5 soicind. Ba cheart go mbeadh cuma mar seo ar an gcomhad pod.yaml:

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

Déanaimis pod le kubectl a imscaradh:

kubectl apply -f pod.yaml

Fanfaimid cúpla soicind agus ansin féachaint conas a d'oibrigh an ullmhachtProbe:

kubectl describe pods nodedelayed

Ag deireadh an aschuir is féidir leat a fheiceáil go bhfuil cuid de na himeachtaí cosúil an ceann seo.

Mar a fheiceann tú, níor atosaigh kubectl an pod nuair a sháraigh an t-am seiceála 2 soicind. Ina áit sin, chuir sé an t-iarratas ar ceal. Déantar cumarsáidí isteach a atreorú chuig pods oibre eile.

Tabhair faoi deara anois go bhfuil an pod díluchtaithe, go n-iarrann bealaí kubectl chuige arís: ní chuirtear moill ar fhreagraí ar iarratais GET a thuilleadh.

Chun comparáid a dhéanamh, seo thíos an comhad app.js modhnaithe:

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
Roimh theacht na n-iarratas scamall, ba iad logaí an príomh-mhodh chun monatóireacht agus seiceáil a dhéanamh ar shláinte feidhmchlár. Mar sin féin, ní raibh aon bhealach chun aon ghníomh ceartaitheach a dhéanamh. Tá logaí fós úsáideach sa lá atá inniu ann; ní mór iad a bhailiú agus a chur chuig córas bailiúcháin logaí chun cásanna éigeandála a anailísiú agus chun cinntí a dhéanamh. [D’fhéadfaí é seo go léir a dhéanamh gan feidhmchláir scamall ag baint úsáide as monit, mar shampla, ach le k8s d’éirigh sé i bhfad níos éasca :) – nóta an eagarthóra. ]

Sa lá atá inniu ann, ní mór ceartúcháin a dhéanamh beagnach i bhfíor-am, mar sin ní gá go mbeadh iarratais ina mboscaí dubha a thuilleadh. Ní féidir, ba cheart dóibh críochphointí a thaispeáint a ligeann do chórais monatóireachta sonraí luachmhara a fhiosrú agus a bhailiú faoi staid na bpróiseas ionas gur féidir leo freagairt láithreach más gá. Tugtar an Patrún Dearaidh Tástála Feidhmíochta air seo, a leanann an Prionsabal Ard-Inbhraite (HOP).

Tairgeann Kubernetes 2 chineál seiceála sláinte de réir réamhshocraithe: ullmhachtProbe agus livenessProbe. Úsáideann an dá cheann na cineálacha céanna seiceálacha (iarratais HTTP GET, cumarsáid TCP agus forghníomhú orduithe). Bíonn difríocht idir na cinntí a dhéanann siad mar fhreagra ar fhadhbanna sna pods. Atosaíonn livenessProbe an coimeádán le súil nach dtarlóidh an earráid arís, agus leithlisíonn ReadinessProbe an pod ón trácht ag teacht isteach go dtí go réitítear cúis na faidhbe.

Ba cheart go n-áireodh dearadh cuí iarratais an dá chineál seiceála agus a chinntiú go mbailíonn siad go leor sonraí, go háirithe nuair a chaitear eisceacht. Ba cheart go léireodh sé freisin na críochphointí API riachtanacha a sholáthraíonn méadracht thábhachtach sláinte don chóras monatóireachta (Prometheus).

Foinse: will.com