Opgradering af en Kubernetes-klynge uden nedetid

Opgraderingsproces for din Kubernetes-klynge

På et tidspunkt, når du bruger en Kubernetes-klynge, er der behov for at opdatere kørende noder. Dette kan omfatte pakkeopdateringer, kerneopdateringer eller implementering af nye virtuelle maskinbilleder. I Kubernetes terminologi kaldes dette "Frivillig afbrydelse".

Dette indlæg er en del af en serie med 4 indlæg:

1. Dette indlæg.
2. Korrekt nedlukning af pods i en Kubernetes-klynge
3. Forsinket afslutning af en pod, når den slettes
4. Sådan undgår du Kubernetes Cluster Downtime ved hjælp af PodDisruptionBudgets

(ca. Forvent oversættelser af de resterende artikler i serien i nær fremtid)

I denne artikel vil vi beskrive alle de værktøjer, som Kubernetes leverer for at opnå nul nedetid for de noder, der kører i din klynge.

Problemdefinition

Vi vil først tage en naiv tilgang, identificere problemer og vurdere de potentielle risici ved denne tilgang og opbygge viden til at løse hvert af de problemer, vi støder på gennem hele cyklussen. Resultatet er en konfiguration, der bruger livscykluskroge, parathedsprober og Pod-afbrydelsesbudgetter for at nå vores mål om nul nedetid.

For at starte vores rejse, lad os tage et konkret eksempel. Lad os sige, at vi har en Kubernetes-klynge med to noder, hvor en applikation kører med to pods placeret bagved Service:

Lad os starte med to pods med Nginx og Service, der kører på vores to Kubernetes-klyndeknuder.

Vi ønsker at opdatere kerneversionen af ​​to arbejdernoder i vores klynge. Hvordan gør vi dette? En simpel løsning ville være at starte nye noder med den opdaterede konfiguration og derefter lukke de gamle noder ned, mens du starter de nye. Selvom dette vil fungere, vil der være et par problemer med denne tilgang:

• Når du slår gamle noder fra, vil de pods, der kører på dem, også blive slukket. Hvad hvis bælgerne skal ryddes for yndefuld nedlukning? Det virtualiseringssystem, du bruger, venter muligvis ikke på, at oprydningsprocessen er fuldført.
• Hvad hvis du slår alle noder fra på samme tid? Du vil få anstændig nedetid, mens pods flytter til nye noder.

Vi har brug for en måde, hvorpå vi elegant kan migrere pods fra gamle noder, samtidig med at vi sikrer, at ingen af ​​vores arbejdsprocesser kører, mens vi foretager ændringer i noden. Eller når vi laver en fuldstændig udskiftning af klyngen, som i eksemplet (det vil sige, vi erstatter VM-billeder), vil vi overføre kørende applikationer fra gamle noder til nye. I begge tilfælde ønsker vi at forhindre nye pods i at planlægge på gamle noder og derefter fjerne alle kørende pods fra dem. For at nå disse mål kan vi bruge kommandoen kubectl drain.

Omfordeling af alle pods fra en node

Drænoperationen giver dig mulighed for at omfordele alle pods fra en node. Under udførelse af dræning markeres knudepunktet som ikke-planlagt (flag NoSchedule). Dette forhindrer nye pods i at blive vist på den. Derefter begynder drænet at uddrive bælgerne fra noden, lukker de beholdere, der i øjeblikket kører på noden, og sender et signal TERM beholdere i en bælg.

Skønt kubectl drain vil gøre et godt stykke arbejde med at smide bælgerne ud, er der to andre faktorer, der kan få afløbsoperationen til at mislykkes:

• Din ansøgning skal kunne afsluttes med ynde ved indsendelse TERM signal. Når pods bliver smidt ud, sender Kubernetes et signal TERM containere og venter på, at de stopper i et bestemt tidsrum, hvorefter det, hvis de ikke er stoppet, tvangsmæssigt afslutter dem. Under alle omstændigheder, hvis din container ikke opfatter signalet korrekt, kan du stadig slukke pods forkert, hvis de kører i øjeblikket (f.eks. er en databasetransaktion i gang).
• Du mister alle de pods, der indeholder din applikation. Det er muligvis ikke tilgængeligt, når nye containere lanceres på nye noder, eller hvis dine pods er implementeret uden controllere, genstarter de muligvis slet ikke.

Undgå nedetid

For at minimere nedetid fra frivillig afbrydelse, såsom fra en drænoperation på en knude, tilbyder Kubernetes følgende fejlhåndteringsmuligheder:

• Yndefuld afslutning
• Livscyklus kroge
• PodDisruptionBudgets

I resten af ​​serien vil vi bruge disse Kubernetes-funktioner til at afbøde virkningen af ​​pod-migrering. For at gøre det nemmere at følge hovedideen, vil vi bruge vores eksempel ovenfor med følgende ressourcekonfiguration:

---
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 konfiguration er et minimalt eksempel Deployment, som administrerer nginx pods i klyngen. Derudover beskriver konfigurationen ressourcen Service, som kan bruges til at få adgang til nginx pods i en klynge.

Gennem hele cyklussen vil vi iterativt udvide denne konfiguration, så den i sidste ende omfatter alle de muligheder Kubernetes giver for at reducere nedetid.

For en fuldt implementeret og testet version af Kubernetes klyngeopdateringer til nul nedetid på AWS og videre, besøg Gruntwork.io.

Læs også andre artikler på vores blog:

• Nul nedetidsimplementering og databaser
• Kubernetes: hvorfor er det så vigtigt at konfigurere systemressourcestyring?
• Tekton Pipeline - Kubernetes-native pipelines
• Opbygning af dynamiske moduler til Nginx
• Introduktion til Hashicorp Consuls Kubernetes-autorisation
• Hvad førte migreringen fra ClickHouse uden autorisation til ClickHouse med autorisation til?

Kilde: www.habr.com