Sévérité : ÉlevéeKubernetes

Pod Kubernetes en CrashLoopBackOff après un déploiement

```text
NAME                   READY   STATUS             RESTARTS
api-7c9f6d8b9-x2k4p    0/1     CrashLoopBackOff   6
Last State: Terminated  Reason: OOMKilled  Exit Code: 137
```

Détecter

Après un kubectl apply, les nouveaux pods redémarrent en boucle ; le rollout reste bloqué et l'ancienne version sert encore une partie du trafic.

Symptômes

Après un kubectl apply, les nouveaux pods redémarrent en boucle ; le rollout reste bloqué et l'ancienne version sert encore une partie du trafic.

Environnement

Deployment avec sondes liveness/readiness, configuration via ConfigMap et Secret, limites mémoire.

Cause racine

Causes fréquentes : variable d'environnement ou Secret manquant (l'application quitte au démarrage), limite mémoire trop basse (OOMKilled, code 137), liveness probe trop agressive qui tue un démarrage lent, commande d'entrée erronée.

Diagnostic

kubectl describe pod api-7c9f6d8b9-x2k4p     # Events, Last State, Reason, Exit Code
kubectl logs api-7c9f6d8b9-x2k4p --previous  # journaux du conteneur précédent
kubectl get events --sort-by=.lastTimestamp | tail

Exit code	Signification
1	erreur applicative (lire les logs)
137	tué (OOMKilled ou liveness)
139	segfault

Solution

Corriger la cause (Secret, limite mémoire, startupProbe pour les démarrages lents) ; si la production est impactée, revenir en arrière d'abord : kubectl rollout undo deploy/api.

Commandes

kubectl rollout status deploy/api
kubectl rollout undo deploy/api
kubectl set resources deploy/api --limits=memory=768Mi

Prévention

maxUnavailable: 0, validation en préproduction, startupProbe, supervision des redémarrages, déploiement progressif avec analyse automatique.