ProHoster > Blog > Stjórnsýsla > Uppfærsla á Kubernetes klasa án niður í miðbæ

Uppfærsla á Kubernetes klasa án niður í miðbæ

Uppfærsla á Kubernetes klasa án niður í miðbæ

Uppfærsluferli fyrir Kubernetes klasann þinn

Á einhverjum tímapunkti, þegar þú notar Kubernetes þyrping, er þörf á að uppfæra hlaupandi hnúta. Þetta getur falið í sér pakkauppfærslur, kjarnauppfærslur eða uppsetningu nýrra sýndarvélamynda. Í Kubernetes hugtökum er þetta kallað "Sjálfviljug truflun".

Þessi færsla er hluti af 4 færsluröð:

  1. Þessi færsla.
  2. Rétt lokun á belgjum í Kubernetes klasa
  3. Seinkað frágangi hólfs þegar honum er eytt
  4. Hvernig á að forðast Kubernetes klasa niður í miðbæ með því að nota PodDisruptionBudgets

(u.þ.b. Búast við þýðingum á þeim greinum sem eftir eru í ritröðinni á næstunni)

Í þessari grein munum við lýsa öllum verkfærunum sem Kubernetes veitir til að ná núllni niður í miðbæ fyrir hnútana sem keyra í þyrpingunni þinni.

Að skilgreina vandamálið

Við munum taka barnaleg nálgun í fyrstu, bera kennsl á vandamál og meta hugsanlega áhættu þessarar nálgunar og byggja upp þekkingu til að leysa hvert vandamál sem við lendum í gegnum hringrásina. Niðurstaðan er uppsetning sem notar líftíma króka, viðbúnaðarskynjara og fjárhagsáætlanir fyrir pod truflanir til að ná núll niðurtímamarkmiði okkar.

Til að hefja ferð okkar skulum við taka áþreifanlegt dæmi. Segjum að við séum með Kubernetes þyrping af tveimur hnútum, þar sem forrit er í gangi með tvo belg staðsetta fyrir aftan Service:

Uppfærsla á Kubernetes klasa án niður í miðbæ

Við skulum byrja á tveimur belgjum með Nginx og þjónustu sem keyra á tveimur Kubernetes klasahnútum okkar.

Við viljum uppfæra kjarnaútgáfu tveggja starfsmannahnú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 ræsa nýja. Þó að þetta muni virka, þá verða nokkur vandamál með þessa nálgun:

  • Þegar þú slekkur á gömlum hnútum verður einnig slökkt á belgunum sem keyra á þeim. Hvað ef það þarf að hreinsa belgina fyrir þokkafulla lokun? Sýndarvæðingarkerfið sem þú notar gæti ekki beðið eftir að hreinsunarferlinu ljúki.
  • Hvað ef þú slekkur á öllum hnútum á sama tíma? Þú munt fá ágætis niður í miðbæ á meðan belgirnir fara í nýja hnúta.

Við þurfum leið til að flytja fræbelg frá gömlum hnútum á þokkafullan hátt á meðan við tryggjum að ekkert af starfsferlum okkar sé í gangi á meðan við gerum breytingar á hnútnum. Eða þegar við gerum algjöra endurnýjun á klasanum, eins og í dæminu (þ.e. við skiptum út VM myndum), viljum við flytja keyrandi forrit frá gömlum hnútum yfir í nýja. Í báðum tilfellum viljum við koma í veg fyrir að nýir belg séu tímasettir á gamla hnúta, og sleppa síðan öllum hlaupandi belgjum frá þeim. Til að ná þessum markmiðum getum við notað skipunina kubectl drain.

Endurdreifir öllum belg frá hnút

Afrennslisaðgerðin gerir þér kleift að dreifa öllum belgjum frá hnút. Við framkvæmd frárennslis er hnúturinn merktur sem ótímasettur (fáni NoSchedule). Þetta kemur í veg fyrir að nýir belg birtist á honum. Þá byrjar tæmsla að reka fræbelg úr hnútnum, slekkur á gámunum sem eru í gangi á hnútnum með því að senda merki TERM ílát í belgnum.

Þó kubectl drain mun gera frábært starf við að reka fræbelg, það eru tveir aðrir þættir sem geta valdið því að frárennslisaðgerðin mistekst:

  • Umsókn þinni verður að geta lokið með þokkabót þegar hún er lögð fram TERM merki. Þegar belgjum er vísað út sendir Kubernetes merki TERM gáma og bíður eftir að þeir stöðvist í ákveðinn tíma, eftir það, ef þeir hafa ekki stöðvað, stöðvar það þá með valdi. Í öllum tilvikum, ef ílátið þitt skynjar ekki merkið rétt, geturðu samt slökkt á belgunum á rangan hátt ef þeir eru í gangi (til dæmis er gagnagrunnsfærsla í gangi).
  • Þú tapar öllum belgunum sem innihalda forritið þitt. Það getur verið að það sé ekki tiltækt þegar nýir gámar eru settir á nýja hnúta, eða ef belgirnir þínir eru settir á vettvang án stýringa, gætu þeir alls ekki endurræst sig.

Forðast niður í miðbæ

Til að lágmarka niður í miðbæ vegna viljandi truflunar, eins og frá tæmingaraðgerð á hnút, býður Kubernetes upp á eftirfarandi valkosti fyrir bilun:

Í restinni af seríunni munum við nota þessa Kubernetes eiginleika til að draga úr áhrifum flutningsbelgja. Til að gera það auðveldara að fylgja meginhugmyndinni munum við nota dæmið okkar hér að ofan með eftirfarandi auðlindastillingu:

---
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 uppsetning er lágmarksdæmi Deployment, sem stjórnar nginx fræbelgjum í þyrpingunni. Að auki lýsir uppsetningin auðlindinni Service, sem hægt er að nota til að fá aðgang að nginx fræbelg í þyrpingu.

Í gegnum lotuna munum við endurtekið stækka þessa stillingu þannig að hún innihaldi að lokum alla möguleika Kubernetes til að draga úr niður í miðbæ.

Fyrir fullkomlega útfærða og prófaða útgáfu af Kubernetes klasauppfærslum fyrir núll niður í miðbæ á AWS og víðar skaltu heimsækja Gruntwork.io.

Lestu einnig aðrar greinar á blogginu okkar:

Heimild: www.habr.com

Bæta við athugasemd