🥇Kubernetes cluster updates without downtime

Teie Kubernetes-klastri uuendusprotsess

Kubernetes-klastri kasutamise ajal tekib varem või hiljem vajadus töökindlate sõlmede uuendamiseks. See võib hõlmata pakettuuendusi, tuumauuendusi või uute virtuaalmasinate piltide rakendamist. Kuberneteses tähendab see "Voluntary Disruption". "Vabatahtlik katkestus".

See postitus on osa neljast postitusest:

See postitus.
Podide korrektne väljalülitamine Kubernetes-klastri raames
Pod'i edasilükatud sulgemine selle kustutamisel
Kuidas vältida Kubernetes-klastri tööseisakuid PodDisruptionBudgets'i abil

(märkus tõlkijale: kaasnevad artiklid on oodata varsti)

Selles artiklis kirjeldame kõiki tööriistu, mida Kubernetes pakub teie klastri sõlmede nullaja töökatkestuse saavutamiseks.

Probleemi määratlemine

Alguses kasutame esialgset lähenemist, et määratleda probleeme ja hinnata nende lähenemiste võimalikke riske, kogudes teadmisi iga probleemiga tegelemiseks, millega kogu tsükli vältel silmitsi seisame. Tulemuseks on konfiguratsioon, mis kasutab elutsükli konksu, valmiduse proove ja Pod disruption budgets'i meie nullaja töökatkestuse saavutamiseks.

Meie teekonna alustamiseks võtame konkreetselt näiteks. Oletame, et meil on kahe sõlmega Kubernetes-klaster, kus töötab rakendus kahe pod’iga, mis asuvad. Teenused:

Hakkame pihta kahe pod'iga, kus Nginx ja teenus on käivitatud meie kahes Kubernetes-klastri sõlmes.

Soovime uuendada kahe töökindla sõlme tuumaversiooni meie klastris. Kuidas me seda teeme? Lihtsaim lahendus oleks laadida uued sõlmed uuendatud seadistusega ja seejärel välja lülitada vanad sõlmed, samal ajal uute sisselükkamisega. Kuigi see töötab, tekivad sellise lähenemisega mõned probleemid:

Kui välja lülitate vanad sõlmed, siis nende peal töötavad pod’id lülituvad samuti välja. Mis saab, kui pod’id tuleb õigeks väljalülitamiseks puhastada? Teie kasutatav virtualiseerimissüsteem ei pruugi oodata puhastusprotsessi lõpuleviimist.
Mis juhtub, kui lülitate välja kõik sõlmed korraga? Saate märkimisväärse tööseisaku, kui pod’id liiguvad uutele sõlmedele.

Me vajame õiget viisi podide migreerimiseks vanadelt noodidelt ning samal ajal peame olema kindlad, et ükski meie töösisestest protsessidest ei käivitu muudatuste tegemise ajal nodide kohta. Või kui teeme kogu klastri asenduse, nagu näites (st asendame VM-pildid), tahame töötavad rakendused vana nodide pealt uutele üle kanda. Mõlemal juhul soovime vältida uute podide ajastamist vanadele nodidele ja seejärel kõigi töötavate podide ümberpaigutamist. Selle saavutamiseks saame kasutada käsku kubectl drain.

Kõikide podide ümberpaigutamine nodilt

Drain-operatsioon võimaldab nõustada kõiki podide nodilt. Drain'i käivitamisel märgitakse node kui unschedulable (lipp NoSchedule). See takistab uudsete podide tekke. Seejärel drain hakkab podide node'ilt välja tõstma, lõpetades konteinerid, mis on hetkel nodis töötavad, edastades neile signaali TERM konteineritele podis.

Kuigi kubectl drain Kuigi see toimetab podide ümberpaigutamisega hästi, on veel kaks tegurit, mis võivad põhjustada drain operatsiooni ebaõnnestumise:

Teie rakendus peab suutma õiget moodi lõpetada signaali saamisel. TERM Kui podid tõstetakse välja, saadab Kubernetes signaali TERM konteineritele ja ootab nende lõpetamist määratud aja jooksul, pärast mida, kui nad ei ole lõpetanud, lõpetatakse need jõu abil. Igatahes, kui teie konteiner ei tõlgenda signaali õigesti, võite ikkagi lõpetada podid vale moodi, kui nad on mingil konkreetsel hetkel töös (nt käib tehing andmebaasis).
Te kaotate kõik podid, kus asub teie rakendus. See võib olla ajal, mil uued konteinerid alustavad tööd uutelt nodidelt, või kui teie podid on juurutatud ilma kontrolleriteta, ei pruugi need üldse uuesti käivituda.

Vältige seisakuaega

Kuna soovime minimaalset seisaku aega vabatahtliku tõrke korral, näiteks nodi drain operatsiooni tõttu, pakub Kubernetes järgmisi tõrkeid vähendamise võimalusi:

Tsükli teistes osades kasutame neid Kubernetes funktsioone podide üleviimise tagajärgede leevendamiseks. Põhimõtte jälgimise lihtsustamiseks kasutame ülaltoodud näidet järgmise ressursikonfiguratsiooniga:

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

See config on a minimal example Deployment, which manages nginx pods in the cluster. Furthermore, the configuration describes a resource Teenused, which can be used to access the nginx pods in the cluster.

Throughout this cycle, we will iteratively expand this configuration so that in the end it includes all capabilities provided by Kubernetes to minimize downtime.

To obtain a fully implemented and tested version of Kubernetes cluster updates for zero downtime on AWS and other resources, visit Gruntwork.io.