ProHoster > Blog > Uprava > Nadgradnja gruče Kubernetes brez izpadov

Nadgradnja gruče Kubernetes brez izpadov

Nadgradnja gruče Kubernetes brez izpadov

Postopek nadgradnje za vašo gručo Kubernetes

Na neki točki, ko uporabljate gručo Kubernetes, je treba posodobiti delujoča vozlišča. To lahko vključuje posodobitve paketov, posodobitve jedra ali uvedbo novih slik virtualnih strojev. V terminologiji Kubernetes se to imenuje "Prostovoljna motnja".

Ta objava je del serije 4 objav:

  1. Ta objava.
  2. Pravilna zaustavitev podov v gruči Kubernetes
  3. Zakasnjena prekinitev sklopa, ko je izbrisan
  4. Kako se izogniti izpadom gruče Kubernetes z uporabo PodDisruptionBudgets

(pribl. v bližnji prihodnosti pričakujte prevode preostalih člankov v seriji)

V tem članku bomo opisali vsa orodja, ki jih ponuja Kubernetes za doseganje nič izpadov za vozlišča, ki se izvajajo v vaši gruči.

Opredelitev problema

Sprva bomo uporabili naiven pristop, prepoznali težave in ocenili morebitna tveganja tega pristopa ter gradili znanje za reševanje vsake težave, s katero se srečujemo v celotnem ciklu. Rezultat je konfiguracija, ki uporablja kljuke življenjskega cikla, sonde pripravljenosti in proračune za motnje Pod za doseganje našega cilja brez izpadov.

Za začetek naše poti vzemimo konkreten primer. Recimo, da imamo gručo Kubernetes dveh vozlišč, v kateri teče aplikacija z dvema podoma za Service:

Nadgradnja gruče Kubernetes brez izpadov

Začnimo z dvema podoma z Nginxom in storitvijo, ki se izvajata na naših dveh vozliščih gruče Kubernetes.

Posodobiti želimo različico jedra dveh delovnih vozlišč v naši gruči. Kako naj to naredimo? Preprosta rešitev bi bila zagon novih vozlišč s posodobljeno konfiguracijo in nato zaustavitev starih vozlišč med zagonom novih. Čeprav bo to delovalo, bo s tem pristopom nekaj težav:

  • Ko izklopite stara vozlišča, bodo izklopljeni tudi podi, ki se izvajajo na njih. Kaj pa, če je treba module očistiti za eleganten izklop? Sistem za virtualizacijo, ki ga uporabljate, morda ne bo čakal na dokončanje postopka čiščenja.
  • Kaj pa, če izklopite vsa vozlišča hkrati? Dobili boste spodoben čas izpadov, medtem ko se sklopi premikajo na nova vozlišča.

Potrebujemo način za elegantno selitev podov iz starih vozlišč, hkrati pa zagotovimo, da se noben od naših delovnih procesov ne izvaja, medtem ko spreminjamo vozlišče. Ali ko naredimo popolno zamenjavo gruče, kot v primeru (torej zamenjamo slike VM), želimo prenesti delujoče aplikacije iz starih vozlišč na nova. V obeh primerih želimo preprečiti, da bi novi podi načrtovali na starih vozliščih, nato pa iz njih izločiti vse delujoče pode. Za doseganje teh ciljev lahko uporabimo ukaz kubectl drain.

Prerazporeditev vseh podov iz vozlišča

Operacija praznjenja vam omogoča prerazporeditev vseh podov iz vozlišča. Med izvajanjem črpanja je vozlišče označeno kot nerazporejeno (zastavica NoSchedule). S tem preprečite, da bi se na njem pojavili novi stroki. Nato drenaža začne izrivati ​​stroke iz vozlišča, izklopi vsebnike, ki trenutno delujejo na vozlišču, in pošlje signal TERM posode v pod.

Čeprav kubectl drain bo odlično opravil izgon strokov, obstajata še dva dejavnika, ki lahko povzročita neuspeh odvajanja:

  • Vaša prijava se mora ob oddaji uspešno zaključiti TERM signal. Ko so stroki izgnani, Kubernetes pošlje signal TERM vsebnike in počaka, da se ustavijo določen čas, nato pa jih, če se ne ustavijo, prisilno prekine. V vsakem primeru, če vaš vsebnik ne zazna signala pravilno, lahko še vedno nepravilno ugasnete pode, če se trenutno izvajajo (na primer, poteka transakcija baze podatkov).
  • Izgubite vse pakete, ki vsebujejo vašo aplikacijo. Morda ne bo na voljo, ko se na novih vozliščih zaženejo novi vsebniki ali če so vaši podi razporejeni brez krmilnikov, se morda sploh ne bodo znova zagnali.

Izogibanje izpadom

Za zmanjšanje izpadov zaradi namerne motnje, na primer zaradi operacije črpanja na vozlišču, Kubernetes ponuja naslednje možnosti za obravnavo napak:

V preostalem delu serije bomo te funkcije Kubernetes uporabili za ublažitev vpliva selitve sklopov. Da bi lažje sledili glavni ideji, bomo uporabili naš zgornji primer z 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 minimalen primer Deployment, ki upravlja pode nginx v gruči. Poleg tega konfiguracija opisuje vir Service, ki se lahko uporablja za dostop do podov nginx v gruči.

V celotnem ciklu bomo to konfiguracijo iterativno širili, tako da bo sčasoma vključevala vse zmožnosti, ki jih Kubernetes ponuja za skrajšanje izpadov.

Za popolnoma implementirano in preizkušeno različico posodobitev gruče Kubernetes za brez izpadov na AWS in drugod obiščite Gruntwork.io.

Preberite tudi druge članke na našem blogu:

Vir: www.habr.com

Dodaj komentar