troubleshooting6 min de lecture

Résoudre les échecs de déploiement Kubernetes : guide de dépannage complet

SFEIR Institute

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ômeStatut du podCause probableSection
Pods ne démarrent pasPendingRessources insuffisantesPods Pending
Crash répétésCrashLoopBackOffErreur applicative ou configCrashLoopBackOff
Image inaccessibleImagePullBackOffRegistry ou credentialsImagePullBackOff
Rollout bloquéProgressing=FalseProbes ou ressourcesRollout bloqué
Pod tuéOOMKilledMémoire insuffisanteOOMKilled

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'eventCauseVotre action
Insufficient cpuPas assez de CPU disponibleRéduisez vos requests ou ajoutez des nodes
Insufficient memoryPas assez de mémoireAjustez resources.requests.memory
node(s) had taintTaints bloquent le schedulingAjoutez les tolerations appropriées
no nodes availableAucun node dans le clusterVé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

ErreurVotre diagnosticSolution
manifest unknownTag inexistantVérifiez le tag avec docker pull image:tag
unauthorizedCredentials manquantsCréez un imagePullSecret
connection refusedRegistry inaccessibleTestez 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

  1. Configurez des PodDisruptionBudgets pour éviter les interruptions pendant les rollouts
  2. Utilisez des probes adaptées à votre application (liveness, readiness, startup)
  3. Définissez des resource requests et limits réalistes basées sur vos métriques
  4. 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 :

Contactez nos conseillers pour planifier votre formation et transformez vos échecs de déploiement en déploiements réussis.