ProHoster > Blogs > Administrācija > Kubernetes konteineru paraugprakse: veselības pārbaudes

Kubernetes konteineru paraugprakse: veselības pārbaudes

Kubernetes konteineru paraugprakse: veselības pārbaudes

TL; DR

  • Lai panāktu augstu konteineru un mikropakalpojumu novērojamÄ«bu, ar žurnāliem un primārajiem rādÄ«tājiem nepietiek.
  • Lai nodroÅ”inātu ātrāku atkopÅ”anu un palielinātu elastÄ«bu, lietojumprogrammām ir jāpiemēro augstas novērojamÄ«bas princips (HOP).
  • Lietojumprogrammas lÄ«menÄ« NOP pieprasa: pareizu reÄ£istrÄ“Å”anu, cieÅ”u uzraudzÄ«bu, saprāta pārbaudes un veiktspējas/pārejas izsekoÅ”anu.
  • Izmantojiet čekus kā NOR elementu gatavÄ«bas zonde Šø dzÄ«vÄ«guma zonde Kubernetes.

Kas ir veselības pārbaudes veidne?

Izstrādājot misijai kritisku un ļoti pieejamu lietojumprogrammu, ir ļoti svarÄ«gi padomāt par tādu aspektu kā kļūdu tolerance. Lietojumprogramma tiek uzskatÄ«ta par defektu tolerantu, ja tā ātri atjaunojas pēc neveiksmes. Tipiska mākoņa lietojumprogramma izmanto mikropakalpojumu arhitektÅ«ru ā€“ kur katrs komponents tiek ievietots atseviŔķā konteinerā. Un, lai nodroÅ”inātu, ka lietojumprogramma k8s ir ļoti pieejama, veidojot klasteru, jums ir jāievēro noteikti modeļi. Starp tiem ir VeselÄ«bas pārbaudes veidne. Tas nosaka, kā lietojumprogramma paziņo k8s, ka tā ir veselÄ«ga. Å Ä« ir ne tikai informācija par to, vai pods darbojas, bet arÄ« par to, kā tas saņem pieprasÄ«jumus un reaģē uz tiem. Jo vairāk Kubernetes zina par poda stāvokli, jo gudrākus lēmumus tā pieņem par satiksmes marÅ”rutÄ“Å”anu un slodzes lÄ«dzsvaroÅ”anu. Tādējādi augstas novērojamÄ«bas princips ļauj lietojumprogrammai reaģēt uz pieprasÄ«jumiem savlaicÄ«gi.

Augstas novērojamības princips (HOP)

Augstas novērojamÄ«bas princips ir viens no konteineru lietojumu projektÄ“Å”anas principi. Mikropakalpojumu arhitektÅ«rā pakalpojumiem ir vienalga, kā viņu pieprasÄ«jums tiek apstrādāts (un tas ir pareizi), bet svarÄ«gi ir tas, kā tie saņem atbildes no saņēmējiem pakalpojumiem. Piemēram, lai autentificētu lietotāju, viens konteiners nosÅ«ta HTTP pieprasÄ«jumu citam, sagaidot atbildi noteiktā formātā ā€“ tas arÄ« viss. PythonJS var arÄ« apstrādāt pieprasÄ«jumu, un Python Flask var atbildēt. Konteineri viens otram ir kā melnās kastes ar slēptu saturu. Tomēr NOP princips nosaka, ka katram pakalpojumam ir jāatklāj vairāki API galapunkti, kas norāda, cik tas ir veselÄ«gs, kā arÄ« tā gatavÄ«bu un kļūdu tolerances statusu. Kubernetes pieprasa Å”os rādÄ«tājus, lai pārdomātu nākamās darbÄ«bas marÅ”rutÄ“Å”anai un slodzes lÄ«dzsvaroÅ”anai.

Labi izstrādāta mākoņa lietojumprogramma reÄ£istrē savus galvenos notikumus, izmantojot standarta I/O straumes STDERR un STDOUT. Tālāk nāk palÄ«gpakalpojums, piemēram, filebeat, logstash vai fluentd, kas piegādā žurnālus centralizētai uzraudzÄ«bas sistēmai (piemēram, Prometheus) un žurnālu vākÅ”anas sistēmai (ELK programmatÅ«ras komplekts). Tālāk esoÅ”ajā diagrammā parādÄ«ts, kā mākoņa lietojumprogramma darbojas saskaņā ar veselÄ«bas pārbaudes modeli un augstas novērojamÄ«bas principu.

Kubernetes konteineru paraugprakse: veselības pārbaudes

Kā piemērot veselības pārbaudes modeli Kubernetes?

Izņemot no kastes, k8s uzrauga podiņu statusu, izmantojot vienu no kontrolleriem (izvietoÅ”anu, ReplicaSets, DaemonSets, StatefulSets utt., utt.). Atklājot, ka pods kāda iemesla dēļ ir nokritis, kontrolieris mēģina to restartēt vai pārvietot uz citu mezglu. Tomēr pods var ziņot, ka tas ir izveidots un darbojas, bet pats nedarbojas. Sniegsim piemēru: jÅ«su lietojumprogramma izmanto Apache kā tÄ«mekļa serveri, jÅ«s instalējāt komponentu vairākos klastera podiņos. Tā kā bibliotēka tika konfigurēta nepareizi, visi pieprasÄ«jumi lietojumprogrammai atbild ar kodu 500 (iekŔēja servera kļūda). Pārbaudot piegādi, pākstu statusa pārbaude dod veiksmÄ«gu rezultātu, taču klienti domā citādi. Mēs aprakstÄ«sim Å”o nevēlamo situāciju Ŕādi:

Kubernetes konteineru paraugprakse: veselības pārbaudes

MÅ«su piemērā k8s to dara funkcionalitātes pārbaude. Šāda veida verifikācijā kubelet nepārtraukti pārbauda procesa stāvokli konteinerā. Kad viņŔ sapratÄ«s, ka process ir apstājies, viņŔ to atsāks. Ja kļūdu var novērst, vienkārÅ”i restartējot lietojumprogrammu, un programma ir paredzēta, lai izslēgtu jebkuru kļūdu, procesa stāvokļa pārbaude ir viss, kas jums nepiecieÅ”ams, lai ievērotu NOP un veselÄ«bas pārbaudes modeli. VienÄ«gi žēl, ka ne visas kļūdas tiek novērstas ar restartÄ“Å”anu. Å ajā gadÄ«jumā k8s piedāvā 2 dziļākus veidus, kā identificēt podziņas: dzÄ«vÄ«guma zonde Šø gatavÄ«bas zonde.

LivenessProbe

Laikā dzīvīguma zonde kubelet veic 3 veidu pārbaudes: ne tikai nosaka, vai pods darbojas, bet arī vai tas ir gatavs saņemt pieprasījumus un adekvāti atbildēt uz tiem:

  • Iestatiet HTTP pieprasÄ«jumu podam. Atbildē ir jāietver HTTP atbildes kods diapazonā no 200 lÄ«dz 399. Tādējādi kodi 5xx un 4xx norāda, ka podā ir problēmas, lai gan process darbojas.
  • Lai pārbaudÄ«tu apvidus ar pakalpojumiem, kas nav HTTP pakalpojumi (piemēram, Postfix pasta serveri), ir jāizveido TCP savienojums.
  • Izpildiet patvaļīgu komandu podam (iekŔēji). Pārbaude tiek uzskatÄ«ta par veiksmÄ«gu, ja komandas pabeigÅ”anas kods ir 0.

Piemērs, kā tas darbojas. Nākamajā pod definÄ«cijā ir NodeJS lietojumprogramma, kas HTTP pieprasÄ«jumos rada kļūdu 500. Lai pārliecinātos, ka konteiners tiek restartēts, saņemot Ŕādu kļūdu, mēs izmantojam parametru 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

Tas neatŔķiras no jebkuras citas pod definÄ«cijas, taču mēs pievienojam objektu .spec.containers.livenessProbe. Parametrs httpGet pieņem ceļu, uz kuru tiek nosÅ«tÄ«ts HTTP GET pieprasÄ«jums (mÅ«su piemērā tas ir /, bet kaujas scenārijos var bÅ«t kaut kas lÄ«dzÄ«gs /api/v1/status). Vēl viens dzÄ«vÄ«gumsProbe pieņem parametru initialDelaySeconds, kas uzdod verifikācijas darbÄ«bai gaidÄ«t noteiktu sekunžu skaitu. Aizkave ir nepiecieÅ”ama, jo konteineram ir nepiecieÅ”ams laiks, lai palaistu, un pēc restartÄ“Å”anas tas kādu laiku nebÅ«s pieejams.

Lai lietotu Ŕo iestatījumu klasterim, izmantojiet:

kubectl apply -f pod.yaml

Pēc dažām sekundēm varat pārbaudÄ«t pāksts saturu, izmantojot Ŕādu komandu:

kubectl describe pods node500

Izvades beigās atrodiet tas ir kas.

Kā redzat, livenessProbe ierosināja HTTP GET pieprasÄ«jumu, konteiners Ä£enerēja kļūdu 500 (tas ir tas, kam tas bija ieprogrammēts), un kubelet to restartēja.

Ja vēlaties uzzināt, kā tika ieprogrammēta lietojumprogramma NideJS, Å”eit ir izmantotie faili app.js un Dockerfile:

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

Ir svarÄ«gi atzÄ«mēt Å”o: livenessProbe restartēs konteineru tikai tad, ja tas neizdosies. Ja restartÄ“Å”ana neizlabo kļūdu, kas neļauj konteineram darboties, kubelet nevarēs veikt darbÄ«bas, lai novērstu problēmu.

gatavības zonde

ReadinessProbe darbojas lÄ«dzÄ«gi kā livenessProbes (GET pieprasÄ«jumi, TCP sakari un komandu izpilde), izņemot traucējummeklÄ“Å”anas darbÄ«bas. Konteiners, kurā tiek konstatēta kļūme, netiek restartēts, bet ir izolēts no ienākoŔās trafika. Iedomājieties, ka viens no konteineriem veic daudz aprēķinu vai ir pakļauts lielai slodzei, kā rezultātā palielinās reakcijas laiks. LivenessProbe gadÄ«jumā tiek aktivizēta atbildes pieejamÄ«bas pārbaude (izmantojot timeoutSeconds pārbaudes parametru), pēc kuras kubelet restartē konteineru. Pēc palaiÅ”anas konteiners sāk veikt resursietilpÄ«gus uzdevumus un tiek restartēts vēlreiz. Tas var bÅ«t ļoti svarÄ«gi lietojumprogrammām, kurām nepiecieÅ”ams reakcijas ātrums. Piemēram, automaŔīna, atrodoties ceļā, gaida atbildi no servera, atbilde tiek aizkavēta - un automaŔīna nonāk avārijā.

UzrakstÄ«sim redinessProbe definÄ«ciju, kas iestatÄ«s GET pieprasÄ«juma atbildes laiku ne vairāk kā divas sekundes, un lietojumprogramma atbildēs uz GET pieprasÄ«jumu pēc 5 sekundēm. Pod.yaml failam vajadzētu izskatÄ«ties Ŕādi:

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

Izvietosim podi ar kubectl:

kubectl apply -f pod.yaml

Pagaidīsim dažas sekundes un tad redzēsim, kā darbojās ReadinessProbe:

kubectl describe pods nodedelayed

Izvades beigās var redzēt, ka daži notikumi ir lÄ«dzÄ«gi Å”is.

Kā redzat, kubectl nerestartēja podziņu, kad pārbaudes laiks pārsniedza 2 sekundes. Tā vietā viņŔ atcēla pieprasÄ«jumu. IenākoÅ”ie sakari tiek novirzÄ«ti uz citiem, strādājoÅ”iem podiem.

Ņemiet vērā, ka tagad, kad pods ir izlādēts, kubectl atkārtoti novirza pieprasījumus uz to: atbildes uz GET pieprasījumiem vairs netiek aizkavētas.

Salīdzinājumam zemāk ir modificētais fails app.js: 

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
Pirms mākoņa lietojumprogrammu parādÄ«Å”anās žurnāli bija galvenais lÄ«dzeklis lietojumprogrammu darbÄ«bas pārraudzÄ«bai un pārbaudei. Tomēr nebija nekādu lÄ«dzekļu, lai veiktu korektÄ«vus pasākumus. Žurnāli ir noderÄ«gi arÄ« Å”odien, tie ir jāsavāc un jānosÅ«ta uz žurnālu savākÅ”anas sistēmu, lai analizētu ārkārtas situācijas un pieņemtu lēmumus. [To visu varēja izdarÄ«t bez mākoņa aplikācijām, piemēram, izmantojot monit, bet ar k8s kļuva daudz vienkārŔāk :) ā€“ redaktora piezÄ«me. ]

Mūsdienās korekcijas ir jāveic gandrīz reāllaikā, tāpēc pieteikumiem vairs nav jābūt melnajām kastēm. Nē, tiem ir jāparāda galapunkti, kas ļauj pārraudzības sistēmām veikt vaicājumus un apkopot vērtīgus datus par procesu stāvokli, lai vajadzības gadījumā tās varētu nekavējoties reaģēt. To sauc par veiktspējas pārbaudes dizaina modeli, kas atbilst augstas novērojamības principam (HOP).

Kubernetes pēc noklusējuma piedāvā 2 veidu veselÄ«bas pārbaudes: readynessProbe un livenessProbe. Abi izmanto viena veida pārbaudes (HTTP GET pieprasÄ«jumi, TCP sakari un komandu izpilde). Viņi atŔķiras ar to, kādus lēmumus viņi pieņem, reaģējot uz problēmām pākstÄ«s. livenessProbe restartē konteineru, cerot, ka kļūda vairs neatkārtosies, un readinessProbe izolē podziņu no ienākoŔās trafika, lÄ«dz tiek novērsts problēmas cēlonis.

Pareizā lietojumprogrammas izstrādē jāiekļauj abi pārbaudes veidi un jānodroÅ”ina, lai tie savāktu pietiekami daudz datu, jo Ä«paÅ”i, ja tiek izdarÄ«ts izņēmums. Tam vajadzētu arÄ« parādÄ«t nepiecieÅ”amos API galapunktus, kas nodroÅ”ina uzraudzÄ«bas sistēmai (Prometheus) svarÄ«gus veselÄ«bas rādÄ«tājus.

Avots: www.habr.com

Pievieno komentāru