ProHoster > Blog > Adminisztráció > Kubernetes-fürt frissítése állásidő nélkül

Kubernetes-fürt frissítése állásidő nélkül

Kubernetes-fürt frissítése állásidő nélkül

Frissítési folyamat a Kubernetes-fürthöz

Egy Kubernetes-fürt használatakor bizonyos pontokon frissíteni kell a futó csomópontokat. Ez magában foglalhatja a csomagfrissítéseket, a kernelfrissítéseket vagy új virtuálisgép-lemezképek telepítését. A Kubernetes terminológiában ezt hívják "Önkéntes megzavarás".

Ez a bejegyzés egy 4 bejegyzésből álló sorozat része:

  1. Ez a poszt.
  2. A podok helyes leállítása egy Kubernetes-fürtben
  3. Egy pod késleltetett leállítása törlésekor
  4. A Kubernetes-fürt leállásának elkerülése a PodDisruptionBudgets használatával

(kb. A sorozat többi cikkének fordítása a közeljövőben várható)

Ebben a cikkben leírjuk a Kubernetes által biztosított összes eszközt, amellyel nulla leállást érhet el a fürtben futó csomópontok számára.

A probléma meghatározása

Eleinte naiv megközelítést alkalmazunk, azonosítjuk a problémákat és felmérjük ennek a megközelítésnek a lehetséges kockázatait, és tudást építünk a ciklus során felmerülő problémák megoldására. Az eredmény egy olyan konfiguráció, amely életciklus-horgokat, készenléti szondákat és pod-megszakítási költségvetést használ a nulla leállási cél elérése érdekében.

Utazásunk megkezdéséhez vegyünk egy konkrét példát. Tegyük fel, hogy van egy két csomópontból álló Kubernetes-fürtünk, amelyben egy alkalmazás fut két poddal mögött. Service:

Kubernetes-fürt frissítése állásidő nélkül

Kezdjük azzal, hogy a két Kubernetes-fürtcsomóponton fut két pod Nginx és Service.

Frissíteni akarjuk a fürtünk két munkavégző csomópontjának kernelverzióját. Hogyan csináljuk ezt? Egy egyszerű megoldás az új csomópontok frissített konfigurációval történő elindítása, majd a régi csomópontok leállítása az újak indításakor. Bár ez működni fog, lesz néhány probléma ezzel a megközelítéssel:

  • Amikor kikapcsolja a régi csomópontokat, a rajtuk futó podok is kikapcsolódnak. Mi a teendő, ha a kecses leállításhoz törölni kell a hüvelyeket? Előfordulhat, hogy a használt virtualizációs rendszer nem várja meg a tisztítási folyamat befejeződését.
  • Mi van, ha egyszerre kikapcsolja az összes csomópontot? Tisztességes állásidőt fog kapni, amíg a hüvelyek új csomópontokhoz költöznek.

Szükségünk van egy módra, hogy kecsesen migráljuk a podokat a régi csomópontokról, miközben biztosítjuk, hogy a csomópont módosítása közben egyik dolgozói folyamatunk se futjon. Vagy amikor végrehajtjuk a fürt teljes cseréjét, mint a példában (vagyis VM-képfájlokat cserélünk), akkor a futó alkalmazásokat a régi csomópontokról újakra szeretnénk átvinni. Mindkét esetben meg akarjuk akadályozni, hogy új pod-ok ütemezzenek a régi csomópontokon, majd kilakoltatjuk az összes futó pod-ot. E célok eléréséhez használhatjuk a parancsot kubectl drain.

Az összes pod újraelosztása egy csomópontból

A leeresztési művelet lehetővé teszi az összes pod újraelosztását egy csomópontból. A leeresztés végrehajtása során a csomópont nem ütemezhetőként van megjelölve (jelző NoSchedule). Ez megakadályozza, hogy új hüvelyek jelenjenek meg rajta. Ezután a drain elkezdi kiüríteni a podokat a csomópontból, leállítja a csomóponton éppen futó konténereket, és jelet küld TERM konténerek egy hüvelyben.

Bár kubectl drain nagyszerű munkát fog végezni a hüvelyek kilakoltatásában, két másik tényező is okozhatja a leeresztő művelet meghiúsulását:

  • A kérelmet a benyújtáskor kecsesen le kell tudni zárni TERM jel. Amikor a hüvelyeket kilakoltatják, a Kubernetes jelet küld TERM konténereket, és meghatározott ideig várja azok leállását, majd ha nem álltak le, akkor erőszakkal megszünteti. Mindenesetre, ha a konténer nem érzékeli megfelelően a jelet, akkor is helytelenül olthatja ki a podokat, ha éppen futnak (például adatbázis-tranzakció van folyamatban).
  • Elveszíti az alkalmazását tartalmazó összes dobozt. Előfordulhat, hogy nem érhető el, amikor új tárolókat indítanak el új csomópontokon, vagy ha a pod-okat vezérlők nélkül helyezik üzembe, előfordulhat, hogy egyáltalán nem indulnak újra.

Az állásidő elkerülése

Az önkéntes megszakításokból, például egy csomópont leürítéséből eredő állásidő minimalizálása érdekében a Kubernetes a következő hibakezelési lehetőségeket kínálja:

A sorozat többi részében ezeket a Kubernetes-funkciókat fogjuk használni a pod-migráció hatásainak mérséklésére. A fő gondolat követésének megkönnyítése érdekében a fenti példánkat a következő erőforrás-konfigurációval fogjuk használni:

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

Ez a konfiguráció egy minimális példa Deployment, amely a fürtben lévő nginx hüvelyeket kezeli. Ezenkívül a konfiguráció leírja az erőforrást Service, amellyel fürtben lehet elérni az nginx podokat.

A ciklus során folyamatosan bővítjük ezt a konfigurációt, hogy végül magában foglalja a Kubernetes által az állásidő csökkentése érdekében biztosított összes képességet.

A Kubernetes-fürtfrissítések teljesen megvalósított és tesztelt verziója az AWS-en és azon túlmenően nulla leállás érdekében látogassa meg Gruntwork.io.

Olvassa el blogunk további cikkeit is:

Forrás: will.com

Hozzászólás