DevOps-bootcamp · Les

Rolling updates en rollbacks

Implementeer applicatie-updates zonder downtime en keer terug naar vorige versies als er problemen ontstaan.

Les 3 van 411 stappen

Rolling updates en rollbacks is een gratis DevOps-bootcamp-les op CoddyKit. Dit is les 3 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject DevOps-bootcamp. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus DevOps-bootcamp bevat in totaal 4 lessen.

Updates zonder downtime: waarom?

Stel je voor dat je een actieve applicatie bijwerkt. Zonder zorgvuldige planning kunnen gebruikers downtime of fouten ervaren. Hier komen rolling updates in Kubernetes goed van pas!

Met rolling updates kun je je applicatie bijwerken naar een nieuwe versie zonder de service te onderbreken. Nieuwe versies worden geleidelijk uitgerold, zodat je app beschikbaar blijft.

Hoe Deployments updates verwerken

Wanneer je het Pod-sjabloon van een Deployment bijwerkt (bijvoorbeeld door de containerimage te wijzigen), wordt niet alles zomaar afgesloten en opnieuw gestart. In plaats daarvan gebruikt Kubernetes standaard de strategie RollingUpdate.

  • Er worden nieuwe Pods gemaakt met de bijgewerkte configuratie.
  • Oude Pods worden geleidelijk beëindigd zodra de nieuwe gereed zijn.
  • Dit proces zorgt voor een soepele overgang met minimale of geen downtime.

De snelheid van een uitrol regelen

Je kunt het gedrag van rolling updates nauwkeurig afstemmen met twee belangrijke parameters in de sectie .spec.strategy.rollingUpdate van je Deployment:

  • maxUnavailable: het maximale aantal Pods dat tijdens de update niet beschikbaar mag zijn. Dit kan een absoluut aantal of een percentage zijn.
  • maxSurge: het maximale aantal Pods dat boven het gewenste aantal Pods mag worden gemaakt. Ook dit kan een absoluut aantal of een percentage zijn.

Standaard zijn beide ingesteld op 25%.

Onze eerste Deployment

Laten we beginnen met een eenvoudige Nginx-Deployment. Deze YAML definieert onze eerste applicatie, die 3 replica's van nginx:1.14.2 uitvoert.

We gebruiken dit als basis voor een rolling update in de volgende stap.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Een rolling update uitvoeren

Laten we nu onze Nginx-versie bijwerken van 1.14.2 naar 1.15.0. We wijzigen simpelweg de image in de YAML en passen deze toe.

Kubernetes detecteert de wijziging en start automatisch een rolling update. Bekijk hieronder het veld image:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.0
        ports:
        - containerPort: 80

De uitrolstatus bewaken

Nadat je de bijgewerkte YAML hebt toegepast, kun je de voortgang van je rolling update bewaken met de opdracht kubectl rollout status:

kubectl rollout status deployment/my-nginx

Je ziet berichten waarin wordt aangegeven dat nieuwe Pods worden gemaakt en oude Pods worden beëindigd totdat de update is voltooid. Je kunt ook kubectl get rs gebruiken om de oude en nieuwe ReplicaSets te bekijken.

De uitrolgeschiedenis controleren

Kubernetes bewaart een geschiedenis van de revisies van je Deployments. Dit is erg nuttig om wijzigingen te begrijpen en eventueel terug te draaien.

Gebruik de volgende opdracht om de geschiedenis te bekijken:

kubectl rollout history deployment/my-nginx

Je ziet een lijst met revisies, die elk een afzonderlijke toestand van je Deployment vertegenwoordigen. De CHANGE-CAUSE geeft vaak de opdracht of YAML-wijziging weer.

Wanneer terugdraaien nodig is

Zelfs met zorgvuldig testen introduceert een nieuwe applicatieversie soms bugs of prestatieproblemen die niet zijn ontdekt. In zulke kritieke situaties heb je een snelle manier nodig om terug te keren naar een bekende stabiele toestand.

Daarvoor kun je rollbacks gebruiken. Hiermee maak je een problematische update ongedaan en zet je je Deployment terug naar een eerdere, werkende versie uit de geschiedenis.

Een rollback uitvoeren

Gebruik de volgende opdracht om terug te gaan naar de direct voorafgaande revisie:

kubectl rollout undo deployment/my-nginx

Als je wilt teruggaan naar een specifieke revisie (bijvoorbeeld revisie 1), kun je die opgeven:

kubectl rollout undo deployment/my-nginx --to-revision=1

Kubernetes voert nog een rolling update uit om de Pods terug te zetten naar de opgegeven historische configuratie.

Controle van de uitrolstrategie

Welke van de volgende parameters kun je gebruiken om het gedrag van de strategie RollingUpdate van een Kubernetes-Deployment te regelen?

Samenvatting: soepele updates en vangnetten

We hebben bekeken hoe Kubernetes-Deployments rolling updates zonder downtime mogelijk maken, waarbij je applicaties soepel naar nieuwe versies overgaan. Je hebt geleerd:

  • Deployments gebruiken standaard RollingUpdate.
  • maxUnavailable en maxSurge bepalen de updatesnelheid.
  • kubectl rollout status bewaakt de voortgang.
  • kubectl rollout history houdt revisies bij.
  • Met kubectl rollout undo kun je snel teruggaan naar stabiele versies.

Deze functies zijn essentieel om hoge beschikbaarheid en betrouwbaarheid van je applicaties te behouden!

Gratis beginnen

Leer DevOps-bootcamp met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen
142
Lessen
568

Veelgestelde vragen

Is de les “Rolling updates en rollbacks” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad DevOps-bootcamp, waaronder “Rolling updates en rollbacks”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus DevOps-bootcamp bevat in totaal 4 lessen.

Wat leer ik in “Rolling updates en rollbacks”?

Implementeer applicatie-updates zonder downtime en keer terug naar vorige versies als er problemen ontstaan. Je oefent met DevOps-bootcamp door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met DevOps-bootcamp te beginnen?

Ervaring vooraf is niet nodig. DevOps-bootcamp op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 3 van 4.

Hoe lang duurt de les “Rolling updates en rollbacks”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over DevOps-bootcamp?

Ja. Elke les over DevOps-bootcamp bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

  1. Deployments begrijpen
  2. Applicaties schalen met ReplicaSets
  3. Rolling updates en rollbacks
  4. Deploymentstrategieën: blue-green en canary
← Terug naar DevOps-bootcamp