Déploiements zéro-downtime avec Azure Kubernetes Service

Déployer des mises à jour en production sans impacter les utilisateurs est une exigence critique pour toute application moderne. Azure Kubernetes Service (AKS) fournit des primitives puissantes pour atteindre le zéro-downtime, mais elles doivent être configurées correctement.

Stratégie de Rolling Update

La stratégie de déploiement par défaut dans Kubernetes est le RollingUpdate, qui remplace progressivement les anciens pods par les nouveaux. Les paramètres clés à ajuster sont maxUnavailable et maxSurge :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      containers:
        - name: api
          image: myregistry.azurecr.io/web-api:v2.1.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 20

Définir maxUnavailable: 0 garantit qu'aucun pod existant n'est terminé avant qu'un nouveau ne soit prêt. Combiné avec maxSurge: 1, Kubernetes créera un pod supplémentaire à la fois, attendra qu'il passe les vérifications de readiness, puis terminera un ancien pod.

Les Health Checks sont indispensables

Sans readiness et liveness probes correctement configurées, Kubernetes n'a aucun moyen de savoir si votre nouveau pod sert réellement le trafic correctement. Une readiness probe conditionne le routage du trafic — un pod qui échoue à sa readiness probe ne recevra pas de requêtes du Service. Une liveness probe redémarre les pods bloqués ou en deadlock.

Pour les APIs, je recommande un endpoint /healthz dédié qui vérifie :

• La connectivité à la base de données
• La disponibilité du cache
• La santé des services en aval essentiels

func healthHandler(w http.ResponseWriter, r *http.Request) {
    if err := db.Ping(); err != nil {
        w.WriteHeader(http.StatusServiceUnavailable)
        json.NewEncoder(w).Encode(map[string]string{"status": "unhealthy", "reason": err.Error()})
        return
    }
    w.WriteHeader(http.StatusOK)
    json.NewEncoder(w).Encode(map[string]string{"status": "healthy"})
}

Pod Disruption Budgets

Lorsque AKS effectue des mises à jour de nœuds ou des opérations de scaling, il doit évincer des pods. Un PodDisruptionBudget (PDB) garantit qu'un nombre minimum de pods reste disponible pendant les disruptions volontaires :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web-api

Cela garantit qu'au moins 2 pods sont toujours en cours d'exécution, même pendant les opérations de maintenance des nœuds.

Rollbacks automatisés avec Flagger

Pour les workloads de production, j'utilise Flagger pour automatiser les déploiements canary sur AKS. Flagger transfère progressivement le trafic vers la nouvelle version tout en surveillant les métriques. Si les taux d'erreur ou la latence dépassent les seuils, il effectue automatiquement un rollback :

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: web-api
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-api
  progressDeadlineSeconds: 600
  analysis:
    interval: 30s
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m

Cette configuration augmente le trafic vers le canary de 10% toutes les 30 secondes, jusqu'à 50%, et effectue un rollback si le taux de succès descend en dessous de 99%.

Points clés à retenir

Les déploiements zéro-downtime sur AKS sont réalisables avec la bonne configuration. Les ingrédients essentiels sont des paramètres de rolling update adaptés, des health checks robustes, des pod disruption budgets, et idéalement une analyse canary automatisée. Ne déployez pas en production sans eux.