---
title: "Mon pod est en erreur"
description: "Diagnostiquer et corriger les trois états d'échec les plus courants : CrashLoopBackOff, ImagePullBackOff et OOMKilled — avec les causes spécifiques à Kontainers."
source_url:
  html: https://docs.blackswift.cloud/depanner/pod-en-erreur/
  md: https://docs.blackswift.cloud/depanner/pod-en-erreur.md
---

# Mon pod est en erreur

> Diagnostiquer et corriger les trois états d'échec les plus courants : CrashLoopBackOff, ImagePullBackOff et OOMKilled — avec les causes spécifiques à Kontainers.

Votre pod apparaît dans `kubectl get pods`, mais son statut n'est pas `Running`
(ou il redémarre en boucle). Cette page couvre les trois cas les plus fréquents,
avec les causes propres à Kontainers qu'un habitué d'un autre cluster ne
devinerait pas.

Commencez toujours par :

```bash
kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
```

## CrashLoopBackOff

**Le conteneur démarre puis s'arrête, en boucle.** Kubernetes espace les
redémarrages (`back-off`), d'où des périodes d'attente croissantes.

C'est presque toujours votre application qui se termine : configuration manquante,
dépendance injoignable, erreur au boot. Les logs de l'exécution précédente
(`--previous`) contiennent la vraie erreur.

Vérifiez notamment :

- une variable d'environnement ou un secret manquant
  ([ConfigMaps et Secrets](https://docs.blackswift.cloud/deployer/configmaps-et-secrets.md)) ;
- une dépendance pas encore prête (base de données…) — ajoutez une
  `readinessProbe` et laissez le pod redémarrer, ou un `initContainer` d'attente ;
- une dépendance dans un namespace d'une **autre organisation** : bloquée par
  design ([isolation réseau](https://docs.blackswift.cloud/comprendre/isolation-reseau.md)).

## ImagePullBackOff

**L'image ne peut pas être téléchargée.**

```bash
kubectl describe pod <pod> -n <namespace> | grep -A3 "Failed"
```

Causes classiques : nom d'image mal orthographié, tag inexistant, registre privé
sans pull secret.

:::caution[Spécificité Kontainers]
`imagePullPolicy` est [forcé à `Always`](https://docs.blackswift.cloud/reference/mutations-et-politiques.md) :
l'image est re-vérifiée auprès du registre **à chaque démarrage**, même si elle est
déjà sur le nœud. Conséquence : **un token de registre expiré ou un registre en
panne empêche vos pods de redémarrer** — y compris ceux qui tournaient très bien
jusque-là. Si un pod qui n'a pas changé tombe en `ImagePullBackOff`, vérifiez
d'abord votre registre et la validité de votre pull secret.
:::

## OOMKilled

**Le conteneur a dépassé sa mémoire allouée et a été tué.** Repérable dans
`describe pod` :

```text
Last State:  Terminated
  Reason:    OOMKilled
```

:::caution[Spécificité Kontainers — lisez avant d'augmenter la limite]
Sur Kontainers, [la limite mémoire est toujours égale à la request](https://docs.blackswift.cloud/reference/mutations-et-politiques.md#limitsmemory--requestsmemory).
Le réflexe habituel « j'augmente `limits.memory` » **ne fonctionne pas** : la
limite serait ramenée à la request. Pour donner plus de mémoire à votre conteneur,
**augmentez `requests.memory`** :

```yaml
resources:
  requests:
    memory: 512Mi   # ← c'est cette valeur qui fait foi (et qui est facturée)
```
:::

Dimensionnez la request sur le pic réel de consommation, visible dans votre
[monitoring](https://docs.blackswift.cloud/operer/acceder-au-monitoring.md) ou via :

```bash
kubectl top pods -n <namespace>
```

## Ce n'est pas l'un de ces trois cas ?

- Aucun pod ne se crée du tout → [Checklist de diagnostic](https://docs.blackswift.cloud/depanner/checklist-de-diagnostic.md#aucun-pod-ne-se-crée) ;
- Le pod tourne mais l'application est injoignable → [Checklist : site injoignable](https://docs.blackswift.cloud/depanner/checklist-de-diagnostic.md#site-injoignable-ou-certificat-absent) ;
- Toujours bloqué → [contactez le support](https://docs.blackswift.cloud/depanner/contacter-le-support.md) avec
  la sortie de `kubectl describe pod` et les logs.