Kubernetes edukiontzietarako praktika onak: osasun-egiaztapenak

TL; DR

• Edukiontzien eta mikrozerbitzuen behagarritasun handia lortzeko, erregistroak eta neurketa nagusiak ez dira nahikoa.
• Berreskuratze azkarragoa eta erresilientzia areagotzeko, aplikazioek Behagarritasun Handiko Printzipioa (HOP) aplikatu beharko lukete.
• Aplikazio mailan, NOPek honako hauek eskatzen ditu: erregistro egokia, jarraipen hurbila, osasun-egiaztapenak eta errendimendu/trantsizioaren jarraipena.
• Erabili txekeak NOR-en elementu gisa prestasunaProbe и bizitasunaProbe Kubernetes.

Zer da Osasun Azterketaren txantiloia?

Aplikazio kritikoa eta oso eskuragarria diseinatzerakoan, oso garrantzitsua da akatsen tolerantzia bezalako alderdi bat pentsatzea. Aplikazio bat akatsak tolerantetzat jotzen da porrotetik azkar berreskuratzen bada. Hodeiko aplikazio tipiko batek mikrozerbitzuen arkitektura bat erabiltzen du, non osagai bakoitza edukiontzi bereizi batean jartzen den. Eta k8s-en aplikazioa kluster bat diseinatzean oso erabilgarri dagoela ziurtatzeko, zenbait eredu jarraitu behar dituzu. Horien artean dago Osasun Kontrolaren Txantiloia. Aplikazioa k8s-i osasuntsu dagoela nola komunikatzen dien definitzen du. Hau ez da bakarrik pod-a martxan dagoen ala ez, eskaerak jasotzen eta erantzuten dituenari buruzkoa ere. Zenbat eta gehiago jakin Kubernetes podaren osasunari buruz, orduan eta erabaki adimentsuagoak hartuko ditu trafikoaren bideratze eta karga orekatzeari buruz. Hala, Behagarritasun Handiko Printzipioari esker, aplikazioak eskaerei garaiz erantzuteko aukera ematen die.

Behagarritasun handiko printzipioa (HOP)

Behagarritasun handiko printzipioa bat da edukiontzidun aplikazioak diseinatzeko printzipioak. Mikrozerbitzuen arkitektura batean, zerbitzuei ez zaie axola nola prozesatzen den eskaera (eta arrazoiz), baina axola duena da zerbitzu hartzaileen erantzunak nola jasotzen dituzten. Adibidez, erabiltzaile bat autentifikatzeko, edukiontzi batek HTTP eskaera bat bidaltzen dio beste bati, formatu jakin bateko erantzuna espero du - hori da dena. PythonJS-k eskaera prozesatu dezake eta Python Flask-ek erantzun dezake. Ontziak elkarren artean ezkutuko edukia duten kutxa beltzak bezalakoak dira. Hala ere, NOP printzipioak zerbitzu bakoitzak API amaierako puntu bat baino gehiago agerian uztea eskatzen du zeinen osasuntsua den adierazten duten, baita prest dagoen eta akatsen tolerantziaren egoera ere. Kubernetes-ek adierazle hauek eskatzen ditu bideratze eta karga orekatzeko hurrengo urratsak pentsatzeko.

Ondo diseinatutako hodeiko aplikazio batek bere gertaera nagusiak erregistratzen ditu STDERR eta STDOUT I/O korronte estandarrak erabiliz. Ondoren, zerbitzu laguntzaile bat dator, adibidez, filebeat, logstash edo fluentd, erregistroak monitorizazio-sistema zentralizatu batera (adibidez, Prometheus) eta erregistroak biltzeko sistema batera (ELK software-suitea) entregatuz. Beheko diagraman hodeiko aplikazio batek nola funtzionatzen duen erakusten du Osasun Proba Ereduaren eta Behagarritasun Handiko Printzipioaren arabera.

Nola aplikatu Osasun Kontrolaren Eredua Kubernetes-en?

Kutxatik kanpo, k8s-ek poden egoera kontrolatzen du kontrolagailuetako bat erabiliz (garapen, Erreplika multzoak, DaemonSets, StatefulSets etab., etab.). Arrazoiren batengatik poda erori dela deskubritu ondoren, kontrolagailua berrabiarazi edo beste nodo batera eramaten saiatzen da. Hala ere, pod batek martxan dagoela jakinarazi dezake, baina berak ez du funtzionatzen. Eman dezagun adibide bat: zure aplikazioak Apache erabiltzen du web zerbitzari gisa, zuk instalatu duzu osagaia klusterreko hainbat podetan. Liburutegia gaizki konfiguratuta zegoenez, aplikazioari egindako eskaera guztiek 500 kodearekin erantzuten dute (barneko zerbitzariaren errorea). Bidalketa egiaztatzean, leken egoera egiaztatzeak emaitza arrakastatsua ematen du, baina bezeroek ezberdin pentsatzen dute. Egoera desiragarri hau honela deskribatuko dugu:

Gure adibidean, k8s egiten du funtzionaltasuna egiaztatzea. Egiaztapen mota honetan, kubeletak etengabe egiaztatzen du ontzian prozesuaren egoera. Prozesua gelditu dela ulertzen duenean, berrabiaraziko du. Errorea aplikazioa berrabiarazi besterik ez baduzu konpon daiteke eta programa edozein erroretan itzaltzeko diseinatuta badago, orduan prozesuko osasun-egiaztapena da NOP eta Osasun Test eredua jarraitzeko behar duzun guztia. Pena bakarra da akats guztiak ez direla kentzen berrabiaraziz. Kasu honetan, k8s-ek 2 modu sakonago eskaintzen ditu podarekin arazoak identifikatzeko: bizitasunaProbe и prestasunaProbe.

LivenessProbe

Zehar bizitasunaProbe kubelet-ek 3 egiaztapen mota egiten ditu: pod-a martxan dagoen ala ez zehazten du, baita eskaerak jasotzeko eta behar bezala erantzuteko prest dagoen ere:

• Konfiguratu HTTP eskaera podan. Erantzunak 200 eta 399 bitarteko HTTP erantzun-kode bat izan behar du. Horrela, 5xx eta 4xx kodeek podak arazoak dituela adierazten dute, prozesua martxan dagoen arren.
• HTTP ez diren zerbitzuak dituzten pod-ak probatzeko (adibidez, Postfix posta zerbitzaria), TCP konexio bat ezarri behar duzu.
• Exekutatu komando arbitrario bat pod baterako (barrutik). Egiaztapena arrakastatsutzat jotzen da komandoa osatzeko kodea 0 bada.

Honen funtzionamenduaren adibide bat. Hurrengo pod definizioak HTTP eskaeretan 500 errore bat botatzen duen NodeJS aplikazio bat dauka. Errore bat jasotzean edukiontzia berrabiarazi dela ziurtatzeko, livenessProbe parametroa erabiltzen dugu:

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

Hau ez da beste edozein pod definizio ezberdina, baina objektu bat gehitzen ari gara .spec.containers.livenessProbe. Parametroa httpGet HTTP GET eskaera bidaltzen den bidea onartzen du (gure adibidean hau da /, baina borroka agertokietan antzeko zerbait egon daiteke /api/v1/status). Beste livenessProbe batek parametro bat onartzen du initialDelaySeconds, egiaztapen-eragiketari segundo kopuru jakin bat itxaron dezan agintzen diona. Atzerapena beharrezkoa da edukiontziak abiarazteko denbora behar duelako, eta berrabiarazitakoan denbora pixka batean erabilgarri egongo ez delako.

Ezarpen hau kluster bati aplikatzeko, erabili:

kubectl apply -f pod.yaml

Segundo batzuk igaro ondoren, ontziaren edukia egiaztatu dezakezu komando hau erabiliz:

kubectl describe pods node500

Irteeraren amaieran, bilatu hori da.

Ikus dezakezunez, livenessProbe-k HTTP GET eskaera bat hasi zuen, edukiontziak 500 errore bat sortu zuen (hori da programatu zena egiteko), eta kubelet-ek berrabiarazi zuen.

NideJS aplikazioa nola programatu zen galdetzen ari bazara, hona hemen erabili ziren app.js eta Dockerfile:

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

Garrantzitsua da hau kontuan hartzea: livenessProbe-k edukiontzia huts egiten badu soilik berrabiaraziko du. Berrabiarazte batek ez badu konpontzen edukiontzia martxan jartzea eragozten duen errorea, kubelet-ek ezingo du arazoa zuzentzeko neurririk hartu.

prestasunaProbe

ReadinessProbe-k livenessProbes-en antzera funtzionatzen du (GET eskaerak, TCP komunikazioak eta komandoen exekuzioa), arazoak konpontzeko ekintzetan izan ezik. Hutsegitea hautematen den edukiontzia ez da berrabiarazten, sarrerako trafikotik isolatuta dago. Imajinatu edukiontziren bat kalkulu asko egiten ari dela edo karga handian dagoela, erantzun denborak handitzea eragiten duela. LivenessProbe-ren kasuan, erantzunaren erabilgarritasunaren egiaztapena abiarazten da (timeoutSeconds check parametroaren bidez), eta ondoren kubelet-ek edukiontzia berrabiaraziko du. Abiaraztean, edukiontzia baliabide askoko zereginak egiten hasten da eta berriro berrabiarazi egiten da. Hau ezinbestekoa izan daiteke erantzun-abiadura behar duten aplikazioetarako. Adibidez, auto bat errepidean dagoenean zerbitzariaren erantzunaren zain dago, erantzuna atzeratu egiten da eta autoak istripua izaten du.

Idatzi dezagun redinessProbe definizio bat, GET eskaeraren erantzun-denbora bi segundo baino gehiagokoa izango ez duena, eta aplikazioak GET eskaerari erantzungo dio 5 segundoren buruan. pod.yaml fitxategiak honela izan beharko luke:

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

Inplementatu dezagun kubectl-rekin pod bat:

kubectl apply -f pod.yaml

Itxaron ditzagun segundo pare bat eta ikus dezagun nola funtzionatu zuen ReadinessProbe-k:

kubectl describe pods nodedelayed

Irteeraren amaieran gertaera batzuk antzekoak direla ikus dezakezu hau.

Ikus dezakezunez, kubectl-ek ez zuen poda berrabiarazi egiaztapen-denbora 2 segundo baino gehiago igaro zenean. Horren ordez, eskaera bertan behera utzi zuen. Jasotzen diren komunikazioak beste lanbide batzuetara birbideratzen dira.

Kontuan izan orain pod-a deskargatuta dagoela, kubectl-ek berriro bideratzen dituela eskaerak: GET eskaeren erantzunak ez dira atzeratzen.

Konparatzeko, behean aldatutako app.js fitxategia dago:

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
Hodeiko aplikazioak agertu aurretik, erregistroak ziren aplikazioen osasuna kontrolatzeko eta egiaztatzeko baliabide nagusiak. Hala ere, ez zegoen neurri zuzentzailerik hartzeko modurik. Erregistroak erabilgarriak dira gaur egun ere; larrialdi egoerak aztertzeko eta erabakiak hartzeko erregistroak biltzeko sistema batera bildu eta bidali behar dira. [Hori guztia hodeiko aplikaziorik gabe egin zitekeen monit erabiliz, adibidez, baina k8s-ekin askoz errazagoa bihurtu zen :) - editorearen oharra. ]

Gaur egun, zuzenketak ia denbora errealean egin behar dira, beraz, aplikazioak ez dira kutxa beltzak izan behar. Ez, monitorizazio-sistemei prozesuen egoerari buruzko datu baliotsuak kontsultatu eta biltzeko aukera ematen duten amaiera-puntuak erakutsi beharko lituzkete, beharrezkoa izanez gero berehala erantzun ahal izateko. Honi Performance Test Design Pattern deitzen zaio, Behagarritasun Handiko Printzipioa (HOP) jarraitzen duena.

Kubernetesek 2 osasun egiaztapen mota eskaintzen ditu lehenespenez: ReadinessProbe eta livenessProbe. Biek egiaztapen mota berdinak erabiltzen dituzte (HTTP GET eskaerak, TCP komunikazioak eta komandoen exekuzioa). Lekak dauden arazoei erantzuteko zein erabaki hartzen dituzten desberdinak dira. livenessProbe-k edukiontzia berrabiarazten du errorea berriro gertatuko ez den itxaropenarekin, eta ReadinessProbe-k poda sarrerako trafikotik isolatzen du arazoaren kausa konpondu arte.

Aplikazioaren diseinu egokiak bi egiaztapen motak barne hartu behar ditu eta datu nahikoa biltzen dutela ziurtatu behar du, batez ere salbuespen bat botatzen denean. Halaber, monitorizazio sistemari (Prometheus) osasun-neurri garrantzitsuak eskaintzen dizkioten beharrezko API-puntuak ere erakutsi beharko lituzke.

Iturria: www.habr.com