Déploiement Canary Intelligent : Sécurisez vos mises en production avec Argo Rollouts et Prometheus

INTRODUCTION

Le déploiement standard RollingUpdate de Kubernetes a un défaut majeur : il est aveugle. Il remplace les pods tant que les probes de santé (liveness/readiness) passent, même si votre application renvoie massivement des erreurs 500 fonctionnelles.

Pour pallier ce risque, Argo Rollouts introduit le concept de "Progressive Delivery". Ce guide technique vous montre comment configurer un déploiement Canary qui analyse vos métriques Prometheus en temps réel et interrompt automatiquement le déploiement à la moindre anomalie, avant que vos utilisateurs ne soient impactés.

Prérequis

Avant de manipuler les manifestes, assurez-vous de disposer de l'environnement suivant :

Un cluster Kubernetes (v1.23+ recommandé) avec droits d'administration.
Kubectl configuré pour votre cluster.
Helm (v3+) installé sur votre poste.
Prometheus actif dans le cluster (ex: kube-prometheus-stack) scrapant déjà vos applications.
Le contrôleur Argo Rollouts installé (voir étape 1).

Tutoriel pas à pas

1. Installation du contrôleur Argo Rollouts

Si ce n'est pas déjà fait, installez le contrôleur et les CRDs nécessaires (Rollout, AnalysisTemplate).

# Création du namespace dédié
kubectl create namespace argo-rollouts

# Ajout du repo et installation via Helm
helm repo add argo https://argoproj.github.io/argo-helm
helm install argo-rollouts argo/argo-rollouts --namespace argo-rollouts

# Installation du plugin kubectl (Optionnel mais recommandé pour la visualisation)
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
sudo mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

2. Définition de l'AnalysisTemplate (Le Cerveau)

Ce template définit comment Argo juge la santé de la nouvelle version. Nous allons configurer une règle qui échoue si le taux d'erreurs 500 dépasse 1%.

Créez un fichier analysis-template.yaml :

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-check
  namespace: default
spec:
  args:
  - name: service-name
  metrics:
  - name: error-rate
    # Succès si le résultat est inférieur à 1% (0.01)
    successCondition: result[0] < 0.01
    failureLimit: 3
    provider:
      prometheus:
        # Adaptez l'URL selon votre installation Prometheus interne
        address: http://prometheus-server.monitoring.svc.cluster.local:9090
        query: |
          sum(irate(http_requests_total{status=~"5.*", service="{{args.service-name}}"}[2m])) 
          / 
          sum(irate(http_requests_total{service="{{args.service-name}}"}[2m]))

3. Création du Service Kubernetes

Le service cible les pods gérés par le Rollout. Contrairement à un déploiement Blue/Green complexe, un simple service suffit ici car Argo Rollouts manipule les ReplicaSets.

Créez un fichier service.yaml :

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
  namespace: default
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: my-app

4. Déploiement du Rollout

Le Rollout remplace la ressource Deployment standard. La section strategy est le cœur du système : elle orchestre l'augmentation du trafic, les pauses et les analyses.

Créez un fichier rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app-rollout
  namespace: default
spec:
  replicas: 5
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: argoproj/rollouts-demo:blue # Image de démo qui change de couleur
        ports:
        - containerPort: 8080
  strategy:
    canary:
      # Référence au template créé à l'étape 2
      analysis:
        templates:
        - templateName: error-rate-check
        args:
        - name: service-name
          value: my-app-svc
      steps:
      # Étape 1 : 20% du trafic sur la nouvelle version
      - setWeight: 20
      # Étape 2 : Pause de 1 minute pour laisser les métriques arriver
      - pause: {duration: 1m}
      # Étape 3 : Analyse explicite (en plus de l'analyse continue en background)
      - analysis:
          templates:
          - templateName: error-rate-check
          args:
          - name: service-name
            value: my-app-svc
      # Étape 4 : Montée à 50%
      - setWeight: 50
      - pause: {duration: 30s}
      # Étape 5 : Bascule totale
      - setWeight: 100

Appliquez les fichiers :

kubectl apply -f analysis-template.yaml
kubectl apply -f service.yaml
kubectl apply -f rollout.yaml

Visualisation du flux

Voici comment Argo Rollouts gère le cycle de vie de votre application :

📊 Chargement du diagramme...

Sécurité 🔐

Un pipeline de déploiement robuste doit être sécurisé :

RBAC (Least Privilege) : Restreignez les droits de modification des objets Rollout. Seule votre CI/CD et les admins doivent pouvoir exécuter kubectl argo rollouts promote.
Ségrégation des Secrets : Si votre AnalysisTemplate doit requêter un Prometheus protégé par authentification, utilisez un Secret Kubernetes référencé dans la configuration du provider. Ne mettez jamais de tokens en clair dans le YAML.
Provenance des images : Couplez Argo Rollouts avec un admission controller (type Kyverno ou OPA Gatekeeper) pour garantir que seules les images de votre registre privé sont déployées.

Observabilité 📈

Argo Rollouts offre une excellente visibilité, mais elle doit être intégrée à vos outils.

Plugin kubectl (Le cockpit) : C'est l'outil indispensable pour suivre le déploiement en direct.
```
kubectl argo rollouts get rollout my-app-rollout -n default --watch
```
Métriques Argo : Le contrôleur expose des métriques sur le port 8090. Configurez Prometheus pour scraper ces données et créez des alertes sur rollout_reconcile_error ou rollout_info pour tracker le taux de succès des déploiements.

Tests et Validation ✅

Ne déployez pas à l'aveugle.

Linting : Validez la syntaxe avant le commit.

kubectl argo rollouts lint -f rollout.yaml

Smoke Test PromQL : Vérifiez toujours que votre requête Prometheus renvoie des données (et non NaN ou No Data) avant de lancer le Rollout. Si la métrique est vide, l'analyse échouera (ou passera à tort selon la config).

Rollback / Plan B ↩️

C'est la force majeure d'Argo Rollouts : l'automatisation de l'échec.

Automatique : Si l'analyse Prometheus détecte > 1% d'erreurs, le Rollout passe en état Degraded. Le trafic rebascule instantanément à 100% sur la version stable (stableRS) et le déploiement de la nouvelle version est stoppé.

Manuel : Si vous détectez un bug fonctionnel (non visible via les erreurs 500), annulez manuellement :

kubectl argo rollouts abort my-app-rollout
# Puis retour à la version stable pour nettoyer
kubectl argo rollouts undo my-app-rollout

Erreurs fréquentes & Diagnostics

Symptôme : L'analyse reste en Pending ou Error.
- Cause : L'URL de Prometheus est inaccessible depuis le contrôleur Argo ou la requête PromQL est syntaxiquement incorrecte.
- Solution : Vérifiez les logs du pod argo-rollouts-controller.
Symptôme : Le Rollout ne progresse pas après le step 1.
- Cause : Vous avez défini pause: {} sans durée. Le Rollout attend une promotion manuelle.
- Solution : Exécutez kubectl argo rollouts promote my-app-rollout.

Checklist de mise en prod

La requête PromQL dans l'AnalysisTemplate retourne une valeur cohérente (ex: 0 ou 0.001).
Le Service Kubernetes pointe vers les sélecteurs gérés par le Rollout.
Les quotas (CPU/RAM) permettent de faire tourner temporairement Canary + Stable (surcoût temporaire).
Une alerte Slack/Teams est configurée sur les événements RolloutAborted.

FAQ

Q: Argo Rollouts fonctionne-t-il avec Istio ou Nginx Ingress ? R: Oui. Ce tutoriel montre la méthode "Basic" (basée sur le nombre de réplicas). Argo s'intègre nativement avec Istio, Nginx, AWS ALB ou SMI pour faire du "Traffic Splitting" fin au niveau de la couche réseau (pourcentages précis de requêtes), ce qui est bien plus précis.

Q: Puis-je utiliser Argo Rollouts sans Prometheus ? R: Oui. Vous pouvez utiliser des pauses manuelles ou d'autres providers (Datadog, NewRelic, Job Kubernetes, Webhooks), mais vous perdez l'automatisation basée sur les métriques open-source.

Conclusion

Vous avez maintenant remplacé un déploiement binaire et risqué par un processus progressif et mesuré. L'intégration d'Argo Rollouts avec Prometheus permet de détecter les régressions techniques bien plus vite qu'un humain.

Pour aller plus loin, intégrez ces manifestes dans votre dépôt Git (approche GitOps) et laissez Argo CD synchroniser l'état de vos Rollouts pour une chaîne de déploiement 100% automatisée.

Déploiements Canary automatisés avec Argo Rollouts et Prometheus