ProHoster > blog > administratie > Een Kubernetes-cluster upgraden zonder downtime

Een Kubernetes-cluster upgraden zonder downtime

Een Kubernetes-cluster upgraden zonder downtime

Upgradeproces voor uw Kubernetes-cluster

Wanneer u een Kubernetes-cluster gebruikt, is het op een gegeven moment nodig om actieve knooppunten bij te werken. Dit kunnen pakketupdates, kernelupdates of de implementatie van nieuwe virtuele machine-images zijn. In Kubernetes-terminologie heet dit "Vrijwillige verstoring".

Dit bericht maakt deel uit van een serie van 4 berichten:

  1. Deze post.
  2. Correcte afsluiting van peulen in een Kubernetes-cluster
  3. Vertraagde beëindiging van een pod wanneer deze wordt verwijderd
  4. Hoe u downtime van Kubernetes-clusters kunt voorkomen met behulp van PodDisruptionBudgets

(Verwacht ongeveer vertalingen van de resterende artikelen in de serie in de nabije toekomst)

In dit artikel beschrijven we alle tools die Kubernetes biedt om nul downtime te bereiken voor de knooppunten die in uw cluster draaien.

Het probleem definiëren

We zullen in eerste instantie voor een naïeve aanpak kiezen, problemen identificeren en de potentiële risico's van deze aanpak inschatten, en kennis opbouwen om elk van de problemen die we tijdens de cyclus tegenkomen op te lossen. Het resultaat is een configuratie die gebruikmaakt van lifecycle hooks, gereedheidstests en Pod-verstoringsbudgetten om ons doel van nul downtime te bereiken.

Laten we, om onze reis te beginnen, een concreet voorbeeld nemen. Laten we zeggen dat we een Kubernetes-cluster van twee knooppunten hebben, waarin een applicatie wordt uitgevoerd met twee pods erachter Service:

Een Kubernetes-cluster upgraden zonder downtime

Laten we beginnen met twee pods waarbij Nginx en Service worden uitgevoerd op onze twee Kubernetes-clusterknooppunten.

We willen de kernelversie van twee werkknooppunten in ons cluster bijwerken. Hoe doen we dit? Een eenvoudige oplossing zou zijn om nieuwe knooppunten op te starten met de bijgewerkte configuratie en vervolgens de oude knooppunten af ​​te sluiten terwijl u de nieuwe start. Hoewel dit zal werken, zullen er een paar problemen zijn met deze aanpak:

  • Wanneer u oude knooppunten uitschakelt, worden de pods die erop draaien ook uitgeschakeld. Wat als de pods moeten worden leeggemaakt voor een elegante afsluiting? Het virtualisatiesysteem dat u gebruikt, wacht mogelijk niet tot het opruimproces is voltooid.
  • Wat als u alle knooppunten tegelijkertijd uitschakelt? Je krijgt behoorlijke downtime terwijl de pods naar nieuwe knooppunten verhuizen.

We hebben een manier nodig om op een elegante manier pods van oude knooppunten te migreren en er tegelijkertijd voor te zorgen dat geen van onze werkprocessen actief is terwijl we wijzigingen aanbrengen in het knooppunt. Of wanneer we het cluster volledig vervangen, zoals in het voorbeeld (dat wil zeggen, we vervangen VM-images), willen we actieve applicaties overbrengen van oude knooppunten naar nieuwe. In beide gevallen willen we voorkomen dat nieuwe pods op oude knooppunten worden gepland en vervolgens alle actieve pods eruit verwijderen. Om deze doelen te bereiken kunnen we het commando gebruiken kubectl drain.

Alle pods vanaf een knooppunt opnieuw distribueren

Met de afvoerbewerking kunt u alle peulen vanaf een knooppunt opnieuw distribueren. Tijdens de afvoeruitvoering wordt het knooppunt gemarkeerd als niet-planbaar (flag NoSchedule). Dit voorkomt dat er nieuwe peulen op verschijnen. Vervolgens begint de drain de pods uit het knooppunt te verwijderen, schakelt de containers uit die momenteel op het knooppunt draaien en verzendt een signaal TERM containers in een peul.

Hoewel kubectl drain zal uitstekend werk leveren bij het uitzetten van peulen, er zijn twee andere factoren die ervoor kunnen zorgen dat de afvoer mislukt:

  • Uw aanvraag moet na indiening netjes kunnen worden beëindigd TERM signaal. Wanneer pods worden uitgezet, stuurt Kubernetes een signaal TERM containers en wacht een bepaalde tijd tot ze stoppen, waarna ze, als ze niet zijn gestopt, met geweld worden beëindigd. Hoe dan ook, als uw container het signaal niet correct waarneemt, kunt u pods nog steeds verkeerd doven als ze momenteel actief zijn (er is bijvoorbeeld een databasetransactie bezig).
  • U verliest alle peulen die uw toepassing bevatten. Het is mogelijk niet beschikbaar wanneer nieuwe containers op nieuwe knooppunten worden gelanceerd, of als uw pods zonder controllers worden ingezet, worden ze mogelijk helemaal niet opnieuw opgestart.

Stilstand vermijden

Om de downtime als gevolg van vrijwillige verstoring, zoals door een leegloopoperatie op een knooppunt, tot een minimum te beperken, biedt Kubernetes de volgende opties voor foutafhandeling:

In de rest van de serie zullen we deze Kubernetes-functies gebruiken om de impact van pod-migratie te verzachten. Om het gemakkelijker te maken om het hoofdidee te volgen, zullen we ons bovenstaande voorbeeld gebruiken met de volgende resourceconfiguratie:

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

Deze configuratie is een minimaal voorbeeld Deployment, dat nginx-pods in het cluster beheert. Bovendien beschrijft de configuratie de resource Service, die kan worden gebruikt om toegang te krijgen tot nginx-pods in een cluster.

Gedurende de cyclus zullen we deze configuratie iteratief uitbreiden, zodat deze uiteindelijk alle mogelijkheden bevat die Kubernetes biedt om de downtime te verminderen.

Ga voor een volledig geïmplementeerde en geteste versie van Kubernetes-clusterupdates voor nul downtime op AWS en daarbuiten naar Gruntwork.io.

Lees ook andere artikelen op onze blog:

Bron: www.habr.com

Voeg een reactie