Et viktig poeng i driften av distribuerte systemer er feilhåndtering. Kubernetes hjelper med dette ved å bruke kontrollere som overvåker helsen til systemet ditt og starter på nytt tjenester som har sluttet å fungere. Kubernetes kan imidlertid stoppe applikasjonene dine med kraft for å sikre generell systemhelse. I denne serien skal vi se på hvordan du kan hjelpe Kubernetes med å gjøre jobben sin mer effektivt og redusere nedetid for applikasjoner.
Før containere kjørte de fleste applikasjoner på virtuelle eller fysiske maskiner. Hvis applikasjonen krasjet eller frøs, tok det lang tid å avbryte oppgaven som pågår og laste programmet på nytt. I verste fall måtte noen løse dette problemet manuelt om natten, på de mest uleilige timene. Hvis bare 1-2 arbeidsmaskiner utførte en viktig oppgave, var en slik forstyrrelse helt uakseptabel.
Derfor, i stedet for manuelle omstarter, begynte de å bruke overvåking på prosessnivå for automatisk å starte applikasjonen på nytt i tilfelle en unormal avslutning. Hvis programmet mislykkes, fanger overvåkingsprosessen opp utgangskoden og starter serveren på nytt. Med bruken av systemer som Kubernetes ble denne typen respons på systemfeil ganske enkelt integrert i infrastrukturen.
Kubernetes bruker en observer-forskjell-tak-handling-hendelsesløkke for å sikre at ressursene forblir sunne når de reiser fra containere til selve nodene.
Dette betyr at du ikke lenger trenger å kjøre prosessovervåking manuelt. Hvis en ressurs mislykkes i helsesjekken, vil Kubernetes ganske enkelt automatisk utstyre den med en erstatning. Kubernetes gjør imidlertid mye mer enn bare å overvåke applikasjonen din for feil. Den kan lage flere kopier av applikasjonen for å kjøre på flere maskiner, oppdatere applikasjonen eller kjøre flere versjoner av applikasjonen samtidig.
Derfor er det mange grunner til at Kubernetes kan avslutte en perfekt sunn beholder. For eksempel, hvis du oppgraderer distribusjonen din, vil Kubernetes sakte stoppe gamle pods mens du starter nye. Hvis du slår av en node, vil Kubernetes slutte å kjøre alle pods på den noden. Til slutt, hvis en node går tom for ressurser, vil Kubernetes slå av alle pods for å frigjøre disse ressursene.
Derfor er det avgjørende at applikasjonen din avsluttes med minimal innvirkning på sluttbrukeren og minimal gjenopprettingstid. Dette betyr at før den slås av, må den lagre alle data som må lagres, lukke alle nettverkstilkoblinger, fullføre gjenværende arbeid og håndtere andre presserende oppgaver.
I praksis betyr dette at applikasjonen din må kunne håndtere SIGTERM-meldingen, prosessavslutningssignalet som er standardsignalet for kill-verktøyet på Unix-operativsystemer. Når du mottar denne meldingen, bør applikasjonen avsluttes.
Når Kubernetes bestemmer seg for å avslutte en pod, skjer en rekke hendelser. La oss se på hvert trinn som Kubernetes tar når du slår av en beholder eller pod.
La oss si at vi ønsker å avslutte en av podene. På dette tidspunktet vil den slutte å motta ny trafikk - containere som kjører i poden vil ikke bli påvirket, men all ny trafikk vil bli blokkert.
La oss se på preStop-kroken, som er en spesiell kommando eller HTTP-forespørsel som sendes til containere i en pod. Hvis applikasjonen din ikke slår seg av på riktig måte når du mottar SIGTERM, kan du bruke preStop for å slå av på riktig måte.
De fleste programmer avsluttes elegant når de mottar et SIGTERM-signal, men hvis du bruker tredjepartskode eller et system som du ikke kontrollerer fullt ut, er preStop-kroken en fin måte å tvinge frem en grasiøs avslutning uten å endre applikasjonen.
Etter å ha utført denne kroken, vil Kubernetes sende et SIGTERM-signal til beholderne i poden, og fortelle dem at de snart vil bli frakoblet. Når du mottar dette signalet, vil koden din fortsette til avslutningsprosessen. Denne prosessen kan inkludere stopp av langvarige tilkoblinger som en databasetilkobling eller WebSocket-strøm, lagring av gjeldende tilstand og lignende.
Selv om du bruker en preStop-krok, er det svært viktig å sjekke hva som skjer med applikasjonen din når du sender den et SIGTERM-signal, og hvordan den oppfører seg, slik at hendelser eller endringer i systemdrift forårsaket av en pod-avstenging ikke kommer som en overraskelse til deg.
På dette tidspunktet vil Kubernetes vente i en spesifisert tidsperiode, kalt terminationGracePeriodSecond, eller perioden for elegant avslutning når den mottar et SIGTERM-signal, før de tar ytterligere handling.
Som standard er denne perioden 30 sekunder. Det er viktig å merke seg at den går parallelt med preStop-kroken og SIGTERM-signalet. Kubernetes vil ikke vente på at preStop-kroken og SIGTERM skal avsluttes – hvis applikasjonen din avsluttes før TerminationGracePeriod slutter, vil Kubernetes umiddelbart gå videre til neste trinn. Kontroller derfor at verdien av denne perioden i sekunder ikke er mindre enn tiden som kreves for å slå av poden på riktig måte, og hvis den overstiger 30 sekunder, øk perioden til ønsket verdi i YAML. I eksemplet er det 60-tallet.
Og til slutt, det siste trinnet er at hvis containere fortsatt kjører etter termineringGracePeriod, vil de sende et SIGKILL-signal og bli tvangsslettet. På dette tidspunktet vil Kubernetes også rydde opp i alle andre pod-objekter.
Kubernetes avslutter pods av mange grunner, så sørg for at applikasjonen din avsluttes grasiøst i alle fall for å sikre en stabil tjeneste.
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com