Flagger

Flagger est un opérateur Kubernetes de progressive delivery, CNCF Sandbox, développé initialement par Weaveworks et maintenant maintenu sous l'organisation fluxcd sur GitHub. Il automatise les déploiements canary, blue-green et A/B testing en s'appuyant sur le traffic shifting fourni par le service mesh (Istio, Linkerd, App Mesh) ou le contrôleur Ingress (NGINX, Contour, Traefik, Gloo). Il interroge Prometheus à chaque intervalle d'analyse et rollbacke automatiquement si les métriques ne satisfont pas les seuils définis.

Informations essentielles

Origine : Weaveworks → CNCF Sandbox (org fluxcd)  ·  Licence : Apache 2.0  ·  Architectures : x86_64, ARM64

Liens : Site officiel  ·  Documentation  ·  GitHub  ·  Releases

Support : CNCF Sandbox. Actif, maintenu par la communauté Flux/CNCF.

Stack par défaut

Prérequis

Installation

helm repo add flagger https://flagger.app
helm repo update

# Avec Istio
helm install flagger flagger/flagger \
  --namespace=istio-system \
  --set meshProvider=istio \
  --set metricsServer=http://prometheus.istio-system:9090

# Avec NGINX Ingress
helm install flagger flagger/flagger \
  --namespace=ingress-nginx \
  --set meshProvider=nginx \
  --set metricsServer=http://prometheus.monitoring:9090

Installer le Grafana dashboard (optionnel)

helm install flagger-grafana flagger/grafana \
  --namespace=flagger \
  --set url=http://prometheus.monitoring:9090

Déployer un canary

Flagger gère les Services et Deployments automatiquement. Il crée des ressources -primary et -canary. Il suffit de déclarer une Canary et de déployer le Deployment cible normalement.

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: my-app
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  # Provider de traffic shifting (ici NGINX)
  ingressRef:
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    name: my-app
  progressDeadlineSeconds: 120
  service:
    port: 80
    targetPort: 8080
  analysis:
    interval: 1m          # Évaluer les métriques toutes les 1 min
    threshold: 5           # Rollback après 5 échecs consécutifs
    maxWeight: 50          # Trafic canary maximum : 50%
    stepWeight: 10         # Incrément du trafic : +10% par interval
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500          # p99 < 500ms
        interval: 1m
    webhooks:
      - name: acceptance-test
        type: pre-rollout
        url: http://flagger-loadtester.test/
        timeout: 30s
        metadata:
          type: bash
          cmd: "curl -sd 'test' http://my-app-canary.production/health | grep -q ok"

Déclencher un déploiement canary

# Mettre à jour l'image du Deployment normalement
kubectl set image deployment/my-app my-app=ghcr.io/org/my-app:v2.0.0 -n production

# Flagger détecte le changement et démarre l'analyse automatiquement
kubectl get canary -n production --watch
# NAME     STATUS        WEIGHT   LASTTRANSITIONTIME
# my-app   Progressing   10       ...
# my-app   Progressing   20       ...
# my-app   Succeeded     0        ...

Blue-Green avec Flagger

spec:
  analysis:
    interval: 1m
    threshold: 1
    iterations: 5          # 5 analyses avant promotion
  # Pas de stepWeight/maxWeight = blue-green (100% d'un coup après analyse)
  service:
    port: 80
    targetPort: 8080

Mise à jour

helm repo update
helm upgrade flagger flagger/flagger \
  --namespace=istio-system \
  --reuse-values

Troubleshooting

# État des canary
kubectl get canaries -A

# Détails et événements d'un canary
kubectl describe canary my-app -n production

# Logs du contrôleur Flagger
kubectl logs -n istio-system -l app.kubernetes.io/name=flagger --tail=50

# Rollback manuel : revenir à l'image précédente dans le Deployment
# Flagger détecte le changement et reconcilie vers la version primary
kubectl set image deployment/my-app my-app=ghcr.io/org/my-app:v1.0.0 -n production

# Ou patcher le Canary pour passer en skipAnalysis et revenir manuellement
kubectl patch canary my-app -n production \
  --type merge -p '{"spec":{"skipAnalysis":true}}'

# Vérifier que les services primary et canary ont été créés
kubectl get svc -n production | grep my-app
# my-app, my-app-primary, my-app-canary

Ressources

• Site officiel : https://flagger.app
• Documentation : https://docs.flagger.app/
• GitHub : https://github.com/fluxcd/flagger
• Tutorials par provider : https://docs.flagger.app/tutorials/
• Releases : https://github.com/fluxcd/flagger/releases