Canary- en blue-green deploys met Argo Rollouts

Argo Rollouts vervangt je Kubernetes Deployment door een Rollout-resource die een nieuwe versie stapsgewijs uitrolt: als canary met een oplopend percentage verkeer, of als blue-green met een volledige preview-omgeving en een omschakeling in één keer. Tussen de stappen kan Rollouts automatisch Prometheus-metrics controleren en bij te veel fouten zelf terugrollen. Voor Laravel-apps werkt dat goed; bij Magento moet je eerst nadenken over databaseschema's en static content, anders draaien twee versies naast elkaar die elkaar in de weg zitten.

Wat een gewone Deployment niet kan

Een Kubernetes Deployment met RollingUpdate vervangt pods één voor één. Dat geeft geen downtime, maar het is ook geen controle:

• Je kunt niet zeggen: eerst 10 procent van het verkeer, dan wachten.
• Er is geen automatische check op foutpercentages. Een pod die opstart en zijn readiness probe haalt, telt als geslaagd, ook als elke checkout een 500 geeft.
• Terugrollen doe je handmatig, nadat iemand het probleem heeft opgemerkt.

Argo Rollouts voegt precies die drie dingen toe: stappen, analyse en automatisch afbreken.

De actuele stand

Argo Rollouts is een project uit de Argo-familie, naast Argo CD. Op het moment van schrijven is v1.10.1 de nieuwste release, van 12 oktober 2026. Die release, en de gelijktijdige patches v1.9.2 en v1.8.5, bevatten een securitywijziging: het dashboard luistert standaard alleen nog op de lokale interface. Stel je het dashboard via je eigen Helm-chart of een andere route beschikbaar, dan heb je de optie --address 0.0.0.0 nodig. Houd daar rekening mee bij een upgrade.

Installeren:

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts \
  -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# kubectl-plugin voor beheer vanaf de command line
brew install argoproj/tap/kubectl-argo-rollouts

In productie pin je een versie in plaats van latest, en beheer je de installatie via Git zoals de rest van je cluster.

Canary: stap voor stap meer verkeer

Een Rollout lijkt sterk op een Deployment. Het verschil zit in strategy:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: platform-web
  namespace: platform
spec:
  replicas: 6
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: platform-web
  template:
    metadata:
      labels:
        app: platform-web
    spec:
      containers:
        - name: app
          image: registry.example.nl/platform/web:2026.10.4
          ports:
            - containerPort: 8080
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 10m }
        - setWeight: 30
        - pause: { duration: 10m }
        - setWeight: 60
        - pause: { duration: 10m }

Zonder traffic router benadert Rollouts het percentage via het aantal pods. Bij 6 replicas en setWeight: 10 draait er één nieuwe pod naast vijf oude. Het verkeer volgt dat ongeveer, maar niet precies. Wil je echte percentages, dan heb je een traffic router nodig.

Heb je al een bestaande Deployment, dan hoef je die niet om te schrijven. Met workloadRef verwijst een Rollout naar de pod-template van een bestaande Deployment. Zet die Deployment daarna op nul replicas.

Echte verkeerssplitsing via de Gateway API

Gebruik je de Gateway API, de opvolger van Ingress waar we het over hadden in ingress-nginx stopt: migreren naar de Gateway API, dan kan Rollouts de gewichten in je HTTPRoute direct aanpassen. Daarvoor is er een plugin in Argoproj Labs.

Eerst laad je de plugin via de ConfigMap van de controller. Controleer de actuele versie op de releasepagina van argoproj-labs/rollouts-plugin-trafficrouter-gatewayapi:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argo-rollouts-config
  namespace: argo-rollouts
data:
  trafficRouterPlugins: |-
    - name: "argoproj-labs/gatewayAPI"
      location: "https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-gatewayapi/releases/download/v0.17.0/gatewayapi-plugin-linux-amd64"

Herstart daarna de controller. Geef de controller ook RBAC-rechten om HTTPRoutes te lezen en te wijzigen (get, list, update, patch op httproutes).

Dan twee Services, stable en canary, en een HTTPRoute die naar allebei wijst:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: platform-web
  namespace: platform
spec:
  parentRefs:
    - name: web
      namespace: gateway
  hostnames:
    - app.voorbeeld.nl
  rules:
    - backendRefs:
        - name: platform-web-stable
          port: 80
          weight: 100
        - name: platform-web-canary
          port: 80
          weight: 0

In de Rollout koppel je die objecten:

strategy:
  canary:
    stableService: platform-web-stable
    canaryService: platform-web-canary
    trafficRouting:
      plugins:
        argoproj-labs/gatewayAPI:
          httpRoute: platform-web
          namespace: platform
    steps:
      - setWeight: 5
      - pause: { duration: 5m }
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 50
      - pause: { duration: 10m }

Nu verandert Rollouts bij elke stap de weight-velden in de HTTPRoute. Bij 5 procent gaat ook echt ongeveer 5 procent van de requests naar de nieuwe versie, ongeacht het aantal pods. De plugin ondersteunt ook header-based routing, zodat je bijvoorbeeld eerst alleen je eigen team met een speciale header naar de canary stuurt.

Een detail: Argo CD ziet dat Rollouts de gewichten aanpast en markeert de HTTPRoute als out-of-sync. Laat Argo CD de weight-velden negeren met ignoreDifferences in je Application.

Automatisch beoordelen met Prometheus

Wachten met pause is beter dan niets. Beter is: laat Rollouts zelf kijken of de nieuwe versie gezond is. Dat doe je met een AnalysisTemplate:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate
  namespace: platform
spec:
  args:
    - name: service
  metrics:
    - name: error-rate
      interval: 1m
      count: 5
      failureLimit: 1
      successCondition: result[0] < 0.01
      provider:
        prometheus:
          address: http://monitoring-kube-prometheus-prometheus.monitoring.svc:9090
          query: |
            sum(rate(http_requests_total{service="{{args.service}}",code=~"5.."}[2m]))
            /
            sum(rate(http_requests_total{service="{{args.service}}"}[2m]))

De metricnaam hangt af van wat je meet. Bij een Gateway-implementatie op basis van Envoy komen request-metrics van de proxy; met PHP-applicaties is dat vaak de makkelijkste bron. Hoe je die metrics verzamelt, staat in Webshop monitoring met Prometheus, Grafana en Loki.

De analyse koppel je als stap in de canary:

steps:
  - setWeight: 10
  - analysis:
      templates:
        - templateName: error-rate
      args:
        - name: service
          value: platform-web-canary
  - setWeight: 50
  - pause: { duration: 10m }

Gaat het foutpercentage boven 1 procent, dan faalt de analyse. Rollouts breekt de rollout af en zet al het verkeer terug op de stabiele versie. Niemand hoeft wakker te worden om dat te doen.

Kies de drempel op basis van je eigen normale foutpercentage. Een drempel die al bij normale ruis afgaat, zorgt dat geen enkele release ooit doorkomt.

Blue-green: alles tegelijk, met een preview

Bij blue-green draait de nieuwe versie volledig naast de oude. Bezoekers zien de oude (active). Jij test de nieuwe via een preview-Service. Na goedkeuring schakelt Rollouts de active Service in één keer om.

strategy:
  blueGreen:
    activeService: platform-web-active
    previewService: platform-web-preview
    autoPromotionEnabled: false
    prePromotionAnalysis:
      templates:
        - templateName: error-rate
      args:
        - name: service
          value: platform-web-preview
    scaleDownDelaySeconds: 600

• autoPromotionEnabled: false betekent: wachten op een handmatige promote.
• prePromotionAnalysis draait vóór de omschakeling tegen de preview.
• scaleDownDelaySeconds houdt de oude versie nog tien minuten draaien. Terugschakelen gaat dan direct, zonder pods op te starten.

Blue-green werkt via de selector van de Services en heeft geen traffic router nodig. Het nadeel: tijdens de rollout draai je twee keer de capaciteit. Op een cluster met autoscaling vangen nieuwe nodes dat op, maar het kost tijdelijk meer.

Bediening vanaf de command line

# status volgen
kubectl argo rollouts get rollout platform-web -n platform --watch

# nieuwe versie starten (in GitOps doe je dit via een commit)
kubectl argo rollouts set image platform-web app=registry.example.nl/platform/web:2026.10.5 -n platform

# handmatig door naar de volgende stap of volledig promoten
kubectl argo rollouts promote platform-web -n platform
kubectl argo rollouts promote platform-web -n platform --full

# afbreken en terug naar stabiel
kubectl argo rollouts abort platform-web -n platform

Met Argo CD erbij wijzig je de image-tag in Git. Argo CD synct de Rollout, Rollouts voert de stappen uit. Argo CD herkent de health-status van een Rollout, dus een gepauzeerde of afgebroken rollout zie je terug in de Argo CD-interface. Waar de image-tag vandaan komt, bespreken we op CI/CD naar Kubernetes.

Waarom Magento lastiger is dan Laravel

Canary betekent: twee versies tegelijk in productie, tegen dezelfde database, dezelfde cache en dezelfde sessies. Dat moet je applicatie aankunnen.

Databaseschema. Magento controleert of de code en de database bij elkaar passen. Heeft een release setup:upgrade nodig met schemawijzigingen, dan kan de oude versie na de upgrade problemen krijgen, of de nieuwe ervoor. Onze vuistregel:

• Releases zonder schema- of data-patches: canary is mogelijk. Controleer dat in je pipeline met bin/magento setup:db:status tegen een kopie van productie.
• Releases met setup:upgrade: geen canary. Gebruik een gecontroleerde deploy met een migratie-Job, zoals beschreven in Magento deployen op Kubernetes zonder downtime.

Static content. Bij Magento zit de gedeployde static content in het image, met een versienummer in de URL. Een bezoeker die een HTML-pagina van de nieuwe versie krijgt en daarna een CSS-bestand opvraagt bij een oude pod, krijgt een 404. Oplossingen: static content via een CDN of object storage serveren waar beide versies naast elkaar staan, of de canary-fase kort houden.

Full page cache. Varnish voor je PHP-pods cachet pagina's van beide versies door elkaar. Bij een canary van de PHP-laag krijgt een deel van de bezoekers dus een gecachte pagina van de andere versie. Dat is meestal geen probleem, maar het maakt foutanalyse onduidelijker.

Laravel is in de regel eenvoudiger. Met migraties volgens het expand/contract-principe (eerst kolommen toevoegen, later pas oude verwijderen) kunnen twee versies prima naast elkaar draaien. Queue-workers rol je apart uit, want een job die door de nieuwe code is gemaakt, moet ook door een oude worker verwerkt kunnen worden, of andersom. Meer over die opzet in Laravel op Kubernetes.

Is het de moeite waard?

Argo Rollouts is een extra controller, extra CRD's en extra kennis in je team. Het loont als:

• Je vaak releaset en fouten in productie direct omzet kosten.
• Je platform genoeg verkeer heeft om in een paar minuten een betrouwbaar foutpercentage te meten.
• Je al Prometheus en een Gateway API-implementatie draait.

Bij een shop met weinig verkeer zegt een canary van 5 procent weinig: er komen te weinig requests langs om iets te meten. Dan is een gewone rolling update met goede readiness probes en een snelle rollback via Git vaak genoeg.

Wil je weten of dit in jouw release-proces past? Neem contact op. Het vaste team dat het inricht, draait het daarna ook mee.