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égie | Downtime | Rollback | Ressources | Complexité | Cas d'usage |
|---|---|---|---|---|---|
| Rolling Update | Zéro | Automatique | 1.25x | Faible | Défaut, apps stateless |
| Blue-Green | Zéro | Instantané | 2x | Moyenne | Zero-downtime critique |
| Canary | Zéro | Partiel | 1.1x | Élevée | Tests en production |
| Recreate | Oui | Manuel | 1x | Faible | Apps 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 situation | Stratégie recommandée |
|---|---|
| Application stateless standard | Rolling Update |
| Zéro downtime critique + budget ressources | Blue-Green |
| Validation progressive en production | Canary |
| Base de données / application stateful | Recreate |
| Migration majeure avec tests A/B | Canary + 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.
| Erreur | Symptôme | Solution |
|---|---|---|
| Pas de readinessProbe | Trafic vers pods non prêts | Ajoutez une probe HTTP/TCP |
| maxUnavailable=100% | Downtime pendant rolling | Limitez à 25% max |
| Pas de resource limits | Pods évincés | Définissez requests et limits |
| Image tag :latest | Version imprévisible | Utilisez des tags immutables |
| Pas de rollback testé | Panique en incident | Testez 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 :
- LFS458 Administration Kubernetes : 4 jours pour maîtriser rolling updates, blue-green et canary en conditions réelles
- LFD459 Kubernetes pour les développeurs d'applications : 3 jours pour intégrer vos déploiements dans vos pipelines CI/CD
- Kubernetes, les fondamentaux : 1 jour pour découvrir les concepts de base si vous débutez