Aide-mémoire5 min de lecture

Stratégies de déploiement Kubernetes : tableau comparatif complet

SFEIR Institute

Points clés

  • 'Rolling Update: mise à jour progressive sans downtime, rollback automatique'
  • Blue-Green : deux environnements complets, bascule instantanée, consomme 2x les ressources
  • Canary : déploiement graduel, test sur sous-ensemble, détection précoce des problèmes
TL;DR : Les stratégies de déploiement Kubernetes (Rolling Update, Blue-Green, Canary, Recreate) déterminent comment vous mettez à jour vos applications en production. Ce tableau comparatif vous permet de choisir la bonne stratégie selon votre tolérance au risque, vos ressources disponibles et vos exigences de disponibilité.

Ces compétences sont au cœur de la LFS458 Administration Kubernetes.

Tableau comparatif des stratégies de déploiement Kubernetes

Avec 82% des utilisateurs de conteneurs qui exécutent Kubernetes en production, maîtriser vos stratégies de déploiement est essentiel. Consultez ce tableau avant chaque mise en production.

StratégieDowntimeRollbackRessourcesComplexitéCas d'usage
Rolling UpdateZéroAutomatique1.25xFaibleDéfaut, apps stateless
Blue-GreenZéroInstantané2xMoyenneZero-downtime critique
CanaryZéroPartiel1.1xÉlevéeTests en production
RecreateOuiManuel1xFaibleApps stateful, DB
À retenir : Si vous débutez, utilisez Rolling Update par défaut. C'est la stratégie native de Kubernetes, intégrée dans chaque Deployment.

Comment configurer Rolling Update (stratégie par défaut)

Rolling Update est la stratégie de déploiement Kubernetes que vous utilisez implicitement. Kubernetes remplace vos pods progressivement.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Pods supplémentaires pendant update
      maxUnavailable: 1  # Pods indisponibles max
  template:
    spec:
      containers:
      - name: app
        image: mon-app:v2
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 3

Vérifiez le déroulement de votre rolling update :

# Suivre le déploiement en temps réel
kubectl rollout status deployment/mon-app

# Historique des versions
kubectl rollout history deployment/mon-app

# Rollback immédiat si problème
kubectl rollout undo deployment/mon-app

Pour les commandes kubectl complètes, consultez l'aide-mémoire kubectl.

Comment implémenter Blue-Green Deployment

Blue-Green Deployment vous offre un rollback instantané. Vous maintenez deux environnements identiques et basculez le trafic via le Service.

# Service pointant vers l'environnement actif
apiVersion: v1
kind: Service
metadata:
  name: mon-app
spec:
  selector:
    app: mon-app
    version: blue  # Basculez vers 'green' pour switcher
  ports:
  - port: 80
    targetPort: 8080
# Déployer la nouvelle version (green)
kubectl apply -f deployment-green.yaml

# Vérifier que green fonctionne
kubectl get pods -l version=green

# Basculer le trafic
kubectl patch service mon-app -p '{"spec":{"selector":{"version":"green"}}}'

# Rollback instantané si nécessaire
kubectl patch service mon-app -p '{"spec":{"selector":{"version":"blue"}}}'
À retenir : Blue-Green double vos ressources nécessaires. Réservez cette stratégie aux applications critiques où vous ne pouvez pas vous permettre d'interruption.

Comment configurer Canary Deployment

Canary vous permet de tester en production sur un pourcentage de votre trafic. Intégrez cette approche dans votre pipeline CI/CD.

# Deployment canary (10% du trafic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-app-canary
spec:
  replicas: 1  # 1 pod canary pour 9 pods stable = 10%
  template:
    metadata:
      labels:
        app: mon-app
        track: canary
    spec:
      containers:
      - name: app
        image: mon-app:v2-candidate
# Surveiller les métriques du canary
kubectl logs -l track=canary -f

# Augmenter progressivement (scale canary, scale down stable)
kubectl scale deployment mon-app-canary --replicas=3
kubectl scale deployment mon-app-stable --replicas=7

# Promouvoir le canary en stable
kubectl set image deployment/mon-app-stable app=mon-app:v2-candidate
kubectl delete deployment mon-app-canary

Vos stratégies de déploiement constituent les primitives de l'orchestration Kubernetes.

Quand utiliser Recreate ?

Recreate supprime tous les pods avant de créer les nouveaux. Utilisez cette stratégie uniquement pour les applications stateful ou les bases de données.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ma-database
spec:
  strategy:
    type: Recreate  # Arrêt complet avant redémarrage
  template:
    spec:
      containers:
      - name: postgres
        image: postgres:15
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
À retenir : Recreate implique un downtime. Préférez cette stratégie pour les applications qui ne supportent pas plusieurs versions simultanées.

Choisir votre stratégie de déploiement Kubernetes

Les équipes IT passent 34 jours ouvrés par an à résoudre des problèmes Kubernetes. Choisissez la bonne stratégie pour réduire ce temps.

Votre situationStratégie recommandée
Application stateless standardRolling Update
Zéro downtime critique + budget ressourcesBlue-Green
Validation progressive en productionCanary
Base de données / application statefulRecreate
Migration majeure avec tests A/BCanary + Feature Flags

Arbre de décision rapide

Votre app supporte plusieurs versions simultanées ?
├── NON → Recreate
└── OUI → Vous avez 2x les ressources ?
          ├── OUI → Blue-Green (rollback instantané)
          └── NON → Vous voulez tester sur un % d'utilisateurs ?
                    ├── OUI → Canary
                    └── NON → Rolling Update

Erreurs courantes à éviter

Ces pièges affectent fréquemment les équipes qui configurent leurs déploiements. Vérifiez ces points avant de déployer.

ErreurSymptômeSolution
Pas de readinessProbeTrafic vers pods non prêtsAjoutez une probe HTTP/TCP
maxUnavailable=100%Downtime pendant rollingLimitez à 25% max
Pas de resource limitsPods évincésDéfinissez requests et limits
Image tag :latestVersion imprévisibleUtilisez des tags immutables
Pas de rollback testéPanique en incidentTestez kubectl rollout undo
# Vérifier vos probes avant déploiement
kubectl get deployment mon-app -o jsonpath='{.spec.template.spec.containers[0].readinessProbe}'

# Valider les resources
kubectl describe deployment mon-app | grep -A4 "Limits:\|Requests:"

Pour diagnostiquer vos déploiements, consultez le guide Monitoring et dépannage Kubernetes.

Intégration avec GitOps

GitOps automatise vos stratégies de déploiement. Configurez ArgoCD ou Flux pour appliquer vos manifests automatiquement.

# Exemple ArgoCD Application avec Canary
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: mon-app
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 10m}
      - setWeight: 100

Pour combiner stratégies de déploiement et autoscaling, dimensionnez vos HPA en fonction des pics de trafic post-déploiement.

À retenir : Avec 80% des organisations exécutant 20+ clusters en production, automatisez vos déploiements via GitOps plutôt que de gérer manuellement chaque cluster.

Passez à la pratique

La Formation Kubernetes : Guide Complet vous accompagne depuis les fondamentaux pour administrateur système jusqu'aux stratégies de déploiement avancées.

Formez-vous aux stratégies de déploiement Kubernetes :