Beste praktyke vir Kubernetes-houers: Gesondheidsondersoeke

TL; DR

• Om hoë waarneembaarheid van houers en mikrodienste te bereik, is logs en primêre maatstawwe nie genoeg nie.
• Vir vinniger herstel en verhoogde veerkragtigheid, moet toepassings die Hoë Waarneembaarheidsbeginsel (HOP) toepas.
• Op die toepassingsvlak vereis NOP: behoorlike aantekening, noukeurige monitering, gesonde verstandkontrole en prestasie/oorgangnasporing.
• Gebruik tjeks as 'n element van NOR gereedheid Ondersoek и lewendigheidSondersoek Kubernetes.

Wat is 'n Gesondheidsondersoek-sjabloon?

Wanneer 'n missie-kritiese en hoogs beskikbare toepassing ontwerp word, is dit baie belangrik om aan so 'n aspek soos fouttoleransie te dink. 'n Aansoek word as foutverdraagsaam beskou as dit vinnig herstel van mislukking. 'n Tipiese wolktoepassing gebruik 'n mikrodienste-argitektuur - waar elke komponent in 'n aparte houer geplaas word. En om seker te maak dat die toepassing op k8s hoogs beskikbaar is wanneer jy 'n cluster ontwerp, moet jy sekere patrone volg. Onder hulle is die Health Check Template. Dit definieer hoe die toepassing aan k8s kommunikeer dat dit gesond is. Dit is nie net inligting oor of die peul aan die gang is nie, maar ook oor hoe dit versoeke ontvang en daarop reageer. Hoe meer Kubernetes van die gesondheid van die peul weet, hoe slimmer besluite neem dit oor verkeersroetes en vragbalansering. Die Hoë Waarneembaarheidsbeginsel laat die toepassing dus toe om betyds op versoeke te reageer.

Hoë Waarneembaarheidsbeginsel (HOP)

Die beginsel van hoë waarneembaarheid is een van beginsels vir die ontwerp van houertoepassings. In 'n mikrodienste-argitektuur gee dienste nie om hoe hul versoek verwerk word nie (en tereg), maar wat saak maak, is hoe hulle antwoorde van die ontvangende dienste ontvang. Byvoorbeeld, om 'n gebruiker te verifieer, stuur een houer 'n HTTP-versoek na 'n ander, en verwag 'n antwoord in 'n sekere formaat - dit is al. PythonJS kan ook die versoek verwerk, en Python Flask kan reageer. Houers is soos swart bokse met verborge inhoud vir mekaar. Die NOP-beginsel vereis egter dat elke diens verskeie API-eindpunte blootstel wat aandui hoe gesond dit is, sowel as sy gereedheid en foutverdraagsaamheidstatus. Kubernetes versoek hierdie aanwysers om die volgende stappe vir roetering en vragbalansering deur te dink.

'n Goed ontwerpte wolktoepassing teken sy hoofgebeurtenisse aan met behulp van die standaard I/O-strome STDERR en STDOUT. Vervolgens kom 'n hulpdiens, byvoorbeeld filebeat, logstash of fluentd, wat logs aan 'n gesentraliseerde moniteringstelsel (byvoorbeeld Prometheus) en 'n loginsamelingstelsel (ELK-sagtewaresuite) lewer. Die diagram hieronder wys hoe 'n wolktoepassing volgens die Gesondheidstoetspatroon en die Hoë Waarneembaarheidsbeginsel werk.

Hoe om die gesondheidskontrolepatroon in Kubernetes toe te pas?

Uit die boks monitor k8s die status van die peule met een van die beheerders (ontplooi, ReplikaSets, DaemonSets, StatefulSets ens., ens.). Nadat hy ontdek het dat die peul om een ​​of ander rede geval het, probeer die beheerder om dit te herbegin of dit na 'n ander nodus te skuif. 'n Peul kan egter rapporteer dat dit aan die gang is, maar dit self funksioneer nie. Kom ons gee 'n voorbeeld: jou toepassing gebruik Apache as 'n webbediener, jy het die komponent op verskeie peule van die groepie geïnstalleer. Aangesien die biblioteek verkeerd opgestel is, reageer alle versoeke aan die toepassing met kode 500 (interne bedienerfout). As u aflewering nagaan, gee die nagaan van die status van peule 'n suksesvolle resultaat, maar kliënte dink anders. Ons sal hierdie ongewenste situasie soos volg beskryf:

In ons voorbeeld doen k8s funksionaliteit kontroleer. In hierdie tipe verifikasie kontroleer die kubelet voortdurend die toestand van die proses in die houer. Sodra hy verstaan ​​dat die proses gestop het, sal hy dit weer begin. As die fout opgelos kan word deur bloot die toepassing te herbegin, en die program is ontwerp om af te sluit op enige fout, dan is 'n prosesgesondheidsondersoek al wat jy nodig het om die NOP en die Gesondheidstoetspatroon te volg. Die enigste jammerte is dat nie alle foute uitgeskakel word deur weer te begin nie. In hierdie geval bied k8s 2 dieper maniere om probleme met die peul te identifiseer: lewendigheidSondersoek и gereedheid Ondersoek.

LivenessProbe

tydens lewendigheidSondersoek kubelet voer 3 tipes kontrole uit: bepaal nie net of die peul aan die gang is nie, maar ook of dit gereed is om versoeke te ontvang en voldoende daarop te reageer:

• Stel 'n HTTP-versoek na die pod op. Die antwoord moet 'n HTTP-antwoordkode in die reeks van 200 tot 399 bevat. Kodes 5xx en 4xx dui dus aan dat die peul probleme ondervind, alhoewel die proses aan die gang is.
• Om peule met nie-HTTP-dienste te toets (byvoorbeeld die Postfix-posbediener), moet jy 'n TCP-verbinding vestig.
• Voer 'n arbitrêre opdrag vir 'n peul (intern) uit. Die kontrole word as suksesvol beskou as die opdragvoltooiingskode 0 is.

'n Voorbeeld van hoe dit werk. Die volgende pod-definisie bevat 'n NodeJS-toepassing wat 'n 500-fout op HTTP-versoeke gooi. Om seker te maak dat die houer herbegin word wanneer so 'n fout ontvang word, gebruik ons ​​die livenessProbe-parameter:

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

Dit verskil nie van enige ander peuldefinisie nie, maar ons voeg 'n voorwerp by .spec.containers.livenessProbe... Parameter httpGet aanvaar die pad waarheen die HTTP GET-versoek gestuur word (in ons voorbeeld is dit /, maar in gevegscenario's kan daar iets wees soos /api/v1/status). Nog 'n lewendige sonde aanvaar 'n parameter initialDelaySeconds, wat die verifikasiebewerking opdrag gee om 'n gespesifiseerde aantal sekondes te wag. Die vertraging is nodig omdat die houer tyd nodig het om te begin, en wanneer dit weer begin word, sal dit vir 'n geruime tyd onbeskikbaar wees.

Om hierdie instelling op 'n groepering toe te pas, gebruik:

kubectl apply -f pod.yaml

Na 'n paar sekondes kan jy die inhoud van die peul nagaan deur die volgende opdrag te gebruik:

kubectl describe pods node500

Aan die einde van die afvoer, vind Dis wat.

Soos u kan sien, het livenessProbe 'n HTTP GET-versoek geïnisieer, die houer het 'n fout 500 gegenereer (dit is wat dit geprogrammeer is om te doen), en die kubelet het dit weer begin.

As jy wonder hoe die NideJS-toepassing geprogrammeer is, hier is die app.js en Dockerfile wat gebruik is:

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

Dit is belangrik om dit op te let: livenessProbe sal slegs die houer herbegin as dit misluk. As 'n herbegin nie die fout regstel wat verhinder dat die houer loop nie, sal die kubelet nie aksie kan neem om die probleem reg te stel nie.

gereedheid Ondersoek

readinessProbe werk soortgelyk aan livenessProbes (GET-versoeke, TCP-kommunikasie en opdraguitvoering), behalwe vir probleemoplossingsaksies. Die houer waarin die mislukking bespeur word, word nie herbegin nie, maar is geïsoleer van inkomende verkeer. Stel jou voor dat een van die houers baie berekeninge doen of onder swaar vrag is, wat veroorsaak dat reaksietye toeneem. In die geval van livenessProbe, word die responsbeskikbaarheidkontrole geaktiveer (via die timeoutSeconds check parameter), waarna die kubelet die houer herbegin. Wanneer dit begin word, begin die houer om hulpbron-intensiewe take uit te voer en word weer herbegin. Dit kan krities wees vir toepassings wat reaksiespoed benodig. Byvoorbeeld, 'n motor terwyl op die pad wag vir 'n reaksie van die bediener, die reaksie word vertraag - en die motor beland in 'n ongeluk.

Kom ons skryf 'n redinessProbe-definisie wat die AOO-versoek-reaksietyd op nie meer as twee sekondes sal stel nie, en die toepassing sal na 5 sekondes op die AOO-versoek reageer. Die pod.yaml-lêer moet soos volg lyk:

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

Kom ons ontplooi 'n peul met kubectl:

kubectl apply -f pod.yaml

Kom ons wag 'n paar sekondes en kyk dan hoe die gereedheidsondersoek gewerk het:

kubectl describe pods nodedelayed

Aan die einde van die afvoer kan jy sien dat sommige van die gebeure soortgelyk is hierdie een.

Soos u kan sien, het kubectl nie die peul herbegin toe die kontroletyd 2 sekondes oorskry het nie. In plaas daarvan het hy die versoek gekanselleer. Inkomende kommunikasie word herlei na ander, werkende peule.

Let daarop dat noudat die peul afgelaai is, stuur kubectl versoeke weer na dit: antwoorde op AOO-versoeke word nie meer vertraag nie.

Ter vergelyking, hieronder is die gewysigde app.js-lêer:

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
Voor die koms van wolktoepassings was logs die primêre manier om toepassingsgesondheid te monitor en na te gaan. Daar was egter geen manier om enige regstellende stappe te neem nie. Logs is vandag nog bruikbaar; dit moet versamel en na 'n loginsamelingstelsel gestuur word om noodsituasies te ontleed en besluite te neem. [Dit alles kan gedoen word sonder wolktoepassings wat byvoorbeeld monit gebruik, maar met k8s het dit baie makliker geword :) – redakteur se nota. ]

Vandag moet regstellings amper intyds gemaak word, so aansoeke hoef nie meer swart bokse te wees nie. Nee, hulle moet eindpunte wys wat moniteringstelsels toelaat om navraag te doen en waardevolle data oor die stand van prosesse in te samel sodat hulle onmiddellik kan reageer indien nodig. Dit word die Prestasietoetsontwerppatroon genoem, wat die Hoë Waarneembaarheidsbeginsel (HOP) volg.

Kubernetes bied by verstek 2 tipes gesondheidsondersoeke aan: gereedheidsondersoek en lewendheidsondersoek. Albei gebruik dieselfde tipe tjeks (HTTP GET-versoeke, TCP-kommunikasie en opdraguitvoering). Hulle verskil in watter besluite hulle neem in reaksie op probleme in die peule. livenessProbe herbegin die houer in die hoop dat die fout nie weer sal gebeur nie, en readinessProbe isoleer die peul van inkomende verkeer totdat die oorsaak van die probleem opgelos is.

Behoorlike toepassingsontwerp moet beide tipes kontrolering insluit en verseker dat hulle genoeg data insamel, veral wanneer 'n uitsondering gegooi word. Dit moet ook die nodige API-eindpunte toon wat die moniteringstelsel (Prometheus) van belangrike gesondheidsmaatstawwe voorsien.

Bron: will.com