Opgradering van 'n Kubernetes-kluster sonder stilstand

Gradeer proses vir jou Kubernetes-kluster op

Op 'n sekere punt, wanneer 'n Kubernetes-kluster gebruik word, is daar 'n behoefte om lopende nodusse op te dateer. Dit kan pakketopdaterings, kernopdaterings of ontplooiing van nuwe virtuele masjienbeelde insluit. In Kubernetes terminologie word dit genoem "Vrywillige ontwrigting".

Hierdie plasing is deel van 'n reeks van 4 plasings:

1. Hierdie pos.
2. Korrekte sluiting van peule in 'n Kubernetes-kluster
3. Vertraagde beëindiging van 'n pod wanneer dit uitgevee word
4. Hoe om Kubernetes Cluster-stilstand te vermy deur PodDisruptionBudgets te gebruik

(Ongeveer. Verwag vertalings van die oorblywende artikels in die reeks in die nabye toekoms)

In hierdie artikel sal ons al die gereedskap beskryf wat Kubernetes verskaf om nul stilstand te bereik vir die nodusse wat in u groepering werk.

Definieer die probleem

Ons sal eers 'n naïewe benadering volg, probleme identifiseer en die potensiële risiko's van hierdie benadering beoordeel, en kennis bou om elkeen van die probleme wat ons deur die siklus teëkom, op te los. Die resultaat is 'n konfigurasie wat lewensiklushake, gereedheidsondersoeke en Pod-ontwrigtingsbegrotings gebruik om ons nul-stilstanddoelwit te bereik.

Om ons reis te begin, kom ons neem 'n konkrete voorbeeld. Kom ons sê ons het 'n Kubernetes-kluster van twee nodusse, waarin 'n toepassing loop met twee peule agter Service:

Kom ons begin met twee peule met Nginx en Service wat op ons twee Kubernetes-klusternodusse loop.

Ons wil die kernweergawe van twee werkernodusse in ons groepering opdateer. Hoe doen ons dit? 'n Eenvoudige oplossing sou wees om nuwe nodusse te begin met die opgedateerde konfigurasie en dan die ou nodusse af te skakel terwyl die nuwes begin word. Alhoewel dit sal werk, sal daar 'n paar probleme met hierdie benadering wees:

• Wanneer jy ou nodusse afskakel, sal die peule wat daarop loop ook afgeskakel word. Wat as die peule skoongemaak moet word vir grasieuse afsluiting? Die virtualisasiestelsel wat jy gebruik, wag dalk nie vir die skoonmaakproses om te voltooi nie.
• Wat as jy alle nodusse gelyktydig afskakel? Jy sal ordentlike stilstand kry terwyl die peule na nuwe nodusse beweeg.

Ons het 'n manier nodig om peule grasieus van ou nodusse te migreer, terwyl ons verseker dat geen van ons werkerprosesse loop terwyl ons veranderinge aan die nodus maak nie. Of wanneer ons 'n volledige vervanging van die cluster doen, soos in die voorbeeld (dit wil sê, ons vervang VM-beelde), wil ons lopende toepassings van ou nodusse na nuwes oordra. In beide gevalle wil ons verhoed dat nuwe peule op ou nodusse skeduleer, en dan alle lopende peule van hulle uitsit. Om hierdie doelwitte te bereik kan ons die opdrag gebruik kubectl drain.

Herverspreiding van alle peule vanaf 'n nodus

Die dreineerwerking laat jou toe om alle peule vanaf 'n nodus te herverdeel. Tydens dreinuitvoering word die nodus as ongeskeduleerd gemerk (vlag NoSchedule). Dit verhoed dat nuwe peule daarop verskyn. Dan begin drein om peule uit die knoop uit te sit, sluit die houers af wat tans op die knoop loop, en stuur 'n sein TERM houers in 'n peul.

Alhoewel kubectl drain sal 'n goeie werk doen om peule uit te sit, is daar twee ander faktore wat kan veroorsaak dat die dreinering misluk:

• Jou aansoek moet grasieus kan beëindig by indiening TERM sein. Wanneer peule uitgesit word, stuur Kubernetes 'n sein TERM houers en wag vir hulle om vir 'n bepaalde tyd te stop, waarna, indien hulle nie gestop het nie, dit hulle met geweld beëindig. In elk geval, as jou houer nie die sein reg waarneem nie, kan jy steeds peule verkeerd uitdoof as hulle tans aan die gang is (byvoorbeeld, 'n databasistransaksie is aan die gang).
• Jy verloor al die peule wat jou toepassing bevat. Dit is dalk nie beskikbaar wanneer nuwe houers op nuwe nodusse bekendgestel word nie, of as jou peule sonder beheerders ontplooi word, sal hulle dalk glad nie herbegin nie.

Vermy stilstand

Om stilstand as gevolg van vrywillige ontwrigting, soos van 'n dreinoperasie op 'n nodus, te verminder, bied Kubernetes die volgende fouthanteringsopsies:

• Grasieuse beëindiging
• Lewensiklushake
• PodOntwrigting Begrotings

In die res van die reeks sal ons hierdie Kubernetes-kenmerke gebruik om die impak van peulmigrasie te versag. Om dit makliker te maak om die hoofgedagte te volg, sal ons ons voorbeeld hierbo gebruik met die volgende hulpbronkonfigurasie:

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

Hierdie konfigurasie is 'n minimale voorbeeld Deployment, wat nginx-peule in die groep bestuur. Daarbenewens beskryf die konfigurasie die hulpbron Service, wat gebruik kan word om toegang tot nginx-peule in 'n groepie te verkry.

Dwarsdeur die siklus sal ons hierdie konfigurasie iteratief uitbrei sodat dit uiteindelik al die vermoëns insluit wat Kubernetes bied om stilstand te verminder.

Vir 'n volledig geïmplementeerde en getoetsde weergawe van Kubernetes-klusteropdaterings vir geen stilstand op AWS en verder, besoek Gruntwork.io.

Lees ook ander artikels op ons blog:

• Zero stilstand ontplooiing en databasisse
• Kubernetes: hoekom is dit so belangrik om stelselhulpbronbestuur op te stel?
• Tekton Pipeline - Kubernetes inheemse pypleidings
• Bou dinamiese modules vir Nginx
• Inleiding tot Hashicorp Consul se Kubernetes-magtiging
• Waartoe het die migrasie van ClickHouse sonder magtiging na ClickHouse met magtiging gelei?

Bron: will.com