Bästa praxis för Kubernetes. Korrekt nedstängning Terminate

Bästa praxis för Kubernetes. Skapa små containrar
Bästa praxis för Kubernetes. Organisera Kubernetes med namnrymder
Bästa praxis för Kubernetes. Kontroll av Kubernetes livskraft med hjälp av Readiness- och Liveness-tester
Bästa praxis för Kubernetes. Inställning av begärningar och resursbegränsningar

En viktig aspekt av distribuerade system är hanteringen av fel. Kubernetes hjälper till med detta genom att använda kontroller som övervakar tillståndet hos ditt system och startar om nedlagda tjänster. Men Kubernetes kan tvångsstänga dina applikationer för att säkerställa systemets övergripande livskraft. I den här serien kommer vi att se hur man kan hjälpa Kubernetes att utföra sitt arbete mer effektivt och minska driftstopp för applikationer.

Innan användningen av containrar körde de flesta applikationer på virtuella eller fysiska maskiner. Om en applikation kraschade eller frös tog det lång tid att avbryta den pågående uppgiften och ladda om programmet. I värsta fall fick någon lösa problemet manuellt mitt i natten, vid mest olämplig tid. Om en viktig uppgift utfördes av endast 1-2 arbetsmaskiner var en sådan krasch helt oacceptabel.
Därför började man använda processövervakning för automatisk omstart av applikationen vid krasch istället för manuell omstart. Om programmet kraschar fångar övervakningsprocessen exit-koden och startar om servern. Med system som Kubernetes har denna typ av respons på systemfel enkelt integrerats i infrastrukturen.

Kubernetes använder en händelseloop av 'övervakning – registrering av skillnader – åtgärd' för att säkerställa att resurser förblir operativa på vägen från containrar till själva noderna.

Detta innebär att du inte längre behöver manuellt starta processövervakning. Om en resurs inte klarar av Health Check kontrollerar Kubernetes helt enkelt automatiskt och ger den en ersättning. Samtidigt gör Kubernetes mycket mer än bara att övervaka dina applikationer för fel. Det kan skapa fler kopior av applikationen för att köras på flera maskiner, uppdatera applikationen, eller köra flera versioner av din applikation samtidigt.
Det finns därför många anledningar till att Kubernetes kan avbryta en helt frisk container. Till exempel, om du uppdaterar din distribution kommer Kubernetes långsamt att stoppa gamla pods samtidigt som nya startas. Om du stänger av en nod kommer Kubernetes att stoppa alla pods i den noden. Slutligen, om en nod får slut på resurser, kommer Kubernetes att stänga av alla pods för att frigöra dessa resurser.

Det är därför mycket viktigt att din applikation stänger ner med minimal påverkan på slutanvändaren och minimal återställningstid. Det innebär att innan avstängningen bör den spara all data som behöver sparas, stänga alla nätverksanslutningar, slutföra kvarvarande arbete och se till att andra brådskande uppgifter utförs.

I praktiken innebär detta att din applikation måste kunna hantera signalen SIGTERM – en processavslutningssignal som är standard för kill-verktyget i Unix-liknande operativsystem. När applikationen tar emot detta meddelande ska den avslutas.

När Kubernetes har beslutat att avsluta en pod inträffar en rad händelser. Låt oss gå igenom varje steg som Kubernetes tar vid nedstängning av en container eller pod.

Anta att vi vill avsluta en av pods. Vid denna tidpunkt kommer den att sluta ta emot ny trafik – de körande containrarna i podden kommer inte att påverkas, men all ny trafik kommer att blockeras.

Låt oss ta en titt på preStop-hooken – detta är ett specialkommando eller HTTP-förfrågan som skickas till containrarna i en pod. Om din applikation inte stänger av korrekt vid mottagandet av SIGTERM kan du använda preStop för en korrekt avstängning.

De flesta program avslutar sin verksamhet korrekt när de får SIGTERM-signalen, men om du använder tredje parts kod eller något system som du inte helt kan kontrollera, är preStop-hooken ett utmärkt sätt att åstadkomma en smidig avstängning utan att ändra applikationen.

Efter att denna hook har körts kommer Kubernetes att skicka en SIGTERM-signal till containrarna i podden, vilket meddelar dem att de snart kommer att stängas av. När de får denna signal kommer din kod att övergå till avstängningsprocessen. Denna process kan inkludera att stänga av eventuella långlivade anslutningar, såsom en databasanslutning eller WebSocket-ström, spara det aktuella tillståndet och liknande.

Även om du använder preStop-hucken är det mycket viktigt att kontrollera vad som händer med din applikation när du skickar den en SIGTERM-signal, hur den beter sig, så att händelser eller förändringar i systemets drift orsakade av nedstängningen av podden inte kommer som en överraskning för dig.

Vid denna tidpunkt, innan några ytterligare åtgärder vidtas, kommer Kubernetes att vänta under en angiven tid, kallad terminationGracePeriodSecond, eller perioden för korrekt avstängning vid mottagandet av SIGTERM-signalen.

Som standard är denna period 30 sekunder. Det är viktigt att notera att den pågår parallellt med preStop-hucken och SIGTERM-signalen. Kubernetes kommer inte att vänta på att preStop-hucken och SIGTERM slutförs — om din applikation avslutar sig innan terminationGracePeriod har löpt ut, går Kubernetes omedelbart vidare till nästa steg. Kontrollera därför att värdet på denna period i sekunder inte är mindre än den tid som krävs för en korrekt avstängning av podden, och om det överstiger 30 sekunder, öka perioden till önskad längd i YAML. I det angivna exemplet är det 60 sekunder.

Och slutligen, det sista steget — om containrarna fortfarande körs efter att terminationGracePeriod har löpt ut, kommer de att skicka en SIGKILL-signal och bli tvingat borttagna. Vid denna tidpunkt kommer Kubernetes också att rensa ut alla andra objekt i podden.

Kubernetes stänger av poddar av många skäl, så se till att ditt program avslutas korrekt under alla omständigheter för att säkerställa att tjänsten fortsätter att fungera stabilt.

Bästa praxis för Kubernetes. Kartläggning av externa tjänster

Lite reklam 🙂

Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, moln-VPS för utvecklare från $4,99, en unik motsvarighet till entry-level servrar som vi har skapat för er: Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur man korrekt delar en server? (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).

Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB från $199 i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om Hur man bygger en företagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro för en bråkdel?

Källa: habr.com