Et vigtigt punkt i driften af distribuerede systemer er fejlhåndtering. Kubernetes hjælper med dette ved at bruge controllere, der overvåger dit systems tilstand og genstarter tjenester, der er holdt op med at virke. Kubernetes kan dog med kraft stoppe dine applikationer for at sikre overordnet systemsundhed. I denne serie vil vi se på, hvordan du kan hjælpe Kubernetes med at udføre sit arbejde mere effektivt og reducere nedetid for applikationer.
Før containere kørte de fleste applikationer på virtuelle eller fysiske maskiner. Hvis programmet gik ned eller frøs, tog det lang tid at annullere den igangværende opgave og genindlæse programmet. I værste fald måtte nogen løse dette problem manuelt om natten, på de mest uhensigtsmæssige timer. Hvis kun 1-2 arbejdende maskiner udførte en vigtig opgave, var en sådan forstyrrelse fuldstændig uacceptabel.
Derfor begyndte de i stedet for manuelle genstarter at bruge overvågning på procesniveau for automatisk at genstarte applikationen i tilfælde af en unormal afslutning. Hvis programmet fejler, fanger overvågningsprocessen exitkoden og genstarter serveren. Med fremkomsten af systemer som Kubernetes blev denne type reaktion på systemfejl simpelthen integreret i infrastrukturen.
Kubernetes bruger en observer-forskel-tag-handling hændelsesløkke for at sikre, at ressourcer forbliver sunde, når de rejser fra containere til selve noderne.
Det betyder, at du ikke længere behøver at køre procesovervågning manuelt. Hvis en ressource fejler i sundhedstjekket, vil Kubernetes simpelthen automatisk levere den med en erstatning. Kubernetes gør dog meget mere end blot at overvåge din applikation for fejl. Det kan oprette flere kopier af applikationen til at køre på flere maskiner, opdatere applikationen eller køre flere versioner af din applikation samtidigt.
Derfor er der mange grunde til, at Kubernetes kan afslutte en perfekt sund beholder. For eksempel, hvis du opgraderer din implementering, stopper Kubernetes langsomt gamle pods, mens du starter nye. Hvis du lukker en node ned, stopper Kubernetes med at køre alle pods på den node. Endelig, hvis en node løber tør for ressourcer, lukker Kubernetes alle pods for at frigøre disse ressourcer.
Derfor er det afgørende, at din applikation afsluttes med minimal indvirkning på slutbrugeren og minimal retableringstid. Det betyder, at den inden nedlukning skal gemme alle data, der skal gemmes, lukke alle netværksforbindelser, afslutte resterende arbejde og håndtere andre presserende opgaver.
I praksis betyder det, at din applikation skal kunne håndtere SIGTERM-meddelelsen, procestermineringssignalet, der er standardsignalet for kill-værktøjet på Unix-operativsystemer. Når denne meddelelse er modtaget, bør applikationen lukkes ned.
Når Kubernetes beslutter sig for at afslutte en pod, sker der en række hændelser. Lad os se på hvert trin, Kubernetes tager, når de lukker en beholder eller pod ned.
Lad os sige, at vi ønsker at afslutte en af pods. På dette tidspunkt vil den stoppe med at modtage ny trafik - containere, der kører i poden, vil ikke blive påvirket, men al ny trafik vil blive blokeret.
Lad os se på preStop-krogen, som er en speciel kommando eller HTTP-anmodning, der sendes til containere i en pod. Hvis din applikation ikke lukker korrekt ned, når du modtager SIGTERM, kan du bruge preStop til at lukke ned korrekt.
De fleste programmer afsluttes elegant, når de modtager et SIGTERM-signal, men hvis du bruger tredjepartskode eller et eller andet system, som du ikke har fuld kontrol over, er preStop-krogen en fantastisk måde at tvinge en yndefuld nedlukning på uden at ændre applikationen.
Efter at have udført denne hook, sender Kubernetes et SIGTERM-signal til beholderne i poden, der fortæller dem, at de snart vil blive afbrudt. Når du har modtaget dette signal, vil din kode fortsætte til nedlukningsprocessen. Denne proces kan omfatte stop af langvarige forbindelser, såsom en databaseforbindelse eller WebSocket-stream, lagring af den aktuelle tilstand og lignende.
Selvom du bruger en preStop hook, er det meget vigtigt at tjekke, hvad der præcist sker med din applikation, når du sender den et SIGTERM-signal, og hvordan den opfører sig, så hændelser eller ændringer i systemdriften forårsaget af en pod-nedlukning ikke kommer som en overraskelse til dig.
På dette tidspunkt vil Kubernetes vente i et specificeret tidsrum, kaldet terminationGracePeriodSecond, eller perioden med yndefuld nedlukning, når den modtager et SIGTERM-signal, før der foretages yderligere handling.
Som standard er denne periode 30 sekunder. Det er vigtigt at bemærke, at den kører parallelt med preStop-krogen og SIGTERM-signalet. Kubernetes vil ikke vente på, at preStop-hook og SIGTERM slutter – hvis din applikation afsluttes, før TerminationGracePeriod slutter, vil Kubernetes straks gå videre til næste trin. Kontroller derfor, at værdien af denne periode i sekunder ikke er mindre end den tid, der kræves for at lukke poden korrekt ned, og hvis den overstiger 30s, øges perioden til den ønskede værdi i YAML. I det givne eksempel er det 60'erne.
Og endelig er det sidste trin, hvis containere stadig kører efter termineringGracePeriod, vil de sende et SIGKILL-signal og blive tvangsslettet. På dette tidspunkt vil Kubernetes også rydde op i alle andre pod-objekter.
Kubernetes afslutter pods af mange årsager, så sørg for, at din applikation afsluttes elegant under alle omstændigheder for at sikre en stabil service.
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com