ProHoster > Blog > Administratioun > Upgrade vun engem Kubernetes Cluster ouni Ënnerbriechung

Upgrade vun engem Kubernetes Cluster ouni Ënnerbriechung

Upgrade vun engem Kubernetes Cluster ouni Ënnerbriechung

Upgrade Prozess fir Äre Kubernetes Cluster

Irgendwann, wann Dir e Kubernetes-Cluster benotzt, ass et e Besoin fir lafenden Noden ze aktualiséieren. Dëst kann Pakupdates, Kernelupdates oder Deployment vun neie virtuelle Maschinnbiller enthalen. An der Kubernetes Terminologie gëtt dat genannt "Fräiwëlleg Stéierung".

Dëse Post ass Deel vun enger 4-Post Serie:

  1. Dëse Post.
  2. Korrekt Ausschaltung vu Pods an engem Kubernetes Cluster
  3. Verspéit Fäerdegstellung vun engem Pod wann et geläscht gëtt
  4. Wéi vermeide Kubernetes Cluster Downtime Mat PodDisruptionBudgets

(ca. Iwwersetzunge vun de reschtlechen Artikelen an der Serie erwaarden an nächster Zukunft)

An dësem Artikel beschreiwen mir all d'Tools déi Kubernetes ubitt fir Null Downtime fir d'Noden ze erreechen déi an Ärem Cluster lafen.

Definéiere vum Problem

Mir wäerten am Ufank eng naiv Approche huelen, Problemer identifizéieren an déi potenziell Risiken vun dëser Approche bewäerten, a Wëssen opbauen fir jiddereng vun de Probleemer ze léisen déi mir am ganzen Zyklus begéinen. D'Resultat ass eng Konfiguratioun déi Liewenszyklus Haken, Bereetschaftssonden a Pod Stéierungsbudgeten benotzt fir eis Null Downtime Zil z'erreechen.

Fir eis Rees unzefänken, huelen mir e konkret Beispill. Loosst eis soen datt mir e Kubernetes Stärekoup vun zwee Wirbelen hunn, an deem eng Applikatioun leeft mat zwee Pods hannert Service:

Upgrade vun engem Kubernetes Cluster ouni Ënnerbriechung

Loosst eis ufänken mat zwee Pods mat Nginx a Service op eisen zwee Kubernetes Cluster Noden.

Mir wëllen d'Kernel Versioun vun zwee Aarbechtsknäppchen an eisem Cluster aktualiséieren. Wéi maache mir dat? Eng einfach Léisung wier nei Wirbelen mat der aktualiséierter Konfiguratioun ze booten an dann déi al Wirbelen auszeschalten wann Dir déi nei starten. Wärend dëst funktionnéiert, ginn et e puer Probleemer mat dëser Approche:

  • Wann Dir al Wirbelen ausschalt, ginn d'Pods, déi drop lafen, och ausgeschalt. Wat wann d'Pods musse geläscht ginn fir e graziéisen Ofschloss? De Virtualiséierungssystem deen Dir benotzt, kann net waarden bis de Botzenprozess fäerdeg ass.
  • Wat wann Dir all Wirbelen zur selwechter Zäit ausschalt? Dir kritt anstänneg Ënnerbriechung wärend d'Pods op nei Wirbelen plënneren.

Mir brauche e Wee fir Pods aus alen Noden graziéis ze migréieren, wärend mir sécherstellen datt keen vun eisen Aarbechterprozesser leeft wärend mir Ännerungen am Node maachen. Oder wa mir e komplette Ersatz vum Cluster maachen, wéi am Beispill (dat ass, mir ersetzen VM Biller), wëlle mir lafen Uwendungen vun alen Wirbelen op nei iwwerdroen. A béide Fäll wëlle mir verhënneren datt nei Pods op alen Wirbelen geplangt ginn, an dann all lafen Pods aus hinnen evitéieren. Fir dës Ziler z'erreechen kënne mir de Kommando benotzen kubectl drain.

Ëmverdeelt all Pods vun engem Node

D'Drainoperatioun erlaabt Iech all Pods vun engem Node ze verdeelen. Wärend der Ausféierung vum Drain gëtt den Node als onplangbar markéiert (Fändel NoSchedule). Dëst verhënnert datt nei Pods drop optrieden. Da fänkt d'Drain un Pods aus dem Node erauszekréien, schléisst d'Container aus, déi am Moment um Node lafen, andeems Dir e Signal schéckt TERM Behälter an der Këscht.

Obschonns kubectl drain wäert eng super Aarbecht maachen fir Pods z'evitéieren, et ginn zwee aner Faktoren déi d'Drainoperatioun versoen kënnen:

  • Är Demande muss fäeg sinn graziéis bei der Soumissioun ofzeschléissen TERM Signal. Wann Pods evictéiert ginn, schéckt Kubernetes e Signal TERM Container a waart op se fir eng spezifizéiert Zäit ze stoppen, duerno, wa se net gestoppt hunn, se zwangsleefeg ofgeschloss. Op alle Fall, wann Äre Container d'Signal net richteg erkennt, kënnt Dir nach ëmmer Pods falsch ausléisen wa se am Moment lafen (zum Beispill eng Datebanktransaktioun ass amgaang).
  • Dir verléiert all Pods déi Är Applikatioun enthalen. Et ass vläicht net verfügbar wann nei Container op neie Wirbelen lancéiert ginn, oder wann Är Pods ouni Controller ofgebaut ginn, kënnen se guer net nei starten.

Vermeiden Ausdauer

Fir d'Downtime vu fräiwëlleger Stéierungen ze minimiséieren, sou wéi vun enger Drainoperatioun op engem Node, bitt Kubernetes déi folgend Feelerhandhabungsoptiounen:

Am Rescht vun der Serie wäerte mir dës Kubernetes Feature benotze fir den Impakt vu migréierende Pods ze reduzéieren. Fir et méi einfach ze maachen d'Haaptidee ze verfollegen, benotze mir eist Beispill hei uewen mat der folgender Ressourcekonfiguratioun:

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

Dës Konfiguratioun ass e minimalt Beispill Deployment, déi nginx Pods am Cluster geréiert. Zousätzlech beschreift d'Konfiguratioun d'Ressource Service, déi benotzt ka ginn fir Zougang zu nginx Pods an engem Cluster.

Am ganzen Zyklus wäerte mir dës Konfiguratioun iterativ ausbauen, sou datt se schliisslech all d'Fäegkeeten enthält, déi Kubernetes ubitt fir d'Downtime ze reduzéieren.

Fir eng komplett implementéiert a getest Versioun vu Kubernetes Clusterupdates fir Null Downtime op AWS an doriwwer eraus, besicht Gruntwork.io.

Liest och aner Artikelen op eisem Blog:

Source: will.com

Setzt e Commentaire