En viktig punkt i driften av distribuerade system är felhantering. Kubernetes hjälper till med detta genom att använda kontroller som övervakar ditt systems tillstånd och startar om tjänster som har slutat fungera. Kubernetes kan dock med kraft stoppa dina applikationer för att säkerställa systemets övergripande hälsa. I den här serien kommer vi att titta på hur du kan hjälpa Kubernetes att göra sitt jobb mer effektivt och minska applikationens stilleståndstid.
Innan behållare kördes de flesta applikationer på virtuella eller fysiska maskiner. Om applikationen kraschade eller frös tog det lång tid att avbryta den pågående uppgiften och ladda om programmet. I värsta fall var någon tvungen att lösa detta problem manuellt på natten, vid de mest olämpliga timmarna. Om bara 1-2 arbetande maskiner utförde en viktig uppgift, var en sådan störning helt oacceptabel.
Istället för manuella omstarter började de därför använda övervakning på processnivå för att automatiskt starta om programmet i händelse av en onormal avslutning. Om programmet misslyckas, fångar övervakningsprocessen utgångskoden och startar om servern. Med tillkomsten av system som Kubernetes, integrerades den här typen av svar på systemfel helt enkelt i infrastrukturen.
Kubernetes använder en observera-skillnad-tag-åtgärd-händelsslinga för att säkerställa att resurserna förblir sunda när de reser från containrar till själva noderna.
Detta innebär att du inte längre behöver köra processövervakning manuellt. Om en resurs misslyckas med hälsokontrollen kommer Kubernetes helt enkelt automatiskt att tillhandahålla den med en ersättning. Kubernetes gör dock mycket mer än att bara övervaka din applikation efter misslyckanden. Det kan skapa fler kopior av programmet för att köras på flera maskiner, uppdatera programmet eller köra flera versioner av ditt program samtidigt.
Därför finns det många anledningar till varför Kubernetes kan avsluta en helt hälsosam behållare. Om du till exempel uppgraderar din distribution kommer Kubernetes långsamt att stoppa gamla pods medan du startar nya. Om du stänger av en nod kommer Kubernetes att sluta köra alla poddar på den noden. Slutligen, om en nod får slut på resurser, kommer Kubernetes att stänga av alla poddar för att frigöra dessa resurser.
Därför är det viktigt att din applikation avslutas med minimal påverkan på slutanvändaren och minimal återställningstid. Det betyder att innan den stängs av måste den spara all data som behöver sparas, stänga alla nätverksanslutningar, slutföra återstående arbete och hantera andra brådskande uppgifter.
I praktiken betyder detta att din applikation måste kunna hantera SIGTERM-meddelandet, processtermineringssignalen som är standardsignalen för kill-verktyget på Unix-operativsystem. När du får detta meddelande bör programmet stängas av.
När Kubernetes bestämmer sig för att avsluta en pod inträffar ett antal händelser. Låt oss titta på varje steg som Kubernetes tar när man stänger av en behållare eller pod.
Låt oss säga att vi vill avsluta en av poddarna. Vid det här laget kommer den att sluta ta emot ny trafik - containrar som körs i podden kommer inte att påverkas, men all ny trafik kommer att blockeras.
Låt oss titta på preStop-kroken, som är ett speciellt kommando eller HTTP-förfrågan som skickas till behållare i en pod. Om din applikation inte stängs av korrekt när du tar emot SIGTERM, kan du använda preStop för att stänga av korrekt.
De flesta program avslutas graciöst när de tar emot en SIGTERM-signal, men om du använder tredjepartskod eller något system som du inte helt kontrollerar, är preStop-kroken ett utmärkt sätt att tvinga fram en graciös avstängning utan att ändra applikationen.
Efter att ha utfört den här kroken kommer Kubernetes att skicka en SIGTERM-signal till behållarna i podden, som låter dem veta att de snart kommer att kopplas bort. När du tar emot denna signal fortsätter din kod till avstängningsprocessen. Denna process kan innefatta att stoppa långlivade anslutningar som en databasanslutning eller WebSocket-ström, spara det aktuella tillståndet och liknande.
Även om du använder en preStop-krok är det mycket viktigt att kontrollera exakt vad som händer med din applikation när du skickar en SIGTERM-signal till den och hur den beter sig, så att händelser eller förändringar i systemdriften orsakade av en podavstängning inte inträffar som en överraskning för dig.
Vid denna tidpunkt kommer Kubernetes att vänta i en specificerad tid, kallad terminationGracePeriodSecond, eller perioden för att graciöst stängas av när den tar emot en SIGTERM-signal, innan den vidtar ytterligare åtgärder.
Som standard är denna period 30 sekunder. Det är viktigt att notera att den går parallellt med preStop-kroken och SIGTERM-signalen. Kubernetes väntar inte på att preStop-haken och SIGTERM ska avslutas – om din applikation avslutas innan TerminationGracePeriod tar slut, kommer Kubernetes omedelbart att gå vidare till nästa steg. Kontrollera därför att värdet för denna period i sekunder inte är mindre än den tid som krävs för att stänga av podden korrekt, och om den överstiger 30s, öka perioden till önskat värde i YAML. I exemplet är det 60-tal.
Och slutligen, det sista steget är om containrar fortfarande körs efter avslutad GracePeriod, kommer de att skicka en SIGKILL-signal och kommer att tvångsraderas. Vid det här laget kommer Kubernetes också att rensa upp alla andra podobjekt.
Kubernetes avslutar pods av många anledningar, så se till att din applikation avslutas på ett elegant sätt i alla fall för att säkerställa en stabil tjänst.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com