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 Kubernetes fonctionnel (K3d, minikube ou autre) 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

Analogie

Pensez au Pod comme à une “enveloppe” autour de votre conteneur. Kubernetes ne manipule pas directement les conteneurs : il manipule des Pods.

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.

Cas courant

Même si un Pod peut contenir plusieurs conteneurs, vous utiliserez presque toujours des Pods mono-conteneur. Les Pods multi-conteneurs servent à des cas spécifiques (sidecars, init containers).

Créer son premier Pod

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
      ports:
        - containerPort: 80
  restartPolicy: Always

Appliquez-le :

kubectl apply -f mon-nginx.yaml

Générer le YAML

Pour voir le YAML sans créer le Pod : 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
mon-nginx   1/1     Running   0          2m    10.42.0.8   k3d-doc-k8s-server-0

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…)

Quand utiliser describe

Utilisez kubectl describe quand un Pod ne démarre pas. Les Events en bas de la sortie expliquent souvent le problème.

kubectl logs : voir les sorties

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

Attention

-it est nécessaire pour les commandes interactives (shell, éditeur…).

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

Limitation importante

Un Pod ne peut pas être modifié une fois créé (sauf pour quelques champs comme les labels). Pour changer l’image, supprimez et recréez le Pod.

Cycle de vie d’un Pod

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

Distinction importante

La phase du Pod est une vue synthétique. Pour comprendre ce qui se passe réellement, regardez les états des conteneurs dans kubectl describe.

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

En pratique

Avec les applications classiques, vous verrez surtout Always. Les valeurs OnFailure et Never apparaissent davantage dans des Pods ponctuels ou via des Jobs.

Exemple avec OnFailure

job-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: job-pod
spec:
  containers:
    - name: worker
      image: busybox:1.36
      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

• 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

• 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
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: app
      image: nginx:1.27-alpine

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

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

Communication intra-Pod

Les conteneurs d’un même Pod communiquent via localhost et partagent les volumes. Pas besoin de Service.

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
      volumeMounts:
        - name: logs
          mountPath: /var/log/nginx
    - name: log-collector
      image: busybox:1.36
      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.

Conseil

Ne commencez pas par les Pods multi-conteneurs. Maîtrisez d’abord les Pods mono-conteneur, puis explorez les sidecars quand vous en aurez besoin (logs centralisés, service mesh…).

Pourquoi éviter les Pods nus en production

Règle d'or

Ne créez jamais de Pods directement en production. Utilisez des contrôleurs.

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é

Commencez toujours par le basique

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

Prérequis

kubectl top nécessite que Metrics Server soit installé sur le cluster.

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 --target=mon-conteneur

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

Quand utiliser kubectl debug

Les ephemeral containers sont un outil de dépannage ponctuel, pas un mode normal d’exploitation. Ne commencez pas par là : essayez d’abord get, describe, logs et exec.

Dépannage : problèmes courants

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 : Kubernetes ne peut pas télécharger l’image.

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.

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

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

Prochaines étapes

Deployments Créez des applications résilientes avec des réplicas et des rolling updates

Services Exposez vos Pods et permettez la communication entre eux

ConfigMaps et Secrets Externalisez la configuration de vos applications

×

📖 Voir la documentation →