Points clés
- ✓60% du temps de gestion cluster est consacré au troubleshooting (Spectro Cloud 2025)
- ✓'Les 4 causes d''échec: erreurs d''image, ressources, configuration, probes'
- ✓Diagnostic résolu en <15 minutes avec les commandes kubectl adaptées
TL;DR : Un échec de déploiement Kubernetes désigne toute situation où vos pods ne passent pas à l'état Running ou où votre rollout reste bloqué. Les causes principales sont les erreurs d'image, les ressources insuffisantes, les mauvaises configurations et les problèmes de probes. Ce guide vous donne les commandes exactes pour diagnostiquer et résoudre chaque type d'échec en moins de 15 minutes.
Pour maîtriser ces compétences de dépannage, découvrez la formation LFS458 Administration Kubernetes.
Pourquoi vos déploiements échouent en 2026
Résoudre les échecs de déploiement Kubernetes représente une compétence critique pour tout ingénieur logiciel. Selon le rapport Spectro Cloud State of Kubernetes 2025, plus de 60% du temps de gestion des clusters est consacré au troubleshooting. Plus inquiétant encore, les équipes IT passent en moyenne 34 jours ouvrés par an à résoudre des problèmes Kubernetes.
Avec 82% des utilisateurs de conteneurs qui exécutent désormais Kubernetes en production, vous devez maîtriser ces techniques de diagnostic pour maintenir vos SLA.
À retenir : Un échec de déploiement coûte en moyenne 2 à 4 heures de productivité. Avec ce guide, vous réduirez ce temps à moins de 15 minutes.
Index des symptômes et solutions rapides
Avant de plonger dans les détails, identifiez votre symptôme dans ce tableau pour accéder directement à la solution :
| Symptôme | Statut du pod | Cause probable | Section |
|---|---|---|---|
| Pods ne démarrent pas | Pending | Ressources insuffisantes | Pods Pending |
| Crash répétés | CrashLoopBackOff | Erreur applicative ou config | CrashLoopBackOff |
| Image inaccessible | ImagePullBackOff | Registry ou credentials | ImagePullBackOff |
| Rollout bloqué | Progressing=False | Probes ou ressources | Rollout bloqué |
| Pod tué | OOMKilled | Mémoire insuffisante | OOMKilled |
Commandes de diagnostic essentielles
Avant d'investiguer, exécutez ces commandes pour obtenir une vue d'ensemble de votre déploiement :
# Vérifier le statut du déploiement
kubectl rollout status deployment/votre-app -n votre-namespace
# Lister les pods avec leur statut détaillé
kubectl get pods -n votre-namespace -o wide
# Voir les events récents (triés par date)
kubectl get events -n votre-namespace --sort-by='.lastTimestamp' | tail -20
# Décrire le déploiement pour voir les conditions
kubectl describe deployment/votre-app -n votre-namespace
Ces commandes constituent votre checklist d'observabilité Kubernetes de base. Pour un monitoring plus avancé, consultez notre comparatif Prometheus vs Datadog.
Pods en Pending : ressources et scheduling
Symptôme
NAME READY STATUS RESTARTS AGE
votre-app-7d4f 0/1 Pending 0 5m
Diagnostic
Examinez les events pour identifier pourquoi le scheduler ne place pas votre pod :
kubectl describe pod votre-app-7d4f -n votre-namespace | grep -A15 "Events:"
Causes et solutions
| Message d'event | Cause | Votre action |
|---|---|---|
Insufficient cpu | Pas assez de CPU disponible | Réduisez vos requests ou ajoutez des nodes |
Insufficient memory | Pas assez de mémoire | Ajustez resources.requests.memory |
node(s) had taint | Taints bloquent le scheduling | Ajoutez les tolerations appropriées |
no nodes available | Aucun node dans le cluster | Vérifiez vos nodes avec kubectl get nodes |
Solution pour ressources insuffisantes
# Vérifiez vos requests actuelles
spec:
containers:
- name: app
resources:
requests:
memory: "128Mi" # Réduisez si possible
cpu: "100m"
limits:
memory: "256Mi"
cpu: "500m"
Commande pour voir la capacité disponible :
kubectl describe nodes | grep -A5 "Allocated resources"
À retenir : Vos requests déterminent le scheduling. Si vous demandez 4Gi de RAM mais que vos nodes n'ont que 2Gi disponibles, votre pod restera en Pending indéfiniment.
ImagePullBackOff : problèmes de registry
Symptôme
NAME READY STATUS RESTARTS AGE
votre-app-8k2m 0/1 ImagePullBackOff 0 3m
Diagnostic
# Voir le message d'erreur exact
kubectl describe pod votre-app-8k2m | grep -A5 "Warning.*Failed"
Causes et solutions
| Erreur | Votre diagnostic | Solution |
|---|---|---|
manifest unknown | Tag inexistant | Vérifiez le tag avec docker pull image:tag |
unauthorized | Credentials manquants | Créez un imagePullSecret |
connection refused | Registry inaccessible | Testez l'accès réseau au registry |
Créer un imagePullSecret
Si vous utilisez un registry privé, configurez vos credentials :
kubectl create secret docker-registry mon-registry-secret \
--docker-server=votre-registry.io \
--docker-username=votre-user \
--docker-password=votre-password \
-n votre-namespace
Puis référencez-le dans votre déploiement :
spec:
imagePullSecrets:
- name: mon-registry-secret
Respectez les bonnes pratiques de conteneurisation pour éviter ces problèmes.
Rollout bloqué : analyser et débloquer
Symptôme
Votre déploiement reste bloqué avec un rollout rollback deployment Kubernetes qui ne progresse pas :
$ kubectl rollout status deployment/votre-app
Waiting for deployment "votre-app" rollout to finish: 1 old replicas are pending termination...
Diagnostic
# Voir les conditions du déploiement
kubectl get deployment votre-app -o jsonpath='{.status.conditions[*].message}'
# Comparer les ReplicaSets
kubectl get rs -n votre-namespace | grep votre-app
Solutions selon la cause
Probes trop strictes : Si vos nouveaux pods échouent les healthchecks, le rollout ne termine jamais.
# Vérifier les probes
kubectl get pod votre-app-xxx -o jsonpath='{.spec.containers[0].readinessProbe}'
Ajustez vos probes si nécessaire :
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30 # Augmentez si votre app démarre lentement
periodSeconds: 10
failureThreshold: 3
Rollback d'urgence si vous devez revenir à la version précédente :
# Voir l'historique des révisions
kubectl rollout history deployment/votre-app
# Rollback à la révision précédente
kubectl rollout undo deployment/votre-app
# Ou rollback à une révision spécifique
kubectl rollout undo deployment/votre-app --to-revision=2
À retenir : Selon Mend.io, 67% des organisations ont retardé des déploiements à cause de problèmes de sécurité ou de configuration Kubernetes. Testez vos manifests dans un environnement de staging avant la production.
OOMKilled : gestion mémoire
Symptôme
$ kubectl describe pod votre-app-xxx | grep -i oom
Reason: OOMKilled
Diagnostic
# Voir la consommation mémoire actuelle
kubectl top pod votre-app-xxx
# Voir les limits configurées
kubectl get pod votre-app-xxx -o jsonpath='{.spec.containers[0].resources.limits.memory}'
Solution
Augmentez votre limit mémoire ou optimisez votre application :
resources:
requests:
memory: "256Mi"
limits:
memory: "512Mi" # Augmentez cette valeur
Pour un développeur Full-Stack Kubernetes, comprendre la gestion des ressources est essentiel. La formation LFD459 couvre ces aspects en détail.
Centraliser vos logs pour un diagnostic efficace
Pour exploiter la puissance de Kubernetes, centralisez vos logs.
Consultez notre comparatif Loki vs Elasticsearch pour choisir votre solution. Une stack d'observabilité complète avec Prometheus et Grafana, adoptée par 67% des organisations en production, vous permet de détecter les problèmes avant qu'ils n'impactent vos utilisateurs.
# Voir les logs de tous les pods d'un déploiement
kubectl logs -l app=votre-app --all-containers=true -f
# Logs des pods précédents (après un crash)
kubectl logs votre-app-xxx --previous
Prévenir les échecs de déploiement
Checklist pré-déploiement
Validez systématiquement avant chaque déploiement :
# Valider la syntaxe YAML
kubectl apply --dry-run=client -f deployment.yaml
# Tester dans un namespace de staging
kubectl apply -f deployment.yaml -n staging
# Vérifier les quotas du namespace
kubectl describe quota -n votre-namespace
Bonnes pratiques
- Configurez des PodDisruptionBudgets pour éviter les interruptions pendant les rollouts
- Utilisez des probes adaptées à votre application (liveness, readiness, startup)
- Définissez des resource requests et limits réalistes basées sur vos métriques
- Testez vos images localement avant de les pousser
Pour approfondir ces pratiques, consultez notre guide complet de formation Kubernetes et explorez les modules de monitoring et dépannage Kubernetes.
Développez vos compétences de dépannage
Un ingénieur logiciel préparant la formation LFS458 Administration Kubernetes acquiert les compétences pratiques pour diagnostiquer et résoudre ces problèmes efficacement. La formation administrateur système Kubernetes constitue également une excellente base.
Passez à l'action avec les formations SFEIR Institute :
- LFS458 Administration Kubernetes : 4 jours pour maîtriser l'administration et le dépannage de clusters
- LFD459 Kubernetes pour les développeurs : 3 jours pour déployer vos applications sans erreurs
- Kubernetes les fondamentaux : 1 journée pour découvrir les bases si vous débutez
Contactez nos conseillers pour planifier votre formation et transformez vos échecs de déploiement en déploiements réussis.