Slik angir du forskjellige retningslinjer for omstart av Kubernetes

Slik Angir Du Forskjellige Retningslinjer For Omstart Av Kubernetes



Vi vil snakke spesifikt om de ulike Kubernetes omstartspolicyer i denne artikkelen. La oss først diskutere de ulike policyene som brukes når Kubernetes må startes på nytt. Du kan bruke disse retningslinjene til å stoppe en viss arbeidsbelastning fra å bli distribuert i klyngen. Mens innføring av strenge standarder i klyngen vanligvis gjøres for å sikre samsvar, bør klyngeadministratorer også følge flere beste praksiser som er foreslått.

Hva er Kubernetes Restart Policy?

Hver Kubernetes-pod følger en bestemt livssyklus. Den begynner i «ventende»-stadiet, og hvis en eller flere av primærbeholderne ble lansert, går den over til «løpende»-stadiet. Avhengig av om beholderne i poden lykkes eller mislykkes, går prosessen videre til fasen 'vellykket' eller 'mislykket'.







For å starte policyen på nytt på nivået av beholderne som er brukt, kan tre alternativer brukes:



Alltid

Hver gang en container avsluttes, produserer Kubernetes en ny siden poden må være aktiv til enhver tid.



På Feil

Hvis beholderen går ut med en annen returkode enn 0, starter den bare på nytt én gang. Omstart er ikke nødvendig for containere som returnerer 0 (suksess).





Aldri

Beholderen kunne ikke starte på nytt.

Nå, i den følgende delen, vil vi diskutere hvordan du kan starte en pod på nytt.



Hvordan starte en pod på nytt i Kubernetes?

For å starte en Kubernetes-pod på nytt, utsted kommandoer ved hjelp av kubectl-verktøyet. Den vil koble til KubeAPI-serveren. La oss utforske de tilgjengelige alternativene:

Starte en container på nytt i en pod

En pod kan inneholde flere beholdere. På den annen side kobler du i hovedsak til den primære beholderen i en pod når du kobler til den. Du kan koble til hver beholder du har definert i en sak hvis du har definert mer enn én.

Nedenfor kan du se et eksempel på spesifikasjoner for pod for flere beholdere:


Dette beskriver et delt volum og to beholdere. HTML-filen vil bli servert av NGINX-beholderen og hvert sekund vil Ubuntu-beholderen legge til et datostempel til HTML-filen.

Siden du ikke spesifiserte hvilken beholder du skulle koble til, vil den automatisk velge den første (NGINX) når du prøver å koble til den poden. Skjermbildet er vedlagt nedenfor:


Du kan nå forsøke å avslutte PID 1-prosessen inne i den aktive beholderen. Kjør følgende kommandoer som root for å oppnå dette:


Du kan også bruke kubectl-verktøyet beskrevet nedenfor:


I følge pod-spesifikasjonen vil K8s nå forsøke å starte den ødelagte beholderen på nytt. For det brukes kommandoen 'beskriv' som følger:


Her er resultatet av kommandoen ovenfor:


Den nåværende tilstanden «går», mens den forrige tilstanden ble «avbrutt». Dette betyr at containeren ble startet på nytt, i følge dette. Imidlertid har ikke alle beholdere tilgang til rotlegitimasjon. Dette er grunnen til at denne metoden kanskje ikke er veldig nyttig.

Starte en pod på nytt ved å skalere

Å skalere en pods replikateller til 0 og deretter skalere den opp til 1 er den enkleste måten å starte den på nytt. Du må i stedet konstruere en distribusjon fordi skaleringskommandoen ikke kan brukes på pods. Her er en enkel måte å oppnå det på:


Skaler til 0 og deretter til 1 etter det. Ved å gjøre dette vil poden bli avsluttet og deretter distribuert til klyngen:


Replikaene er satt til 1 som du kan se på dette bildet.


For å se distribusjonsdetaljene har vi nå brukt 'kubectl get distribusjoner.' Følgende er en liste over både kommandoen og resultatet:

Starte en pod på nytt ved å slette den og distribuere den på nytt

Ved å bruke kommandoen 'kubectl delete' kan du slette en pod og deretter distribuere den på nytt. Denne tilnærmingen er imidlertid ganske forstyrrende, derfor anbefales den ikke.

Starte en pod på nytt ved hjelp av utrulling

For å starte en pod på nytt på den måten som er beskrevet ovenfor, må du enten ødelegge den eksisterende poden og deretter opprette en ny, eller skalere replikaten ned og deretter opp. Med Kubernetes versjon 1.15 kan du starte en distribusjon på nytt på en rullende måte. Dette er den foreslåtte prosedyren for å starte en pod på nytt. Bare skriv inn følgende kommando for å komme i gang:


Nå, hvis du holder et øye med distribusjonsstatusen på en annen terminal, vil du legge merke til flyten av hendelser som følger:


Hvis den er sunn, vil den skalere ned den forrige kopien av utplasseringen og spinne opp en ny kopi av poden. Resultatet er det samme, bortsett fra i denne tilnærmingen ble den underliggende orkestreringen håndtert av Kubernetes.

Hvordan kan Kubernetes Pods startes på nytt på forskjellige måter?

La oss først begynne med docker-containeren. Med følgende kommando kan Docker-beholdere startes på nytt:

> docker restart container_id

Men i Kubernetes er det ingen sammenlignbar kommando for å starte pods på nytt, spesielt hvis det ikke er noen spesifisert YAML-fil. Som et alternativ kan du starte Kubernetes pods på nytt ved å bruke kubectl-kommandoer. Følgende kommandoer er oppført:

Kommandoen Kubectl Set Env

En metode er å bruke kommandoen kubectl scale. Dette vil endre antall replikaer av poden som må startes på nytt. Nedenfor er en eksempelkommando for hvordan du setter replikaene i poden til å være to:

> kubectl skala distribusjon første utrulling --kopier = 2

Utrullingskommando omstart

Her vil vi demonstrere hvordan du bruker kommandoen utrulling omstart for å starte Kubernetes pods på nytt:

> kubectl utrulling start på nytt distribusjon første distribusjon -n demo-navneområde

Kontrolleren får beskjed om å utrydde hver pod individuelt ved kommandoen. Deretter skalerer den opp nye pods ved hjelp av ReplicaSet. Inntil hver ny pod er nyere enn hver gjeldende pod når kontrolleren gjenopptas, fortsetter denne prosessen.

Kommandoen Delete Pod

Denne delen vil gå over hvordan du bruker fjernkommandoen for å starte Kubernetes-pods på nytt. Du kan legge merke til at vi brukte neste kommando for å bli kvitt pod API-objektet i dette bildet:

. > kubectl slett pod første pod -n demo_namespace

Den forventede blir motsagt ved å slette pod-objektet fordi Kubernetes API er deklarativ. For å holde konsistensen med den forventede, er poden derfor gjenskapt.

Én pod kan startes på nytt om gangen ved å bruke den forrige kommandoen. Se den vedlagte kommandoen for å starte flere pods på nytt:

> kubectl slett replikasett pods-multiple-n demo_namespace

Den nevnte kommandoen starter hver pod på nytt ved å slette hele ReplicaSet av pods og deretter lage den fra bunnen av.

Konklusjon

Dette innlegget ga informasjon om de ulike retningslinjene for Kubernetes omstart. Vi illustrerte hvert trinn ved hjelp av eksempler. Prøv også disse kommandoene og se hvilken utgang de genererer.