Arferion Gorau ar gyfer Cynhwyswyr Kubernetes: Gwiriadau Iechyd

TL; DR

• Er mwyn sicrhau arsylwi uchel ar gynwysyddion a microwasanaethau, nid yw logiau a metrigau cynradd yn ddigon.
• Ar gyfer adferiad cyflymach a mwy o wytnwch, dylai ceisiadau gymhwyso'r Egwyddor Arsylwi Uchel (HOP).
• Ar lefel y cais, mae NOP yn gofyn am: logio cywir, monitro agos, gwiriadau pwyll, ac olrhain perfformiad / trawsnewid.
• Defnyddiwch sieciau fel elfen o NOR parodrwyddProbe и bywioliaethProbe Kubernetes.

Beth yw Templed Gwiriad Iechyd?

Wrth ddylunio cymhwysiad sy'n hanfodol i genhadaeth ac sydd ar gael yn fawr, mae'n bwysig iawn meddwl am agwedd o'r fath fel goddefgarwch bai. Ystyrir bod cais yn oddefgar o fai os yw'n gwella'n gyflym o fethiant. Mae cymhwysiad cwmwl nodweddiadol yn defnyddio pensaernïaeth microservices - lle mae pob cydran yn cael ei rhoi mewn cynhwysydd ar wahân. Ac er mwyn sicrhau bod y cais ar k8s ar gael yn fawr pan fyddwch chi'n dylunio clwstwr, mae angen i chi ddilyn rhai patrymau. Yn eu plith mae'r Templed Gwiriad Iechyd. Mae'n diffinio sut mae'r cymhwysiad yn cyfleu i k8s ei fod yn iach. Mae hyn nid yn unig yn wybodaeth ynghylch a yw'r pod yn rhedeg, ond hefyd am sut mae'n derbyn ac yn ymateb i geisiadau. Po fwyaf y mae Kubernetes yn ei wybod am iechyd y pod, y penderfyniadau doethach y mae'n eu gwneud ynghylch llwybro traffig a chydbwyso llwythi. Felly, mae'r Egwyddor Arsylwi Uchel yn caniatáu i'r cais ymateb i geisiadau mewn modd amserol.

Egwyddor Arsylwi Uchel (HOP)

Mae'r egwyddor o arsylwi uchel yn un o egwyddorion ar gyfer dylunio cymwysiadau cynhwysydd. Mewn pensaernïaeth microwasanaethau, nid oes ots gan wasanaethau sut mae eu cais yn cael ei brosesu (ac yn gywir felly), ond yr hyn sy'n bwysig yw sut y maent yn derbyn ymatebion gan y gwasanaethau sy'n derbyn. Er enghraifft, i ddilysu defnyddiwr, mae un cynhwysydd yn anfon cais HTTP i un arall, gan ddisgwyl ymateb mewn fformat penodol - dyna i gyd. Gall PythonJS hefyd brosesu'r cais, a gall Python Flask ymateb. Mae cynwysyddion fel blychau du gyda chynnwys cudd i'w gilydd. Fodd bynnag, mae egwyddor NOP yn ei gwneud yn ofynnol i bob gwasanaeth ddatgelu sawl pwynt terfyn API sy'n nodi pa mor iach ydyw, yn ogystal â'i barodrwydd a'i statws goddefgarwch diffygion. Mae Kubernetes yn gofyn am y dangosyddion hyn er mwyn meddwl trwy'r camau nesaf ar gyfer llwybro a chydbwyso llwythi.

Mae cymhwysiad cwmwl wedi'i ddylunio'n dda yn cofnodi ei brif ddigwyddiadau gan ddefnyddio'r ffrydiau I / O safonol STDERR a STDOUT. Nesaf daw gwasanaeth ategol, er enghraifft filebeat, logstash neu fluentd, danfon logiau i system fonitro ganolog (er enghraifft Prometheus) a system casglu boncyffion (cyfres meddalwedd ELK). Mae'r diagram isod yn dangos sut mae cymhwysiad cwmwl yn gweithio yn unol â'r Patrwm Prawf Iechyd a'r Egwyddor Arsylwi Uchel.

Sut i gymhwyso'r Patrwm Gwiriad Iechyd yn Kubernetes?

Allan o'r bocs, mae k8s yn monitro statws y codennau gan ddefnyddio un o'r rheolyddion (Defnyddiau, ReplicaSets, DaemonSets, Setiau Gwladol etc., etc.). Ar ôl darganfod bod y pod wedi disgyn am ryw reswm, mae'r rheolydd yn ceisio ei ailgychwyn neu ei symud i nod arall. Fodd bynnag, efallai y bydd pod yn adrodd ei fod ar waith, ond nid yw ei hun yn gweithio. Gadewch i ni roi enghraifft: mae eich cais yn defnyddio Apache fel gweinydd gwe, fe wnaethoch chi osod y gydran ar sawl cod o'r clwstwr. Gan fod y llyfrgell wedi'i ffurfweddu'n anghywir, mae pob cais i'r rhaglen yn ymateb gyda chod 500 (gwall gweinydd mewnol). Wrth wirio dosbarthiad, mae gwirio statws codennau yn rhoi canlyniad llwyddiannus, ond mae cwsmeriaid yn meddwl yn wahanol. Byddwn yn disgrifio'r sefyllfa annymunol hon fel a ganlyn:

Yn ein hesiampl, mae k8s yn gwneud hynny gwirio ymarferoldeb. Yn y math hwn o ddilysu, mae'r kubelet yn gwirio cyflwr y broses yn y cynhwysydd yn barhaus. Unwaith y bydd yn deall bod y broses wedi dod i ben, bydd yn ei ailgychwyn. Os gellir datrys y gwall trwy ailgychwyn y cais yn unig, a bod y rhaglen wedi'i chynllunio i gau unrhyw wall, yna gwiriad iechyd proses yw'r cyfan sydd ei angen arnoch i ddilyn yr NOP a'r Patrwm Prawf Iechyd. Yr unig drueni yw nad yw pob gwall yn cael ei ddileu trwy ailgychwyn. Yn yr achos hwn, mae k8s yn cynnig 2 ffordd ddyfnach o nodi problemau gyda'r pod: bywioliaethProbe и parodrwyddProbe.

LivenessProbe

Yn ystod bywioliaethProbe Mae kubelet yn cyflawni 3 math o wiriad: nid yn unig yn pennu a yw'r pod yn rhedeg, ond hefyd a yw'n barod i dderbyn ac ymateb yn ddigonol i geisiadau:

• Sefydlu cais HTTP i'r pod. Rhaid i'r ymateb gynnwys cod ymateb HTTP yn yr ystod o 200 i 399. Felly, mae codau 5xx a 4xx yn nodi bod y pod yn cael problemau, er bod y broses yn rhedeg.
• I brofi codennau gyda gwasanaethau nad ydynt yn HTTP (er enghraifft, gweinydd post Postfix), mae angen i chi sefydlu cysylltiad TCP.
• Gweithredu gorchymyn mympwyol ar gyfer pod (yn fewnol). Ystyrir bod y gwiriad yn llwyddiannus os yw'r cod cwblhau gorchymyn yn 0.

Enghraifft o sut mae hyn yn gweithio. Mae'r diffiniad pod nesaf yn cynnwys cymhwysiad NodeJS sy'n taflu gwall 500 ar geisiadau HTTP. I wneud yn siŵr bod y cynhwysydd yn cael ei ailgychwyn wrth dderbyn gwall o'r fath, rydym yn defnyddio'r paramedr 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

Nid yw hyn yn wahanol i unrhyw ddiffiniad pod arall, ond rydym yn ychwanegu gwrthrych .spec.containers.livenessProbe. Paramedr httpGet yn derbyn y llwybr yr anfonir y cais HTTP GET iddo (yn ein hesiampl dyma /, ond mewn senarios ymladd efallai y bydd rhywbeth tebyg /api/v1/status). Mae livenessProbe arall yn derbyn paramedr initialDelaySeconds, sy'n cyfarwyddo'r gweithrediad dilysu i aros nifer penodol o eiliadau. Mae angen yr oedi oherwydd bod angen amser ar y cynhwysydd i ddechrau, a phan fydd wedi'i ailgychwyn ni fydd ar gael am beth amser.

I gymhwyso'r gosodiad hwn i glwstwr, defnyddiwch:

kubectl apply -f pod.yaml

Ar ôl ychydig eiliadau, gallwch wirio cynnwys y pod gan ddefnyddio'r gorchymyn canlynol:

kubectl describe pods node500

Ar ddiwedd yr allbwn, darganfyddwch dyna beth.

Fel y gallwch weld, cychwynnodd livenessProbe gais HTTP GET, cynhyrchodd y cynhwysydd wall 500 (sef yr hyn y cafodd ei raglennu i'w wneud), ac ailddechreuodd y kubelet ef.

Os ydych chi'n pendroni sut cafodd y cymhwysiad NideJS ei raglennu, dyma'r app.js a Dockerfile a ddefnyddiwyd:

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

Mae'n bwysig nodi hyn: dim ond os bydd yn methu y bydd livenessProbe yn ailgychwyn y cynhwysydd. Os na fydd ailgychwyn yn cywiro'r gwall sy'n atal y cynhwysydd rhag rhedeg, ni fydd y kubelet yn gallu cymryd camau i gywiro'r broblem.

parodrwyddProbe

Mae readyinessProbe yn gweithio'n debyg i livenessProbes (ceisiadau GET, cyfathrebu TCP a gweithredu gorchmynion), ac eithrio gweithredoedd datrys problemau. Nid yw'r cynhwysydd y canfyddir y methiant ynddo yn cael ei ailgychwyn, ond mae wedi'i ynysu rhag traffig sy'n dod i mewn. Dychmygwch fod un o'r cynwysyddion yn gwneud llawer o gyfrifiadau neu o dan lwyth trwm, gan achosi i amseroedd ymateb gynyddu. Yn achos livenessProbe, mae'r gwiriad argaeledd ymateb yn cael ei sbarduno (trwy'r paramedr gwirio timeoutSeconds), ac ar ôl hynny mae'r kubelet yn ailgychwyn y cynhwysydd. Pan gaiff ei ddechrau, mae'r cynhwysydd yn dechrau cyflawni tasgau sy'n defnyddio llawer o adnoddau ac yn cael ei ailgychwyn eto. Gall hyn fod yn hollbwysig ar gyfer ceisiadau sydd angen cyflymder ymateb. Er enghraifft, mae car tra ar y ffordd yn aros am ymateb gan y gweinydd, mae'r ymateb yn cael ei oedi - ac mae'r car yn mynd i ddamwain.

Gadewch i ni ysgrifennu diffiniad redinessProbe a fydd yn gosod amser ymateb cais GET i ddim mwy na dwy eiliad, a bydd y cais yn ymateb i'r cais GET ar ôl 5 eiliad. Dylai'r ffeil pod.yaml edrych fel hyn:

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

Gadewch i ni ddefnyddio pod gyda kubectl:

kubectl apply -f pod.yaml

Gadewch i ni aros ychydig eiliadau ac yna gweld sut y gweithiodd y ParodrwyddProbe:

kubectl describe pods nodedelayed

Ar ddiwedd yr allbwn gallwch weld bod rhai o'r digwyddiadau yn debyg yr un yma.

Fel y gwelwch, ni wnaeth kubectl ailgychwyn y pod pan oedd yr amser gwirio yn fwy na 2 eiliad. Yn lle hynny, fe ganslodd y cais. Mae cyfathrebiadau sy'n dod i mewn yn cael eu hailgyfeirio i godennau gweithio eraill.

Sylwch, nawr bod y pod wedi'i ddadlwytho, mae llwybrau kubectl yn gofyn amdano eto: nid yw ymatebion i geisiadau GET bellach yn cael eu gohirio.

Er mwyn cymharu, isod mae'r ffeil app.js wedi'i haddasu:

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
Cyn dyfodiad cymwysiadau cwmwl, logiau oedd y prif ddull o fonitro a gwirio iechyd cymwysiadau. Fodd bynnag, nid oedd modd cymryd unrhyw gamau unioni. Mae logiau’n dal i fod yn ddefnyddiol heddiw; mae angen eu casglu a’u hanfon i system casglu boncyffion ar gyfer dadansoddi sefyllfaoedd brys a gwneud penderfyniadau. [Gellid gwneud hyn i gyd heb gymwysiadau cwmwl gan ddefnyddio monit, er enghraifft, ond gyda k8s daeth yn llawer haws :) - nodyn golygydd. ]

Heddiw, mae'n rhaid gwneud cywiriadau bron mewn amser real, felly nid oes rhaid i geisiadau fod yn flychau du mwyach. Na, dylent ddangos diweddbwyntiau sy'n caniatáu i systemau monitro ymholi a chasglu data gwerthfawr am gyflwr prosesau fel y gallant ymateb yn syth os oes angen. Gelwir hyn yn Patrwm Dylunio Prawf Perfformiad, sy'n dilyn yr Egwyddor Arsylwi Uchel (HOP).

Mae Kubernetes yn cynnig 2 fath o wiriad iechyd yn ddiofyn: parodrwyddProbe a livenessProbe. Mae'r ddau yn defnyddio'r un mathau o wiriadau (ceisiadau HTTP GET, cyfathrebu TCP a gweithredu gorchymyn). Maent yn wahanol o ran pa benderfyniadau a wnânt mewn ymateb i broblemau yn y codennau. Mae livenessProbe yn ailgychwyn y cynhwysydd yn y gobaith na fydd y gwall yn digwydd eto, ac mae parodrwyddProbe yn ynysu'r pod rhag traffig sy'n dod i mewn nes bod achos y broblem wedi'i ddatrys.

Dylai dyluniad cymhwysiad priodol gynnwys y ddau fath o wirio a sicrhau eu bod yn casglu digon o ddata, yn enwedig pan fydd eithriad yn cael ei daflu. Dylai hefyd ddangos y pwyntiau terfyn API angenrheidiol sy'n darparu metrigau iechyd pwysig i'r system fonitro (Prometheus).

Ffynhonnell: hab.com