🥇Uppfærðu Kubernetes klasa án niðurtíma

Uppfærsluferlið fyrir Kubernetes klasa þinn

Á einhverjum tímapunkti meðan á rekstri Kubernetes-klasa stendur verður þörf á að uppfæra keyrandi hnúta. Þetta gæti falið í sér uppfærslur á pakka, kjarnauppfærslur eða uppsetningu á nýjum sýndarvélamyndum. Í Kubernetes-hugtökum er þetta kallað ... „Sjálfviljug truflun“.

Þessi færsla er hluti af fjögurra færslna seríu:

Þessi færsla.
Snilldarleg lokun á hylki í Kubernetes klasa
Seinkað lokun á hylki þegar því er eytt
Hvernig á að forðast niðurtíma í Kubernetes klasa með PodDisruptionBudgets

(Athugasemd þýðanda: Búist er við þýðingum á eftirstandandi greinum í seríunni fljótlega)

Í þessari grein munum við lýsa öllum þeim verkfærum sem Kubernetes býður upp á til að ná núll niðurtíma fyrir hnúta sem keyra í klasanum þínum.

Að skilgreina vandamálið

Við munum í fyrstu nota einfeldnislega nálgun, greina vandamál og meta hugsanlega áhættu af þessari aðferð og safna þekkingu til að takast á við hvert vandamál sem við rekumst á í gegnum ferlið. Lokaniðurstaðan verður stilling sem notar líftímakróka, viðbúnaðarprófanir og fjárhagsáætlanir fyrir truflanir á búnaði til að ná markmiði okkar um núll niðurtíma.

Til að hefja ferðalag okkar skulum við taka raunhæft dæmi. Segjum sem svo að við höfum tveggja hnúta Kubernetes klasa sem keyrir forrit með tveimur hyljum á bak við sig. Service:

Byrjum á tveimur hylkjum með Nginx og Service sem keyra á tveimur Kubernetes klasahnútunum okkar.

Við viljum uppfæra kjarnaútgáfu tveggja vinnuhnúta í klasanum okkar. Hvernig gerum við þetta? Einföld lausn væri að ræsa nýja hnúta með uppfærðu stillingunum og slökkva síðan á gömlu hnútunum á meðan þeir nýju eru ræstir. Þó að þetta myndi virka eru nokkur vandamál með þessari aðferð:

Þegar þú lokar gömlum hnútum, þá verða hylkin sem keyra á þeim einnig lokuð. Hvað ef hylkin þurfa að vera hreinsuð til að hægt sé að loka þeim rétt? Sýndarvæðingarkerfið sem þú ert að nota gæti ekki beðið eftir að hreinsunarferlinu ljúki.
Hvað ef þú lokar öllum hnútum í einu? Þú munt upplifa verulegan niðurtíma á meðan hylkin flytjast yfir á nýja hnúta.

Við þurfum leið til að flytja hylki á skilvirkan hátt frá gömlum hnútum og tryggja að engin vinnuflæði okkar séu í gangi á meðan við gerum breytingar á hnút. Eða, þegar við erum að framkvæma fulla klasaskiptingu, eins og í dæminu (þ.e. að skipta út sýndarvélamyndum), viljum við flytja keyrandi forrit frá gömlum hnútum yfir í nýja. Í báðum tilvikum viljum við koma í veg fyrir að ný hylki séu tímasett á gömlu hnútunum og síðan fjarlægja öll keyrandi hylki frá þeim. Til að ná þessum markmiðum getum við notað skipunina kubectl drain.

Endurdreifing allra hylkja frá hnút

Tæmingaraðgerðin gerir þér kleift að endurdreifa öllum hylkjum úr hnút. Meðan á tæmingaraðgerðinni stendur er hnúturinn merktur sem óáætlaður (fáninn NoSchedule). Þetta kemur í veg fyrir að nýir hylki verði búnir til á því. Þá byrjar drain að fjarlægja hylki úr hnútnum og stöðvar ílát sem eru nú þegar í gangi á hnútnum með því að senda merki. TERM ílát í hylkjum.

Þó kubectl drain Þó að þetta virki vel til að losa um hylki, þá eru tveir aðrir þættir sem geta valdið því að frárennslisaðgerðin mistekst:

Umsókn þín verður að geta lokið snyrtilega við innsendingu. TERM merki. Þegar hylki eru fjarlægð sendir Kubernetes merki TERM gámar og bíður eftir að þeir stöðvist í ákveðinn tíma, en ef þeir hafa ekki stöðvast eftir það, þá lýkur það þeim með valdi. Í öllum tilvikum, ef gámurinn þinn bregst ekki rétt við merkinu, geturðu samt sem áður lýkur hylki rangt ef þau eru í gangi (til dæmis ef gagnagrunnsfærsla er í gangi).
Þú tapar öllum hylkjunum sem innihalda forritið þitt. Þau gætu verið ófáanleg þegar þú ræsir nýja gáma á nýjum hnútum, eða ef hylkin þín eru sett upp án stýringa gætu þau alls ekki endurræsst.

Að forðast niðurtíma

Til að lágmarka niðurtíma vegna sjálfviljugra truflana, svo sem hnútaþurrkunar, býður Kubernetes upp á eftirfarandi valkosti til að meðhöndla bilanir:

Í þeim köflum sem eftir eru í þessari seríu munum við nota þessa Kubernetes eiginleika til að draga úr áhrifum flutninga á pods. Til að auðvelda hugmyndina munum við nota dæmið okkar hér að ofan með eftirfarandi stillingu á auðlindum:

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

Þessi stilling er lágmarksdæmi. Deployment, sem stýrir nginx pods í klasanum. Að auki lýsir stillingin auðlindinni Service, sem hægt er að nota til að fá aðgang að nginx pods í klasanum.

Í gegnum ferlið munum við stækka þessa stillingu ítrekað þannig að hún innihaldi alla eiginleika Kubernetes til að draga úr niðurtíma.

Til að fá fullútfærða og prófaða útgáfu af Kubernetes klasauppfærslum fyrir núll niðurtíma á AWS og öðrum auðlindum, heimsækið Gruntwork.io.