Beschte Praktiken fir Kubernetes Container: Gesondheetschecken

TL; DR

• Fir héich Beobachtbarkeet vu Container a Mikroservicer z'erreechen, sinn Logbicher a primär Metriken net genuch.
• Fir méi séier Erhuelung a verstäerkte Widderstandsfäegkeet, sollten Uwendungen den High Observability Principle (HOP) uwenden.
• Um Applikatiounsniveau erfuerdert NOP: richteg Logbicher, enk Iwwerwaachung, Sanitéitskontrollen, a Performance / Iwwergangs Tracing.
• Benotzt Schecken als Element vun NOR Bereetschaft Probe и Liewensdauer Probe Kubernetes.

Wat ass eng Gesondheetscheck Schabloun?

Wann Dir eng Missiounskritesch an héich verfügbare Applikatioun designt, ass et ganz wichteg un esou en Aspekt wéi Feelertoleranz ze denken. Eng Applikatioun gëtt als Feelertolerant ugesinn wann se sech séier vum Versoen erholl. Eng typesch Cloud Applikatioun benotzt eng Mikroservicer Architektur - wou all Komponent an engem getrennten Container plazéiert ass. A fir sécherzestellen datt d'Applikatioun op k8s héich verfügbar ass wann Dir e Cluster designt, musst Dir verschidde Mustere verfollegen. Ënnert hinnen ass d'Gesondheetscheck Schabloun. Et definéiert wéi d'Applikatioun mat k8s kommunizéiert datt et gesond ass. Dëst ass net nëmmen Informatioun iwwer ob de Pod leeft, awer och iwwer wéi en Ufroe kritt an reagéiert. Wat méi Kubernetes iwwer d'Gesondheet vum Pod weess, dest méi schlau mécht Entscheedungen iwwer Traffic Routing a Laaschtbalancéierung. Also erlaabt den High Observability Principle d'Applikatioun fristgerecht op Ufroe z'äntwerten.

Héich Observabilitéitsprinzip (HOP)

De Prinzip vun héich Observabilitéit ass ee vun Prinzipien fir entworf containerized Uwendungen. An enger Mikroservicearchitektur ass d'Servicer egal wéi hir Ufro veraarbecht gëtt (a mat Recht), awer wat wichteg ass wéi se Äntwerte vun den Empfangsservicer kréien. Zum Beispill, fir e Benotzer ze authentifizéieren, schéckt ee Container eng HTTP-Ufro un en aneren, erwaart eng Äntwert an engem bestëmmte Format - dat ass alles. PythonJS kann och d'Ufro veraarbecht, an Python Flask kann äntweren. Container si wéi schwaarz Këschte mat verstoppten Inhalter mateneen. Wéi och ëmmer, den NOP-Prinzip erfuerdert all Service fir verschidde API-Endpunkte z'exposéieren déi uginn wéi gesond et ass, souwéi seng Disponibilitéit a Feelertoleranzstatus. Kubernetes freet dës Indikatoren fir duerch déi nächst Schrëtt fir Routing a Laaschtbalancéierung ze denken.

Eng gutt entworf Cloud-Applikatioun protokolléiert seng Haaptevenementer mat de Standard I/O Streams STDERR a STDOUT. Als nächst kënnt en Hëllefsdéngscht, zum Beispill Filebeat, Logstash oder fluentd, déi Logbicher un en zentraliséierter Iwwerwaachungssystem liwwert (zum Beispill Prometheus) an e Log Sammelsystem (ELK Software Suite). D'Diagramm hei ënnen weist wéi eng Cloud-Applikatioun funktionnéiert no dem Gesondheetstestmuster an dem High Observability Principle.

Wéi applizéiert ech de Gesondheetscheckmuster a Kubernetes?

Aus der Këscht iwwerwaacht k8s de Status vun de Pods mat engem vun de Controller (Deployments, ReplicaSets, DaemonSets, StatefulSets etc., etc.). Nodeems Dir entdeckt hutt datt de Pod aus iergendengem Grond gefall ass, probéiert de Controller et nei ze starten oder en an en aneren Node ze réckelen. Wéi och ëmmer, e Pod kann mellen datt et op a leeft, awer et selwer funktionnéiert net. Loosst eis e Beispill ginn: Är Applikatioun benotzt Apache als Webserver, Dir hutt de Komponent op verschiddene Pods vum Cluster installéiert. Zënter datt d'Bibliothéik falsch konfiguréiert ass, reagéieren all Ufroe fir d'Applikatioun mam Code 500 (interne Serverfehler). Wann Dir d'Liwwerung iwwerpréift, iwwerpréift de Status vun de Pods en erfollegräicht Resultat, awer d'Clienten denken anescht. Mir beschreiwen dës ongewollt Situatioun wéi follegt:

An eisem Beispill mécht k8s Funktionalitéit kontrolléieren. An dëser Aart vu Verifizéierung kontrolléiert de Kubelet kontinuéierlech den Zoustand vum Prozess am Container. Wann hien versteet datt de Prozess gestoppt ass, wäert hien et nei starten. Wann de Feeler geléist ka ginn andeems Dir d'Applikatioun einfach nei start, an de Programm ass entwéckelt fir all Feeler auszeschalten, dann ass e Prozess Gesondheetscheck alles wat Dir braucht fir den NOP an de Gesondheetstestmuster ze verfollegen. Déi eenzeg schued ass datt net all Feeler duerch Neistart eliminéiert ginn. An dësem Fall bitt k8s 2 méi déif Weeër fir Probleemer mam Pod z'identifizéieren: Liewensdauer Probe и Bereetschaft Probe.

LivenessProbe

Während der Liewensdauer Probe kubelet mécht 3 Aarte vu Kontrollen: bestëmmt net nëmmen ob de Pod leeft, awer och ob et prett ass fir Ufroen ze kréien an adäquat ze reagéieren:

• Setzt eng HTTP-Ufro un de Pod op. D'Äntwert muss en HTTP-Reaktiounscode enthalen am Beräich vun 200 bis 399. Also, Coden 5xx an 4xx signaliséieren datt de Pod Problemer huet, obwuel de Prozess leeft.
• Fir Pods mat Net-HTTP-Servicer ze testen (zum Beispill de Postfix Mail Server), musst Dir eng TCP Verbindung opbauen.
• Ausféieren en arbiträr Kommando fir e Pod (intern). De Scheck gëtt als erfollegräich ugesinn wann de Kommando Fäerdegstellungscode 0 ass.

E Beispill vu wéi dëst funktionnéiert. Déi nächst Pod Definitioun enthält eng NodeJS Applikatioun déi e 500 Feeler op HTTP Ufroe werft Fir sécherzestellen datt de Container nei gestart gëtt wann Dir esou e Feeler kritt, benotze mir de 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

Dëst ass net anescht wéi all aner Pod Definitioun, awer mir addéieren en Objet .spec.containers.livenessProbe. Parameter httpGet akzeptéiert de Wee, op deen d'HTTP GET Ufro geschéckt gëtt (an eisem Beispill ass dëst /, mee am Kampf Szenarie kann et eppes wéi /api/v1/status). Aner livenessProbe akzeptéiert e Parameter initialDelaySeconds, déi d'Verifizéierungsoperatioun instruéiert fir eng spezifizéiert Zuel vu Sekonnen ze waarden. D'Verzögerung ass néideg well de Container Zäit brauch fir ze starten, a wann et nei gestart gëtt, ass et fir eng Zäit net verfügbar.

Fir dës Astellung op e Cluster z'applizéieren, benotzt:

kubectl apply -f pod.yaml

No e puer Sekonnen kënnt Dir den Inhalt vum Pod iwwerpréiwen mat dem folgenden Kommando:

kubectl describe pods node500

Um Enn vun der Ausgab fannt Dir dat ass dat.

Wéi Dir gesitt, huet livenessProbe eng HTTP GET Ufro initiéiert, de Container generéiert e Feeler 500 (wat ass programméiert fir ze maachen), an de Kubelet huet et nei gestart.

Wann Dir Iech frot wéi d'NideJS Applikatioun programméiert gouf, hei ass d'app.js an Dockerfile déi benotzt goufen:

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

Et ass wichteg dëst ze notéieren: livenessProbe wäert de Container nëmmen nei starten wann et klappt. Wann e Restart de Fehler net korrigéiert, deen de Container verhënnert aus ze lafen, kann de Kubelet keng Handlung ënnerhuelen fir de Problem ze korrigéieren.

Bereetschaft Probe

readinessProbe funktionnéiert ähnlech wéi livenessProbes (GET Ufroen, TCP Kommunikatiounen a Kommando Ausféierung), ausser fir Fehlerléisungsaktiounen. De Container, an deem de Feeler erkannt gëtt, gëtt net nei gestart, mee ass isoléiert vum Entréeën Traffic. Stellt Iech vir datt ee vun de Container vill Berechnungen ausféiert oder ënner schwéierer Belaaschtung ass, wat d'Äntwertzäite erhéicht. Am Fall vu LivenessProbe gëtt d'Äntwert Disponibilitéitskontroll ausgeléist (iwwer de TimeoutSeconds Check Parameter), no deem de Kubelet de Container nei start. Wann et gestart gëtt, fänkt de Container un Ressourceintensiv Aufgaben auszeféieren a gëtt erëm nei gestart. Dëst kann kritesch sinn fir Uwendungen déi Äntwertgeschwindegkeet brauchen. Zum Beispill, en Auto op der Strooss waart op eng Äntwert vum Server, d'Äntwert gëtt verspéit - an den Auto kënnt an en Accident.

Loosst eis eng RedinessProbe Definitioun schreiwen déi d'GET Ufro Äntwertzäit op net méi wéi zwou Sekonnen setzt, an d'Applikatioun äntwert op d'GET Ufro no 5 Sekonnen. D'pod.yaml Datei soll esou ausgesinn:

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

Loosst eis e Pod mat kubectl ofsetzen:

kubectl apply -f pod.yaml

Loosst eis e puer Sekonnen waarden a kucke wéi d'BereetschaftSonde geschafft huet:

kubectl describe pods nodedelayed

Um Enn vun der Ausgab kënnt Dir gesinn datt e puer vun den Eventer ähnlech sinn dëser.

Wéi Dir gesitt, huet kubectl de Pod net nei gestart wann d'Kontrollzäit 2 Sekonnen iwwerschratt ass. Amplaz huet hien d'Demande annuléiert. Entréeën Kommunikatiounen ginn op aner, schaffend Pods ëmgeleet.

Notéiert datt elo datt de Pod ofgelueden ass, kubectl fuert Ufroen nach eng Kéier drop: Äntwerten op GET Ufroe ginn net méi verspéit.

Zum Verglach, hei ënnen ass déi geännert app.js Datei:

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
Virun der Advent vu Cloud Uwendungen waren Logbicher de primäre Mëttel fir d'Applikatiounsgesondheet ze iwwerwaachen an ze kontrolléieren. Et waren awer keng Moyenen fir Korrektiounsmoossnamen ze huelen. Logbicher sinn haut nach nëtzlech si musse gesammelt an an e Log-Sammelsystem geschéckt ginn fir Noutsituatiounen ze analyséieren an Entscheedungen ze treffen. [All dëst kéint ouni Cloud Uwendungen gemaach ginn mat Monit, zum Beispill, awer mat k8s gouf et vill méi einfach :) - Redakter Notiz. ]

Haut musse Korrekturen bal an Echtzäit gemaach ginn, sou datt Uwendungen net méi schwaarz Këschte musse sinn. Nee, si sollten Endpunkte weisen, déi Iwwerwaachungssystemer erlaben, wäertvoll Donnéeën iwwer den Zoustand vun de Prozesser ze froen an ze sammelen, fir datt se direkt äntweren wann néideg. Dëst gëtt den Performance Test Design Pattern genannt, deen dem High Observability Principle (HOP) follegt.

Kubernetes bitt 2 Aarte vu Gesondheetschecken als Standard: ReadinessProbe a LivenessProbe. Béid benotzen déiselwecht Aarte vu Kontrollen (HTTP GET Ufroen, TCP Kommunikatiounen a Kommando Ausféierung). Si ënnerscheeden sech a wéi eng Entscheedunge si huelen als Äntwert op Probleemer an de Pods. livenessProbe restart de Container an der Hoffnung datt de Feeler net erëm wäert geschéien, a ReadinessProbe isoléiert de Pod vum erakommende Verkéier bis d'Ursaach vum Problem geléist ass.

De richtege Applikatiounsdesign soll béid Aarte vu Kontrollen enthalen a suergen datt se genuch Daten sammelen, besonnesch wann eng Ausnam geworf gëtt. Et sollt och déi néideg API Endpunkte weisen, déi dem Iwwerwaachungssystem (Prometheus) mat wichtege Gesondheetsmetriken ubidden.

Source: will.com