Automated canary with Flagger and Traefik on Kubernetes

1. The principle #

Canary without human intervention.

How it works #

Flagger is a Kubernetes progressive delivery operator. From a Deployment, it creates a primary (stable) version and a canary version, then drives a weighted TraefikService. With each new image, it gradually increases the canary's share of traffic as long as the metrics stay good, then promotes it; otherwise it rolls back.

2. Installation and the Canary resource #

Flagger with the Traefik provider.

Installation #

helm repo add flagger https://flagger.app
helm upgrade --install flagger flagger/flagger -n traefik \
  --set meshProvider=traefik \
  --set metricsServer=http://prometheus.monitoring:9090

Canary #

apiVersion: flagger.app/v1beta1
kind: Canary
metadata: { name: app, namespace: app }
spec:
  provider: traefik
  targetRef: { apiVersion: apps/v1, kind: Deployment, name: app }
  service: { port: 80, targetPort: 8080 }
  analysis:
    interval: 1m
    threshold: 5                 # 5 analyses en échec = retour arrière
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange: { min: 99 }
        interval: 1m
      - name: request-duration
        thresholdRange: { max: 500 }   # millisecondes
        interval: 1m
    webhooks:
      - name: tests-de-fumee
        type: pre-rollout
        url: http://flagger-loadtester.app/
        metadata: { cmd: "curl -sf http://app-canary.app/healthz" }

3. Following and triggering #

Day to day.

Commands #

kubectl -n app set image deploy/app app=registre/app:2.1.0   # déclenche une analyse
kubectl -n app get canary app -w                                # Progressing, Succeeded, Failed
kubectl -n app describe canary app                              # événements : poids, métriques, décisions
kubectl -n app get traefikservice

• Generate traffic during the analysis (loadtester): without requests, metrics are empty and the analysis fails.
• Choose thresholds aligned with your SLOs.
• Send Flagger events to the team's channel (Slack or Teams alerting).

Good practice: Start with a non-critical service and observe several deployments before rolling it out more widely.