🥇Posodobitev Kubernetes grozda brez nedelovanja

Postopek posodabljanja za vaš klaster Kubernetes

Občasno se pri uporabi klustra Kubernetes pojavi potreba po posodobitvi delujočih vozlišč. To lahko vključuje posodobitve paketov, posodobitev jedra ali uvajanje novih slik virtualnih strojev. V terminologiji Kubernetes se to imenuje "Prostovoljna prekinitev".

Ta objava je del cikla štirih objav:

Ta objava.
Pravilno zaključitev podov v klasterju Kubernetes
Odložitev zaključitev poda ob njegovi odstranitvi
Kako se izogniti stanju nedelovanja klasterja Kubernetes s pomočjo PodDisruptionBudgets

(op. prev. prevode ostalih člankov cikla pričakujte kmalu)

V tem članku bomo opisali vse orodje, ki jih Kubernetes nudi za dosego ničelnega časa nedelovanja za delujoča vozlišča v vašem klasterju.

Opredelitev problema

Sprva bomo uporabili naiven pristop, opredeliti probleme in oceniti morebitna tveganja tega pristopa ter pridobiti znanje za reševanje vsakega od problemov, s katerimi se bomo srečali v celotnem ciklu. Tako bomo dobili konfiguracijo, ki uporablja lifecycle hooks, readiness probes in Pod disruption budgets za dosego našega ničelnega časa nedelovanja.

Da začnemo našo pot, vzemimo konkretni primer. Recimo, da imamo klaster Kubernetes s dvema vozlišči, v katerem deluje aplikacija z dvema podoma, ki se nahajata za Storitev:

Začeli bomo z dvema podoma z Nginx-om in storitvijo, ki delujeta na naših dveh vozliščih klasterja Kubernetes.

Želimo posodobiti verzijo jedra dveh delovnih vozlišč v našem klasterju. Kako to storiti? Enostavna rešitev bi bila, da naložimo nova vozlišča z posodobljeno konfiguracijo in nato izklopimo stara vozlišča, hkrati pa zagnamo nova. Čeprav to deluje, bo pri takem pristopu več težav:

Ko izklopite stara vozlišča, bodo vsi podi, ki delujejo na njih, prav tako izklopljeni. Kaj pa, če je treba podpore očistiti za pravilno izklop? Virtualizacijski sistem, ki ga uporabljate, morda ne bo počakal na dokončanje postopka čiščenja.
Kaj pa, če izklopite vsa vozlišča hkrati? Opravljali boste precejšnje nedelovanje, medtem ko se podi preselijo na nova vozlišča.

Potrebujemo način za pravilno migracijo podov s starih vozlišč in biti moramo prepričani, da noben od naših delovnih procesov ni zagnan, medtem ko uvajamo spremembe na vozlišču. Ali ko izvajamo popolno zamenjavo grozda, kot v zgoraj navedenem primeru (tj. zamenjamo slike VM), želimo preneseti delujoče aplikacije s starih vozlišč na nova. V obeh primerih želimo preprečiti načrtovanje novih podov na starih vozliščih in nato izgnati vse zagnane pode. Za dosego teh ciljev lahko uporabimo ukaz kubectl drain.

Preusmeritev vseh podov z vozlišča

Operacija drain omogoča preusmeritev vseh podov z vozlišča. Med izvajanjem drain je vozlišče označeno kot unschedulable (znamka NoSchedule). To preprečuje, da bi se na njem pojavili novi podi. Nato drain začne izgnati pode z vozlišča, konča z delovanjem kontejnerjev, ki so trenutno zagnani na vozlišču z pošiljanjem signala TERM kontejnerjem v podu.

Čeprav kubectl drain Čeprav odlično upravlja z izganjanjem podov, obstajata še dva dejavnika, ki lahko povzročita neuspeh pri izvajanju operacije drain:

Vaša aplikacija mora znati pravilno končati ob prejemu TERM signala. Ko se podi izganjajo, Kubernetes pošlje signal TERM kontejnerjem in čaka, da se ustavijo določeno količino časa, po kateri, če se niso ustavili, jih prisilno konča. V vsakem primeru, če vaš kontejner signala ne sprejme pravilno, lahko še vedno nepravilno ugasnete pode, če so trenutno aktivni (na primer, če poteka transakcija v bazi podatkov).
Izgubite vse pode, v katerih je vaša aplikacija. Ta morda ne bo na voljo ob zagonu novih kontejnerjev na novih vozliščih ali, če so vaši podi nameščeni brez krmilnikov, se morda ne bodo ponovno zagnali.

Izogibanje izpadu

Da bi zmanjšali čas izpada zaradi prostovoljnega motenja, kot je operacija drain za vozlišče, Kubernetes ponuja naslednje možnosti za obvladovanje napak:

V preostalih delih cikla bomo uporabili te funkcije Kubernetes za omilitev posledic prenosa podov. Da bi olajšali sledenje glavni ideji, bomo uporabili naš zgornji primer s naslednjo konfiguracijo virov:

---
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

Ta konfiguracija je minimalni primer Deployment, ki upravlja podi nginx v grozdu. Poleg tega konfiguracija opisuje vir Storitev, ki ga je mogoče uporabiti za dostop do podov nginx v grozdu.

V celotnem ciklu bomo iterativno širili to konfiguracijo, da bo na koncu vključevala vse funkcionalnosti, ki jih Kubernetes ponuja za zmanjšanje časa nedelovanja.

Za popolnoma implementirano in testirano različico posodobitev grozda Kubernetes za ničelni čas nedelovanja na AWS in drugih virih obiščite Gruntwork.io.