Pod Kubernetes : créer, observer et comprendre son cycle de vie

Un Pod est l'objet de base utilisé par Kubernetes pour exécuter un ou plusieurs conteneurs. Dans la majorité des cas, un Pod contient un seul conteneur. Ce guide vous montre comment créer un Pod, l'observer, comprendre son cycle de vie et diagnostiquer les problèmes les plus fréquents.

Prérequis : un cluster kind et kubectl configuré.

Ce que vous allez apprendre

• Créer un Pod avec kubectl run et avec un fichier YAML
• Observer un Pod : voir son état, lire ses logs, entrer dedans
• Comprendre le cycle de vie : phases, restartPolicy, CrashLoopBackOff
• Utiliser les init containers pour préparer l'environnement
• Diagnostiquer les problèmes : ImagePullBackOff, Pending, crash

Ce qu'est un Pod Kubernetes

Un Pod est la plus petite unité déployable dans Kubernetes. C'est l'objet que Kubernetes crée, planifie sur un nœud et surveille.

Pour un débutant, retenez simplement :

• Un Pod exécute vos conteneurs
• Kubernetes gère le Pod (démarrage, surveillance, redémarrage)
• Dans 80% des cas, un Pod = un conteneur

Pourquoi Kubernetes utilise des Pods

Pourquoi ne pas gérer directement les conteneurs ? Parce que certaines applications nécessitent plusieurs processus qui doivent :

• Partager la même adresse IP (ils communiquent via localhost)
• Partager les mêmes volumes (fichiers communs)
• Être co-localisés sur le même nœud
• Être démarrés et arrêtés ensemble

Le Pod est l'unité de scheduling : c'est lui que Kubernetes place sur un nœud, pas le conteneur individuel.

Même si un Pod peut contenir plusieurs conteneurs, vous utiliserez presque toujours des Pods mono-conteneur. Les Pods multi-conteneurs répondent à des cas précis, les sidecars et les init containers, tous deux traités plus bas dans ce guide.

Créer son premier Pod

Deux chemins mènent au même Pod. La méthode impérative tient en une commande et convient pour essayer, déboguer ou produire un squelette. La méthode déclarative passe par un fichier YAML que vous versionnez, et c'est celle que vous emploierez en équipe. Commencez par la première pour voir un Pod vivre, la seconde arrive juste après.

Méthode impérative : kubectl run

La façon la plus rapide de créer un Pod :

kubectl run mon-nginx --image=nginx:1.27-alpine

Résultat : un Pod nommé mon-nginx exécutant Nginx.

Vérifiez sa création :

kubectl get pods

Sortie

NAME        READY   STATUS    RESTARTS   AGE
mon-nginx   1/1     Running   0          10s

Méthode déclarative : fichier YAML

Pour un contrôle total, créez un fichier manifest :

mon-nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mon-nginx
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.27-alpine@sha256:65645c7bb6a0661892a8b03b89d0743208a18dd2f3f17a54ef4b76fb8e2f2a10
      ports:
        - containerPort: 80
  restartPolicy: Always

Appliquez-le :

kubectl apply -f mon-nginx.yaml

Vous n'avez pas besoin d'écrire ce YAML de mémoire. kubectl sait le produire pour vous, sans rien créer sur le cluster, ce qui est le point de départ le plus rapide pour un manifeste :

kubectl run mon-nginx --image=nginx:1.27-alpine --dry-run=client -o yaml

Observer et inspecter un Pod

Une fois votre Pod créé, vous voulez immédiatement savoir : est-ce qu'il tourne ? Où regarder ?

kubectl get : vue d'ensemble

kubectl get pods -o wide

Sortie

NAME        READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
mon-nginx   1/1     Running   0          8s    10.244.1.24   doc-k8s-worker   <none>           <none>

Les deux dernières colonnes restent vides tant que vous ne faites ni préemption ni readiness gates : ne vous en préoccupez pas pour l'instant.

Les colonnes importantes :

Colonne	Signification
READY	1/1 = 1 conteneur prêt sur 1 total
STATUS	Phase actuelle du Pod (Running, Pending...)
RESTARTS	Nombre de redémarrages du conteneur
IP	Adresse IP interne du Pod

Glissez pour voir

kubectl describe : détails complets

kubectl describe pod mon-nginx

Cette commande affiche :

• Conditions : états du Pod (PodScheduled, Initialized, Ready...)
• Containers : état de chaque conteneur
• Events : historique des actions (scheduling, pull d'image, démarrage...)

C'est la commande à lancer quand un Pod ne démarre pas. Les Events, en bas de la sortie, donnent presque toujours la raison : image introuvable, nœud sans ressource, volume en attente.

kubectl logs : voir les sorties

kubectl logs affiche ce que le conteneur écrit sur sa sortie standard. C'est là que se trouve le message d'erreur d'une application qui refuse de démarrer, et c'est donc la deuxième commande du diagnostic, juste après describe.

kubectl logs mon-nginx

Options utiles :

kubectl logs mon-nginx --tail=20      # Les 20 dernières lignes
kubectl logs mon-nginx --follow       # Flux en temps réel
kubectl logs mon-nginx --previous     # Logs du conteneur précédent (après crash)

kubectl exec : exécuter une commande

kubectl exec mon-nginx -- hostname
kubectl exec -it mon-nginx -- sh      # Shell interactif

L'option -it est indispensable pour une commande interactive, shell ou éditeur. Sans elle, la commande s'exécute mais vous ne pouvez rien y taper.

Anatomie d'un Pod

Maintenant que vous avez vu un Pod vivre, regardons sa structure YAML :

Champ	Description
metadata.name	Nom unique du Pod dans le namespace
metadata.labels	Étiquettes pour organiser et sélectionner
spec.containers[]	Liste des conteneurs (au moins un)
spec.containers[].image	Image à utiliser
spec.containers[].ports[]	Ports exposés (informatif)
spec.restartPolicy	Comportement au redémarrage

Glissez pour voir

Un Pod ne se modifie pas

Une fois créé, un Pod ne peut plus être modifié, à l'exception de quelques champs comme les labels. Pour changer l'image, il faut le supprimer et le recréer. C'est la première raison pour laquelle on ne gère pas des Pods à la main en production.

Cycle de vie d'un Pod

La phase d'un Pod résume en un mot où il en est de son existence, du moment où l'API l'accepte jusqu'à son arrêt. C'est la colonne STATUS de kubectl get pods, et la première chose à lire quand quelque chose ne va pas. Il n'en existe que cinq, et trois suffisent au quotidien.

Un Pod passe par plusieurs phases :

Phase	Signification
Pending	Pod accepté mais pas encore sur un nœud. En attente de scheduling ou de téléchargement d'image.
Running	Pod assigné à un nœud, au moins un conteneur tourne.
Succeeded	Tous les conteneurs ont terminé avec succès (exit code 0).
Failed	Au moins un conteneur a terminé en échec (exit code non-zéro).
Unknown	État indéterminé, souvent problème de communication avec le nœud.

Glissez pour voir

Pour voir la phase :

kubectl get pod mon-nginx -o jsonpath='{.status.phase}'

Phase du Pod vs état des conteneurs

Phase du Pod et état du conteneur ne sont pas la même chose

La phase du Pod est une vue synthétique, volontairement grossière. Pour comprendre ce qui se passe réellement, regardez les états des conteneurs dans kubectl describe. Un Pod peut rester en phase Running alors qu'un de ses conteneurs redémarre en boucle.

Chaque conteneur dans un Pod a son propre état :

État	Description
Waiting	En attente (pull d'image, init container en cours...)
Running	Le conteneur s'exécute
Terminated	Le conteneur s'est arrêté (succès ou échec)

Glissez pour voir

Attention : CrashLoopBackOff n'est pas une phase du Pod. C'est un état d'attente du conteneur visible dans la sortie de kubectl get pods. Il signifie que le conteneur a crashé plusieurs fois et que Kubernetes attend avant de le redémarrer.

restartPolicy : que fait Kubernetes quand un conteneur s'arrête

Le champ restartPolicy définit ce que Kubernetes fait quand un conteneur s'arrête :

Valeur	Comportement	Cas d'usage
Always (défaut)	Redémarre le conteneur quoi qu'il arrive	Services web, API
OnFailure	Redémarre seulement si exit code ≠ 0	Jobs de traitement batch
Never	Ne redémarre jamais	Tâches ponctuelles, debug

Glissez pour voir

Avec les applications classiques, vous verrez surtout Always. Les valeurs OnFailure et Never apparaissent plutôt sur des Pods ponctuels ou créés par un Job.

Exemple avec OnFailure

job-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: job-pod
spec:
  containers:
    - name: worker
      image: busybox:1.36@sha256:73aaf090f3d85aa34ee199857f03fa3a95c8ede2ffd4cc2cdb5b94e566b11662
      command: ['sh', '-c', 'echo "Traitement..." && exit 0']
  restartPolicy: OnFailure

Si le conteneur échoue (exit 1), Kubernetes le redémarre. S'il réussit (exit 0), le Pod passe en Succeeded.

Backoff exponentiel

Quand un conteneur échoue plusieurs fois, Kubernetes attend de plus en plus longtemps avant de le redémarrer :

• 1ère tentative : 10s
• 2ème : 20s
• 3ème : 40s
• Maximum : 5 minutes

C'est ce qui produit l'état CrashLoopBackOff.

Init containers : préparer l'environnement

Les init containers s'exécutent avant les conteneurs principaux. Ils sont plus simples à comprendre que les multi-conteneurs classiques car leur rôle est clair : préparer le terrain.

Cas d'usage

Un init container sert chaque fois qu'une condition doit être remplie avant que l'application démarre. Plutôt que d'inscrire cette attente dans le code applicatif, on la sort dans un conteneur dédié, qui a le droit d'échouer et d'être relancé sans conséquence.

• Attendre qu'un service soit prêt (base de données, API)
• Télécharger des fichiers de configuration
• Initialiser une base de données
• Vérifier des prérequis

Caractéristiques

Trois propriétés expliquent l'essentiel du comportement d'un init container, et notamment pourquoi un Pod peut rester bloqué en Init:0/1 sans jamais démarrer son application.

• S'exécutent séquentiellement (un après l'autre)
• Doivent tous réussir avant le démarrage des conteneurs principaux
• Peuvent utiliser des images différentes (avec des outils spécifiques)

Exemple : attendre un service

init-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.36@sha256:73aaf090f3d85aa34ee199857f03fa3a95c8ede2ffd4cc2cdb5b94e566b11662
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: app
      image: nginx:1.27-alpine@sha256:65645c7bb6a0661892a8b03b89d0743208a18dd2f3f17a54ef4b76fb8e2f2a10

Le Pod restera en Init:0/1 jusqu'à ce que db-service:5432 réponde :

kubectl get pod init-demo

Sortie pendant l'init

NAME        READY   STATUS     RESTARTS   AGE
init-demo   0/1     Init:0/1   0          5s

Pod mono-conteneur vs Pod multi-conteneur

La question revient vite : faut-il mettre plusieurs conteneurs dans un Pod ? La réponse par défaut est non. Le partage du réseau et des volumes est le seul argument qui justifie de les réunir, et il ne se présente que dans des cas précis.

Cas majoritaire : 1 Pod = 1 conteneur

Dans 80% des cas, un Pod contient un seul conteneur. C'est le pattern recommandé car :

• Plus simple à gérer
• Scaling indépendant
• Isolation des pannes

Quand utiliser plusieurs conteneurs

Les Pods multi-conteneurs servent à des cas spécifiques où les conteneurs doivent absolument partager réseau et volumes :

Pattern	Description	Exemple
Sidecar	Conteneur auxiliaire qui enrichit l'app principale	Agent de logs, proxy Envoy
Init container	Prépare l'environnement avant l'app	Attente d'une dépendance

Glissez pour voir

Les conteneurs d'un même Pod communiquent par localhost et partagent leurs volumes. Aucun Service n'est nécessaire entre eux, c'est précisément ce qui distingue un Pod multi-conteneur de deux Pods séparés.

Exemple : Pod avec sidecar

app-avec-sidecar.yaml

apiVersion: v1
kind: Pod
metadata:
  name: app-avec-sidecar
spec:
  containers:
    - name: app
      image: nginx:1.27-alpine@sha256:65645c7bb6a0661892a8b03b89d0743208a18dd2f3f17a54ef4b76fb8e2f2a10
      volumeMounts:
        - name: logs
          mountPath: /var/log/nginx
    - name: log-collector
      image: busybox:1.36@sha256:73aaf090f3d85aa34ee199857f03fa3a95c8ede2ffd4cc2cdb5b94e566b11662
      command: ['sh', '-c', 'tail -f /var/log/nginx/access.log']
      volumeMounts:
        - name: logs
          mountPath: /var/log/nginx
  volumes:
    - name: logs
      emptyDir: {}

Les deux conteneurs partagent le volume logs.

Ne commencez pas par là. Maîtrisez d'abord les Pods mono-conteneur ; les sidecars viendront quand un besoin réel les appellera, typiquement la centralisation des logs ou un service mesh.

Pourquoi éviter les Pods nus en production

Ne créez jamais de Pods directement en production. Passez toujours par un contrôleur, qui saura les recréer, les répliquer et les mettre à jour. La raison tient en une phrase : un Pod n'est surveillé par personne, et Kubernetes ne répare que ce qu'un contrôleur lui demande de maintenir.

Un Pod "nu" (créé directement avec kubectl run ou un YAML Pod) a plusieurs problèmes :

Problème	Conséquence
Pas de rescheduling	Si le nœud tombe, le Pod disparaît définitivement
Pas de réplicas	Un seul Pod = pas de haute disponibilité
Pas de rolling update	Impossible de mettre à jour sans interruption
Pas d'auto-scaling	Le nombre de Pods est fixe

Glissez pour voir

Ce qu'il faut utiliser

Contrôleur	Cas d'usage
Deployment	Applications stateless (API, web)
StatefulSet	Applications stateful (bases de données)
DaemonSet	Un Pod par nœud (agents de monitoring)
Job	Tâches batch ponctuelles
CronJob	Tâches planifiées

Glissez pour voir

Ces contrôleurs créent et gèrent les Pods pour vous, avec la résilience nécessaire.

Debug : de basique à avancé

Le diagnostic d'un Pod suit toujours le même ordre, du moins coûteux au plus intrusif. Les premières commandes ne touchent à rien et répondent déjà à la plupart des situations ; les suivantes entrent dans le conteneur, et ne servent qu'ensuite.

Commencez toujours par le basique

Ces quatre commandes se lancent dans cet ordre, et chacune répond à une question différente : où en est le Pod, ce que Kubernetes a tenté, ce que l'application a dit, puis ce que le conteneur contient.

1. Voir l'état :

   kubectl get pod mon-pod -o wide

2. Lire les événements :

   kubectl describe pod mon-pod | tail -20

3. Consulter les logs :

   kubectl logs mon-pod --tail=50

4. Entrer dans le conteneur (si possible) :

   kubectl exec -it mon-pod -- sh

Ces quatre commandes résolvent 90% des problèmes.

Surveiller les ressources

kubectl top pod mon-pod

Sortie

NAME      CPU(cores)   MEMORY(bytes)
mon-pod   3m           45Mi

kubectl top ne fonctionne pas sur un cluster nu. Il interroge le Metrics Server, qui n'est pas installé par défaut, ni sur kind ni sur un cluster kubeadm. Sans lui, la commande répond Metrics API not available.

Debug avancé : ephemeral containers

Si le conteneur n'a pas de shell (image distroless, scratch), utilisez un conteneur éphémère :

kubectl debug -it mon-pod --image=busybox:1.36@sha256:73aaf090f3d85aa34ee199857f03fa3a95c8ede2ffd4cc2cdb5b94e566b11662 --target=mon-conteneur

Le conteneur éphémère partage le namespace réseau et process du Pod ciblé.

kubectl debug vient en dernier, pas en premier

Les conteneurs éphémères sont un outil de dépannage ponctuel, pas un mode d'exploitation. Essayez d'abord get, describe, logs et exec : ces quatre commandes suffisent dans la très grande majorité des cas.

Dépannage : problèmes courants

Trois symptômes couvrent la très grande majorité des Pods qui ne démarrent pas. Chacun se reconnaît à la colonne STATUS, et pour chacun c'est la section Events de kubectl describe qui donne la cause exacte.

CrashLoopBackOff

Symptôme : Le Pod redémarre en boucle.

NAME      READY   STATUS             RESTARTS   AGE
mon-pod   0/1     CrashLoopBackOff   5          3m

Rappel : ce n'est pas une phase du Pod, mais un état d'attente visible dans STATUS.

Causes possibles :

1. L'application plante au démarrage (erreur de code)
2. Configuration manquante (variables d'environnement, secrets)
3. Dépendance non disponible (base de données, API)

Diagnostic :

kubectl logs mon-pod --previous   # Logs du crash précédent
kubectl describe pod mon-pod      # Voir le exit code

ImagePullBackOff

Symptôme : le Pod ne démarre pas et Kubernetes n'arrive pas à télécharger l'image. La séquence relevée sur un cluster est ContainerCreating, puis ErrImagePull au premier échec, puis ImagePullBackOff quand les tentatives s'espacent. Les deux derniers alternent ensuite à chaque nouvelle tentative : voir l'état changer sous vos yeux dans un kubectl get pods -w est normal, ce n'est pas deux pannes différentes.

Causes possibles :

1. Image inexistante ou mal orthographiée
2. Registry privée sans credentials
3. Problème réseau

Diagnostic :

kubectl describe pod mon-pod | grep -A 5 "Events"

Pending (bloqué)

Symptôme : le Pod reste en Pending sans jamais être placé sur un nœud. Il a bien été accepté par l'API, mais le scheduler n'a trouvé aucun nœud qui lui convienne, ou le kubelet attend encore une ressource.

Causes possibles :

1. Ressources insuffisantes sur les nœuds
2. Pas de nœud avec les bons labels/taints
3. Volume PVC en attente

Diagnostic :

kubectl describe pod mon-pod | grep -A 10 "Events"
kubectl get nodes -o wide
kubectl describe node <nom-du-noeud>

Testez vos connaissances

Sept questions pour vérifier que les notions de ce guide sont acquises : cycle de vie, restartPolicy, init containers et diagnostic des trois pannes les plus fréquentes.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Un Pod est l'unité minimale de Kubernetes : dans 80% des cas, 1 Pod = 1 conteneur
2. Les conteneurs d'un Pod partagent réseau (localhost) et volumes
3. Cycle de vie : Pending → Running → Succeeded/Failed
4. CrashLoopBackOff n'est pas une phase du Pod, mais un état d'attente du conteneur
5. restartPolicy : Always (défaut et le plus courant), OnFailure, Never
6. Les init containers s'exécutent avant les conteneurs principaux pour préparer l'environnement
7. Ne créez jamais de Pods nus en production : utilisez Deployments, StatefulSets ou Jobs
8. Debug : commencez par get, describe, logs, exec avant kubectl debug

FAQ : questions fréquentes sur les Pods

Ces questions reviennent souvent quand on découvre les Pods Kubernetes. Les réponses ci-dessous reprennent les points clés du guide, différence avec un conteneur, Pods multi-conteneurs, CrashLoopBackOff, init containers et cycle de vie.

Qu'est-ce qu'un Pod dans Kubernetes ?

Un Pod est la plus petite unité déployable de Kubernetes. Il exécute un ou plusieurs conteneurs qui partagent la même adresse IP et les mêmes volumes. Dans 80 % des cas, un Pod contient un seul conteneur.

Quelle est la différence entre un Pod et un conteneur ?

Un conteneur exécute une application ; un Pod est l'enveloppe Kubernetes autour d'un ou plusieurs conteneurs. Kubernetes ne gère jamais un conteneur seul, toujours à travers un Pod.

Un Pod peut-il contenir plusieurs conteneurs ?

Oui. Un Pod peut regrouper plusieurs conteneurs qui partagent réseau et volumes, par exemple une application et un sidecar. Mais dans la majorité des cas, un Pod ne contient qu'un seul conteneur.

Pourquoi ne faut-il pas créer de Pods directement en production ?

Un Pod nu n'est pas recréé s'il tombe : ni auto-réparation, ni montée en charge, ni rolling update. En production, on déclare un Deployment, un StatefulSet ou un Job qui gère les Pods pour vous.

Que signifie l'erreur CrashLoopBackOff ?

CrashLoopBackOff indique qu'un conteneur démarre puis plante en boucle. Kubernetes attend de plus en plus longtemps entre deux essais. Ce n'est pas une phase du Pod mais un état du conteneur, à diagnostiquer avec kubectl logs.

Qu'est-ce qu'un init container ?

Un init container s'exécute et se termine avant les conteneurs principaux du Pod. Il sert à préparer l'environnement : attendre une dépendance, télécharger un fichier, appliquer une migration de base de données.

Comment voir les logs d'un Pod ?

La commande kubectl logs nom-du-pod affiche la sortie d'un conteneur. Ajoutez -f pour suivre en direct, --previous pour les logs du conteneur précédent après un crash, et -c pour cibler un conteneur précis.

Quelles sont les phases du cycle de vie d'un Pod ?

Un Pod passe par les phases Pending, Running, puis Succeeded ou Failed. La phase est une vue synthétique : pour comprendre un blocage, regardez l'état détaillé des conteneurs avec kubectl describe.

Pour aller plus loin

• Les Services : L'exposition stable de Pods dont l'adresse IP change à chaque recréation.
• Les ConfigMaps : L'injection de configuration dans un Pod sans reconstruire son image.
• Définir les Probes : Les sondes qui décident si un conteneur est vivant et prêt à recevoir du trafic.

×

📖 Voir la documentation →