🥇Kubernetes klastri uuendamine katkestusteta

Teie Kubernetes-klastri värskendamise protsess

Kubernetes-klastri kasutamise käigus tekib vajadus värskendada töötavaid sõlmi. See võib hõlmata paketihalduse värskendusi, tuuma uuendamist või uute virtuaalmasinate piltide juurutamist. Kubernetes'e terminoloogias nimetatakse seda "Vabatahtlik katkestus".

See postitus on osa neljast postitusest:

See postitus.
Kubernetes-klastri pod'ide õigete lõpetamisprotseduuride järgimine
Pod'i edasilükatud lõpetamine selle eemaldamisel
Kuidas vältida Kubernetes-klastri töökatkestusi PodDisruptionBudgets'i abil

(näit. tõlke ülejäänud artiklite kohta oodake varsti)

Selles artiklis käsitleme kõiki tööriistu, mida Kubernetes pakub, et saavutada nullaegse töökatkestus teie klastri töötavatele sõlmedele.

Probleemi määratlemine

Alguses kasutame me lihtsat lähenemist, et tuvastada probleeme ja hinnata selle lähenemise võimalikke riske, samas kogume teadmisi iga probleemi lahendamiseks, millega seni silmitsi seisame. Tulemuseks on konfiguratsioon, kus on kasutusel lifecycle hooks, readiness probes ja Pod disruption budgets, et saavutada null seisakuaega.

Et alustada oma teekonda, võtame konkreetsena näitena näiteks. Oletame, et meil on Kubernetes klaster, kus on kaks sõlme ja käimas on rakendus, millel on kaks pod’i, mis asuvad Teenused:

Alustame kahe pod’iga, kus töötab Nginx ja Service meie kahe Kubernetes klastris oleva sõlme peal.

Soovime uuendada kahe töö sõlme tuumaversiooni meie klastris. Kuidas seda teha? Lihtsaim lahendus oleks käivitada uued sõlmed uuendatud konfiguratsiooniga ja seejärel välja lülitada vanad sõlmed, samal ajal kui uusi käivitame. Kuigi see toimib, on sellise lähenemisega mitmeid probleeme:

Kui te väljalülitate vanad sõlmed, siis väljalülitatakse ka nendel töötavad pod’id. Mis juhtub, kui pod’id tuleb õigeks väljalülitamiseks puhastada? Teie kasutatav virtualiseerimissüsteem ei pruugi oodata puhastusprotsessi lõpuni.
Mis juhtub, kui te välja lülitate kõik sõlmed korraga? Saate korraliku seisaku, kuni pod’id liiguvad uutele sõlmedele.

Meile on vajalik viis pod’ide õigeks migreerimiseks vanadelt sõlmedelt, olles samal ajal kindlad, et ükski meie tööprotsess ei tööta, kui me teeme muudatusi sõlmele. Või kui me teeme klusteri täieliku asendamise, nagu näites (st asendame virtuaalmasinate kujundid), tahame viia töötavad rakendused vanadelt sõlmedelt uutele. Mõlemal juhul soovime takistada uute pod’ide planeerimist vanadele sõlmedele ning seejärel evakueerida kõik töötavad pod’id nendelt. Nende eesmärkide saavutamiseks saame kasutada käsku kubectl drain.

Kõikide pod’ide ümberjaotamine sõlmest

Käsk drain võimaldab kõik pod’id sõlmest ümber jaotada. Drain'i täitmise protsessis märgitakse sõlm kui unschedulable (lipp NoSchedule). See on takistab uute pod'ide tekkimist. Seejärel drain hakkab pod'e nodest välja viima, lõpetades konteinerite töö, mis on hetkel nodis käimas, saates signaali TERM konteineritele pod’is.

Kuigi kubectl drain drainimisega saadakse hästi hakkama, kuid on veel kaks tegurit, mis võivad põhjustada operatsiooni drain ebaõnnestumise:

Teie rakendus peab oskama korrektselt lõpetada signaali saamisel. TERM Kui pod'id viiakse välja, saadab Kubernetes signaali TERM konteineritele ja ootab nende äralangemist määratud aja jooksul, pärast mida, kui nad ei ole lõpetanud, lõpetab nad jõhkralt. Igatahes, kui teie konteiner ei reageeri signaalile õigesti, võite ikkagi pod'ed lõpetada vale viisiga, kui nad on konkreetsel hetkel töös (näiteks, kui andmebaasis toimub tehing).
Te kaotate kõik pod'id, kus teie rakendus asub. See võib olla hetkeks kättesaamatu, kui uued konteinerid käivitatakse uutest nodidest, või kui teie pod'id on juurutatud ilma kontrolleriteta, võivad nad üldse mitte uuesti käivituda.

Vältige seisakuid

Kubernetes pakub järgmisi võimalusi tõrgete töötlemiseks, et minimeerida seisaku aega, mis on põhjustatud näiteks node'i drain operatsioonist, nagu näiteks vabatahtlik katkestus.

Ülejäänud elutsükli jooksul kasutame neid Kubernetes'e funktsioone, et leevendada pod'ide üleviimise tagajärgi. Et peamist mõtet lihtsam jälgida, 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 konfiguratsioon on minimaalne näide Deployment, mis haldab nginx pod'e klastris. Lisaks kirjeldab konfiguratsioon ressursi Teenused, mida saab kasutada nginx pod'idele klastris juurdepääsu saamiseks.

Kogu elutsükli jooksul laiendame iteratiivselt seda konfiguratsiooni, et lõpus sisaldaks see kõiki võimalusi, mida Kubernetes pakub seisaku aja vähendamiseks.

Ette näha täielikult rakendatud ja testitud versioon Kubernetes klastri uuendustest nullaja katkestustega AWS ja muudes ressurssides, külastage Gruntwork.io.