ProHoster > blogg > administration > Uppgradera ett Kubernetes-kluster utan driftstopp

Uppgradera ett Kubernetes-kluster utan driftstopp

Uppgradera ett Kubernetes-kluster utan driftstopp

Uppgraderingsprocessen för ditt Kubernetes-kluster

Vid någon tidpunkt, när du använder ett Kubernetes-kluster, finns det ett behov av att uppdatera löpande noder. Detta kan inkludera paketuppdateringar, kärnuppdateringar eller distribution av nya virtuella maskinavbildningar. I Kubernetes terminologi kallas detta "Frivillig störning".

Det här inlägget är en del av en serie med fyra inlägg:

  1. Den här posten.
  2. Korrekt avstängning av pods i ett Kubernetes-kluster
  3. Försenad avslutning av en pod när den raderas
  4. Hur man undviker Kubernetes Cluster Downtime med PodDisruptionBudgets

(ca. Räkna med översättningar av de återstående artiklarna i serien inom en snar framtid)

I den här artikeln kommer vi att beskriva alla verktyg som Kubernetes tillhandahåller för att uppnå noll driftstopp för noderna som körs i ditt kluster.

Problemdefinition

Vi kommer att ta ett naivt förhållningssätt till en början, identifiera problem och bedöma de potentiella riskerna med detta tillvägagångssätt, och bygga kunskap för att lösa vart och ett av de problem vi stöter på under hela cykeln. Resultatet är en konfiguration som använder livscykelhakar, beredskapssonder och Pod-avbrottsbudgetar för att uppnå vårt mål om noll stillestånd.

För att börja vår resa, låt oss ta ett konkret exempel. Låt oss säga att vi har ett Kubernetes-kluster med två noder, där en applikation körs med två poddar bakom Service:

Uppgradera ett Kubernetes-kluster utan driftstopp

Låt oss börja med två pods med Nginx och Service som körs på våra två Kubernetes-klusternoder.

Vi vill uppdatera kärnversionen av två arbetarnoder i vårt kluster. Hur gör vi detta? En enkel lösning skulle vara att starta upp nya noder med den uppdaterade konfigurationen och sedan stänga av de gamla noderna samtidigt som man startar de nya. Även om detta kommer att fungera, kommer det att finnas några problem med detta tillvägagångssätt:

  • När du stänger av gamla noder stängs även podarna som körs på dem av. Vad händer om baljorna måste rensas för graciös avstängning? Det virtualiseringssystem du använder kanske inte väntar på att rensningsprocessen ska slutföras.
  • Vad händer om du stänger av alla noder samtidigt? Du kommer att få anständig driftstopp medan poddarna flyttar till nya noder.

Vi behöver ett sätt att på ett elegant sätt migrera pods från gamla noder samtidigt som vi säkerställer att ingen av våra arbetsprocesser körs medan vi gör ändringar i noden. Eller när vi gör en fullständig ersättning av klustret, som i exemplet (det vill säga vi ersätter VM-bilder), vill vi överföra körande applikationer från gamla noder till nya. I båda fallen vill vi förhindra att nya pods schemaläggs på gamla noder, och sedan vräka alla pågående pods från dem. För att uppnå dessa mål kan vi använda kommandot kubectl drain.

Omfördelning av alla poddar från en nod

Dräneringsoperationen låter dig omfördela alla pods från en nod. Under körning av dränering markeras noden som oplanerad (flagga NoSchedule). Detta förhindrar att nya poddar dyker upp på den. Sedan börjar dräneringen att kasta ut baljor från noden, stänger av behållarna som för närvarande körs på noden, skickar en signal TERM behållare i en balja.

Även kubectl drain kommer att göra ett bra jobb med att vräka baljor, det finns två andra faktorer som kan orsaka att dräneringen misslyckas:

  • Din ansökan måste kunna avslutas graciöst vid inlämnandet TERM signal. När baljor vräkas, skickar Kubernetes en signal TERM containrar och väntar på att de ska stanna under en viss tid, varefter den, om de inte har stannat, tvångsavslutar dem. I alla fall, om din behållare inte uppfattar signalen korrekt, kan du fortfarande släcka pods felaktigt om de körs för närvarande (till exempel en databastransaktion pågår).
  • Du förlorar alla poddar som innehåller din applikation. Det kanske inte är tillgängligt när nya behållare lanseras på nya noder, eller om dina poddar distribueras utan kontroller kanske de inte startar om alls.

Undviker driftstopp

För att minimera driftstopp från frivilliga avbrott, till exempel från en dräneringsoperation på en nod, tillhandahåller Kubernetes följande felhanteringsalternativ:

I resten av serien kommer vi att använda dessa Kubernetes-funktioner för att mildra effekten av podmigrering. För att göra det lättare att följa huvudidén kommer vi att använda vårt exempel ovan med följande resurskonfiguration:

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

Denna konfiguration är ett minimalt exempel Deployment, som hanterar nginx-pods i klustret. Dessutom beskriver konfigurationen resursen Service, som kan användas för att komma åt nginx-pods i ett kluster.

Under hela cykeln kommer vi iterativt att utöka denna konfiguration så att den så småningom inkluderar alla funktioner Kubernetes tillhandahåller för att minska stilleståndstiden.

För en fullt implementerad och testad version av Kubernetes klusteruppdateringar för noll driftstopp på AWS och senare, besök Gruntwork.io.

Läs även andra artiklar på vår blogg:

Källa: will.com

Lägg en kommentar