Oppgradering av en Kubernetes-klynge uten nedetid

Oppgraderingsprosess for Kubernetes-klyngen din

På et tidspunkt, når du bruker en Kubernetes-klynge, er det behov for å oppdatere kjørende noder. Dette kan inkludere pakkeoppdateringer, kjerneoppdateringer eller distribusjon av nye virtuelle maskinbilder. I Kubernetes terminologi kalles dette "Frivillig avbrudd".

Dette innlegget er en del av en serie med 4 innlegg:

1. Denne posten.
2. Riktig avslutning av pods i en Kubernetes-klynge
3. Forsinket avslutning av en pod når den slettes
4. Slik unngår du Kubernetes Cluster Nedetid ved å bruke PodDisruptionBudgets

(ca. Forvent oversettelser av de resterende artiklene i serien i nær fremtid)

I denne artikkelen vil vi beskrive alle verktøyene som Kubernetes gir for å oppnå null nedetid for nodene som kjører i klyngen din.

Definere problemet

Vi vil først ta en naiv tilnærming, identifisere problemer og vurdere de potensielle risikoene ved denne tilnærmingen, og bygge kunnskap for å løse hvert av problemene vi møter gjennom syklusen. Resultatet er en konfigurasjon som bruker livssykluskroker, beredskapsprober og Pod-avbruddsbudsjetter for å nå vårt null nedetidsmål.

For å starte reisen vår, la oss ta et konkret eksempel. La oss si at vi har en Kubernetes-klynge med to noder, der en applikasjon kjører med to poder plassert bak Service:

La oss starte med to pods med Nginx og Service som kjører på våre to Kubernetes-klyngenoder.

Vi ønsker å oppdatere kjerneversjonen av to arbeidernoder i klyngen vår. Hvordan gjør vi dette? En enkel løsning ville være å starte opp nye noder med den oppdaterte konfigurasjonen og deretter slå av de gamle nodene mens du starter de nye. Selv om dette vil fungere, vil det være noen problemer med denne tilnærmingen:

• Når du slår av gamle noder, vil podene som kjører på dem også bli slått av. Hva om podene må ryddes for grasiøs nedleggelse? Virtualiseringssystemet du bruker vil kanskje ikke vente til oppryddingsprosessen er fullført.
• Hva om du slår av alle noder samtidig? Du vil få anstendig nedetid mens podene flytter til nye noder.

Vi trenger en måte å elegant migrere pods fra gamle noder, samtidig som vi sikrer at ingen av arbeidsprosessene våre kjører mens vi gjør endringer i noden. Eller når vi gjør en fullstendig utskifting av klyngen, som i eksemplet (det vil si at vi erstatter VM-bilder), ønsker vi å overføre kjørende applikasjoner fra gamle noder til nye. I begge tilfeller ønsker vi å hindre nye pods fra å planlegge på gamle noder, og deretter kaste ut alle kjørende pods fra dem. For å oppnå disse målene kan vi bruke kommandoen kubectl drain.

Omfordele alle pods fra en node

Dreneringsoperasjonen lar deg omfordele alle pods fra en node. Under utføring av drenering er noden merket som ikke-planlagt (flagg NoSchedule). Dette forhindrer at nye pods vises på den. Deretter begynner drenering å kaste ut pods fra noden, slår av beholderne som for øyeblikket kjører på noden, og sender et signal TERM beholdere i en belg.

Selv kubectl drain vil gjøre en god jobb med å kaste ut pods, er det to andre faktorer som kan føre til at dreneringsoperasjonen mislykkes:

• Søknaden din må kunne avsluttes elegant ved innsending TERM signal. Når pods blir kastet ut, sender Kubernetes et signal TERM containere og venter på at de skal stoppe i en spesifisert tidsperiode, hvoretter den, hvis de ikke har stoppet, avslutter dem med makt. Uansett, hvis beholderen din ikke oppfatter signalet riktig, kan du fortsatt slukke pods feil hvis de kjører for øyeblikket (for eksempel en databasetransaksjon pågår).
• Du mister alle podene som inneholder applikasjonen din. Den er kanskje ikke tilgjengelig når nye beholdere lanseres på nye noder, eller hvis podene dine er distribuert uten kontrollere, kan det hende at de ikke starter på nytt i det hele tatt.

Unngå nedetid

For å minimere nedetid fra frivillig avbrudd, for eksempel fra en dreneringsoperasjon på en node, tilbyr Kubernetes følgende feilhåndteringsalternativer:

• Grasiøs avslutning
• Livssykluskroker
• PodDisruptionBudgets

I resten av serien vil vi bruke disse Kubernetes-funksjonene for å dempe virkningen av pod-migrering. For å gjøre det lettere å følge hovedideen, vil vi bruke eksemplet ovenfor med følgende ressurskonfigurasjon:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Denne konfigurasjonen er et minimalt eksempel Deployment, som administrerer nginx-pods i klyngen. I tillegg beskriver konfigurasjonen ressursen Service, som kan brukes til å få tilgang til nginx-poder i en klynge.

Gjennom hele syklusen vil vi iterativt utvide denne konfigurasjonen slik at den til slutt inkluderer alle mulighetene Kubernetes gir for å redusere nedetid.

For en fullt implementert og testet versjon av Kubernetes klyngeoppdateringer for null nedetid på AWS og utover, besøk Gruntwork.io.

Les også andre artikler på bloggen vår:

• Null nedetidsdistribusjon og databaser
• Kubernetes: hvorfor er det så viktig å konfigurere systemressursadministrasjon?
• Tekton Pipeline - Kubernetes-native pipelines
• Bygge dynamiske moduler for Nginx
• Introduksjon til Hashicorp Consuls Kubernetes-autorisasjon
• Hva førte migreringen fra ClickHouse uten autorisasjon til ClickHouse med autorisasjon?

Kilde: www.habr.com