ProHoster > Blog > Bestjoer > It opwurdearjen fan in Kubernetes-kluster sûnder downtime

It opwurdearjen fan in Kubernetes-kluster sûnder downtime

It opwurdearjen fan in Kubernetes-kluster sûnder downtime

Upgradeproses foar jo Kubernetes-kluster

Op in stuit, by it brûken fan in Kubernetes-kluster, is d'r needsaak om rinnende knopen te aktualisearjen. Dit kin pakket updates, kernel updates, of ynset fan nije firtuele masine ôfbyldings. Yn Kubernetes terminology wurdt dit neamd "Frijwillige fersteuring".

Dit berjocht is diel fan in searje fan 4 posten:

  1. Dizze post.
  2. Korrekte ôfsluting fan pods yn in Kubernetes-kluster
  3. Fertrage beëiniging fan in pod as it wurdt wiske
  4. Hoe kinne jo Kubernetes Cluster Downtime foarkomme mei PodDisruptionBudgets

(sa. Ferwachtsje yn de heine takomst oersettingen fan de oerbleaune artikels yn de rige)

Yn dit artikel sille wy alle ark beskriuwe dy't Kubernetes leveret om nul downtime te berikken foar de knopen dy't yn jo kluster rinne.

It definiearjen fan it probleem

Wy sille earst in naïve oanpak nimme, problemen identifisearje en de potinsjele risiko's fan dizze oanpak beoardielje, en kennis bouwe om elk fan 'e problemen op te lossen dy't wy yn 'e syklus tsjinkomme. It resultaat is in konfiguraasje dy't lifecycle-haken, reewilligensprobes en Pod-ûntbrekkingsbudzjetten brûkt om ús doel fan nul downtime te berikken.

Om ús reis te begjinnen, litte wy in konkreet foarbyld nimme. Litte wy sizze dat wy in Kubernetes-kluster hawwe fan twa knooppunten, wêryn in applikaasje rint mei twa pods efter Service:

It opwurdearjen fan in Kubernetes-kluster sûnder downtime

Litte wy begjinne mei twa pods mei Nginx en Service dy't rinne op ús twa Kubernetes-klusterknooppunten.

Wy wolle de kernelferzje fan twa wurkknooppunten yn ús kluster bywurkje. Hoe dogge wy dit? In ienfâldige oplossing soe wêze om nije knopen te booten mei de bywurke konfiguraasje en dan de âlde knopen ôfslute by it starten fan de nije. Hoewol dit sil wurkje, sille d'r in pear problemen wêze mei dizze oanpak:

  • As jo ​​âlde knopen útsette, sille de pods dy't derop rinne ek útskeakele wurde. Wat as de pods moatte wurde wiske foar sierlike ôfsluting? It virtualisaasjesysteem dat jo brûke kin net wachtsje oant it opromjenproses foltôge is.
  • Wat as jo alle knopen tagelyk útsette? Jo sille fatsoenlike downtime krije wylst de pods nei nije knopen ferhúzje.

Wy hawwe in manier nedich om pods fan âlde knooppunten sierlik te migrearjen, wylst wy derfoar soargje dat gjin fan ús arbeidersprosessen rint wylst wy wizigingen oan it knooppunt meitsje. Of as wy in folsleine ferfanging fan it kluster dogge, lykas yn it foarbyld (dat is, wy ferfange VM-ôfbyldings), wolle wy rinnende applikaasjes fan âlde knopen nei nije oerdrage. Yn beide gefallen wolle wy foarkomme dat nije pods op âlde knopen planne, en dan alle rinnende pods fan har ferdriuwe. Om dizze doelen te berikken kinne wy ​​it kommando brûke kubectl drain.

Redistributing alle pods fan in knooppunt

De drain-operaasje lit jo alle pods fan in knooppunt opnij fersprieden. By it útfieren fan drain wurdt de knoop markearre as net-plannen (flagge NoSchedule). Dit foarkomt dat nije pods derop ferskine. Dan begjint drain pods út 'e knoop te ferdriuwen, slút de konteners út dy't op it stuit rinne op' e knoop, stjoert in sinjaal TERM konteners yn in pod.

Hoewol kubectl drain sil in geweldige baan dwaan om pods út te lûken, d'r binne twa oare faktoaren dy't kinne feroarsaakje dat de drainoperaasje mislearret:

  • Jo oanfraach moat by yntsjinjen graceful kinne beëinigje TERM sinjaal. Wannear't pods wurde útset, stjoert Kubernetes in sinjaal TERM konteners en wachtet oant se stopje foar in bepaalde tiid, wêrnei't se, as se net binne stoppe, se mei geweld beëinige. Yn alle gefallen, as jo kontener it sinjaal net goed waarnimt, kinne jo pods noch ferkeard blussen as se op it stuit rinne (bygelyks is in databanktransaksje oan 'e gong).
  • Jo ferlieze alle pods dy't jo applikaasje befetsje. It is mooglik net beskikber as nije konteners wurde lansearre op nije knopen, of as jo pods wurde ynset sûnder controllers, se meie net opnij starte hielendal.

It foarkommen fan downtime

Om downtime te minimalisearjen fan frijwillige steuring, lykas fan in drainoperaasje op in knooppunt, biedt Kubernetes de folgjende opsjes foar mislearring:

Yn 'e rest fan' e searje sille wy dizze Kubernetes-funksjes brûke om de ynfloed fan podmigraasje te ferminderjen. Om it makliker te meitsjen om it haadidee te folgjen, sille wy ús foarbyld hjirboppe brûke mei de folgjende boarnekonfiguraasje:

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

Dizze konfiguraasje is in minimal foarbyld Deployment, dy't nginx-pods yn it kluster beheart. Derneist beskriuwt de konfiguraasje de boarne Service, dat kin wurde brûkt om tagong te krijen ta nginx-pods yn in kluster.

Yn 'e rin fan' e syklus sille wy dizze konfiguraasje iteratyf útwreidzje, sadat it úteinlik alle mooglikheden omfettet dy't Kubernetes leveret om downtime te ferminderjen.

Foar in folslein ymplementearre en hifke ferzje fan Kubernetes-klusterupdates foar nul downtime op AWS en fierder, besykje Grutwork.io.

Lês ek oare artikels op ús blog:

Boarne: www.habr.com

Add a comment