Quand j’ai commencé à enseigner Kubernetes à mes étudiants en BTS SIO, la première question revenait systématiquement : « mais c’est quoi exactement un Pod ? ». Et je comprends la confusion. Entre les conteneurs Docker qu’ils venaient de découvrir et cette nouvelle couche d’abstraction, il y avait de quoi se perdre. Pourtant, les pods in Kubernetes sont le concept fondamental à maîtriser avant tout le reste. Sans une compréhension solide des Pods, impossible de déployer, scaler ou déboguer une application conteneurisée correctement.

Dans ce guide, je vous emmène du concept théorique jusqu’aux commandes pratiques que j’utilise quotidiennement. Que vous prépariez une certification, un projet professionnel ou simplement votre montée en compétences, vous repartirez avec une vision claire et actionnable.

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

Un Pod est la plus petite unité déployable que vous pouvez créer et gérer dans Kubernetes. Pensez-y comme une enveloppe logique autour d’un ou plusieurs conteneurs qui doivent fonctionner ensemble. Le terme vient de l’anglais « pod of whales » (un groupe de baleines), une métaphore choisie par les créateurs de Kubernetes pour évoquer un ensemble cohérent.

Concrètement, un Pod encapsule :

• Un ou plusieurs conteneurs applicatifs (Docker, containerd, CRI-O)
• Des volumes de stockage partagés entre les conteneurs du Pod
• Une adresse IP unique au sein du cluster
• Des règles de configuration définissant comment les conteneurs s’exécutent (ports, variables d’environnement, limites de ressources)

Ce qui rend le Pod si important, c’est le partage de contexte. Tous les conteneurs d’un même Pod partagent le même namespace réseau (ils se parlent via localhost), le même espace de stockage si vous montez des volumes, et le même cycle de vie. Quand un Pod démarre, tous ses conteneurs démarrent. Quand il s’arrête, tout s’arrête.

Pour mes étudiants, j’utilise souvent cette analogie : si un conteneur est un processus isolé, le Pod est l’équivalent d’une machine virtuelle légère qui héberge ce processus avec tout son contexte. C’est une simplification, mais elle aide à saisir l’idée. Selon la documentation officielle de Kubernetes, un Pod modélise un « hôte logique » spécifique à une application.

Pods, Nodes et Containers : comprendre la hiérarchie

Je vois régulièrement des confusions entre ces trois concepts. Clarifions définitivement la hiérarchie.

Un Node (nœud) est une machine physique ou virtuelle qui fait partie du cluster Kubernetes. Chaque Node exécute un agent appelé kubelet qui communique avec le plan de contrôle. Un Node peut héberger plusieurs Pods simultanément, en fonction de ses ressources disponibles (CPU, mémoire, stockage). Si vous venez du monde de la virtualisation de serveurs, un Node est comparable à un hyperviseur qui héberge plusieurs machines virtuelles.

Un Container est un processus isolé qui exécute votre application avec toutes ses dépendances. C’est l’unité d’exécution la plus fine. Docker est le runtime de conteneurs le plus connu, mais Kubernetes supporte aussi containerd et CRI-O.

Un Pod se situe entre les deux : il tourne sur un Node et contient un ou plusieurs Containers.

La règle d’or : un Pod est toujours planifié sur un seul Node. Il ne peut pas être réparti sur plusieurs machines. Si vous avez besoin de redondance, vous créez plusieurs répliques du même Pod, et le scheduler de Kubernetes les répartit sur différents Nodes. C’est là qu’interviennent les contrôleurs comme les services Kubernetes et les Deployments.

Les différents types de Pods dans Kubernetes

On distingue principalement deux catégories de Pods, avec des patterns bien établis pour les Pods multi-conteneurs.

Pods mono-conteneur : le cas standard

C’est le pattern le plus courant et celui que je recommande par défaut. Un Pod héberge un seul conteneur applicatif. Dans ce cas, le Pod est simplement un wrapper autour du conteneur, et Kubernetes gère le Pod plutôt que le conteneur directement. Environ 90 % des Pods en production suivent ce modèle.

apiVersion: v1
kind: Pod
metadata:
  name: mon-app
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

Pods multi-conteneurs : les patterns avancés

Parfois, vous avez besoin que plusieurs conteneurs collaborent étroitement. Les trois patterns reconnus sont :

• Sidecar : un conteneur auxiliaire enrichit le conteneur principal. Exemple classique : un collecteur de logs (Fluentd) qui lit les fichiers de log du conteneur applicatif via un volume partagé
• Ambassador : un conteneur fait office de proxy vers le monde extérieur. Votre application parle à localhost, et l’ambassador route les requêtes vers le bon service distant
• Adapter : un conteneur normalise ou transforme les données de sortie du conteneur principal. Utile pour harmoniser les métriques de monitoring

apiVersion: v1
kind: Pod
metadata:
  name: app-avec-sidecar
spec:
  containers:
  - name: app
    image: mon-app:2.0
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
  - name: log-collector
    image: fluentd:latest
    volumeMounts:
    - name: logs
      mountPath: /var/log/app
  volumes:
  - name: logs
    emptyDir: {}

Pods statiques et Pods gérés

Il existe aussi une distinction technique importante. Les Pods statiques sont gérés directement par le kubelet sur un Node, sans passer par le serveur API. On les utilise principalement pour les composants du plan de contrôle (etcd, kube-apiserver). Les Pods gérés, eux, sont créés via l’API Kubernetes et supervisés par des contrôleurs : c’est la norme pour vos applications.

Le cycle de vie d’un Pod expliqué étape par étape

Comprendre le cycle de vie d’un Pod est essentiel pour diagnostiquer les problèmes. Un Pod traverse cinq phases principales :

1. Pending : le Pod est accepté par le cluster mais un ou plusieurs conteneurs ne sont pas encore prêts. Le scheduler cherche un Node adapté, les images se téléchargent
2. Running : le Pod est lié à un Node, tous les conteneurs sont créés et au moins un est en cours d’exécution
3. Succeeded : tous les conteneurs du Pod ont terminé avec succès (code de sortie 0) et ne seront pas redémarrés. Typique pour les Jobs
4. Failed : au moins un conteneur a terminé en erreur (code de sortie non nul)
5. Unknown : l’état du Pod ne peut pas être déterminé, généralement à cause d’un problème de communication avec le Node

À l’intérieur de ces phases, chaque conteneur a son propre état : Waiting, Running ou Terminated. Par exemple, un Pod en phase Running peut contenir un conteneur en état Waiting si celui-ci redémarre après un crash. C’est pourquoi la colonne RESTARTS dans kubectl get pods est un indicateur précieux.

J’insiste toujours sur un point auprès de mes étudiants : les Pods sont éphémères par conception. Kubernetes ne répare pas un Pod cassé, il le remplace. C’est un changement de paradigme fondamental par rapport à l’administration système traditionnelle. Si vous cherchez à approfondir l’orchestration, je vous recommande de suivre une formation Kubernetes structurée.

Créer et gérer des Pods avec kubectl

L’outil en ligne de commande kubectl est votre interface principale avec le cluster. Voici les commandes que j’utilise plusieurs fois par jour.

Créer un Pod

La méthode déclarative (recommandée) utilise un fichier YAML :

# Créer un Pod à partir d'un fichier manifeste
kubectl apply -f mon-pod.yaml

# Méthode impérative rapide (tests uniquement)
kubectl run mon-nginx --image=nginx:1.25 --port=80

Lister et observer les Pods

# Lister les Pods du namespace par défaut
kubectl get pods

# Lister les Pods de tous les namespaces
kubectl get pods --all-namespaces

# Lister les Pods d'un namespace spécifique
kubectl get pods -n mon-namespace

# Afficher plus de détails (IP, Node, etc.)
kubectl get pods -o wide

# Surveiller en temps réel
kubectl get pods --watch

Inspecter un Pod en détail

# Description complète avec événements
kubectl describe pod mon-nginx

# Consulter les logs du conteneur
kubectl logs mon-nginx

# Suivre les logs en temps réel
kubectl logs -f mon-nginx

# Logs d'un conteneur spécifique dans un Pod multi-conteneurs
kubectl logs mon-pod -c mon-sidecar

Accéder à un Pod

# Ouvrir un shell interactif dans le conteneur
kubectl exec -it mon-nginx -- /bin/bash

# Exécuter une commande ponctuelle
kubectl exec mon-nginx -- cat /etc/nginx/nginx.conf

# Port-forward pour accéder au Pod localement
kubectl port-forward mon-nginx 8080:80

Ces commandes constituent la base de la gestion quotidienne. Pour aller plus loin dans l’automatisation, vous pouvez coupler kubectl avec des outils comme Ansible et ses templates pour déployer vos manifestes de manière reproductible.

Configurer les probes de santé pour vos Pods

Les probes sont un mécanisme essentiel que je vois trop souvent négligé. Elles permettent à Kubernetes de vérifier automatiquement si vos conteneurs fonctionnent correctement.

Les trois types de probes

• Liveness Probe : vérifie si le conteneur est vivant. En cas d’échec, Kubernetes redémarre le conteneur. Indispensable pour détecter les deadlocks
• Readiness Probe : vérifie si le conteneur est prêt à recevoir du trafic. En cas d’échec, le Pod est retiré du Service (plus de trafic entrant) mais pas redémarré
• Startup Probe : protège les conteneurs lents au démarrage. Tant que la startup probe n’a pas réussi, les deux autres probes sont désactivées

apiVersion: v1
kind: Pod
metadata:
  name: app-avec-probes
spec:
  containers:
  - name: app
    image: mon-app:3.0
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10

En pratique, je configure systématiquement au moins une liveness et une readiness probe sur chaque Pod de production. Le coût de configuration est minime, mais l’impact sur la fiabilité est considérable. Un Pod sans probe qui tombe en deadlock restera en état « Running » indéfiniment, sans servir aucune requête : c’est un scénario que j’ai vu provoquer des incidents majeurs.

Bonnes pratiques pour vos Pods en production

Après plusieurs années à déployer des applications sur Kubernetes en entreprise et à former des étudiants, voici les règles que j’applique sans exception.

Toujours utiliser un contrôleur

Ne créez jamais un Pod nu en production. Utilisez toujours un contrôleur de niveau supérieur :

• Deployment : pour les applications stateless (API, frontends). Gère le rolling update et le rollback
• StatefulSet : pour les applications stateful (bases de données, files de messages). Garantit un identifiant stable et un stockage persistant
• DaemonSet : pour les agents qui doivent tourner sur chaque Node (monitoring, collecte de logs)
• Job / CronJob : pour les tâches ponctuelles ou planifiées

Le contrôleur garantit que si un Pod meurt, il sera automatiquement recréé. Sans contrôleur, un Pod supprimé disparaît définitivement.

Définir des limites de ressources

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Les requests déterminent le minimum garanti pour le scheduling. Les limits fixent le plafond : si un conteneur dépasse sa limite mémoire, il sera tué (OOMKilled). Je recommande de toujours définir les deux, en commençant par des valeurs observées en staging.

Utiliser des labels et annotations

Les labels sont votre outil d’organisation principal. Adoptez une convention cohérente dès le départ :

metadata:
  labels:
    app: mon-api
    environment: production
    team: backend
    version: "3.2.1"

Les labels permettent de filtrer, sélectionner et regrouper vos Pods. Les Services et Deployments utilisent des label selectors pour cibler les bons Pods. Un bon étiquetage vous évitera bien des maux de tête lors du débogage.

Sécuriser vos Pods

Appliquez le principe du moindre privilège via le SecurityContext. Selon les recommandations de la documentation Kubernetes sur les standards de sécurité des Pods, vous devriez au minimum :

• Exécuter les conteneurs en tant qu’utilisateur non-root
• Monter le système de fichiers racine en lecture seule quand c’est possible
• Désactiver l’escalade de privilèges

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

La sécurité des conteneurs est un sujet à part entière. Si votre entreprise gère des données sensibles, je vous invite à consulter les ressources spécialisées en sécurité informatique pour compléter votre approche.

Supprimer et déboguer des Pods efficacement

La suppression et le débogage sont des opérations quotidiennes. Voici comment je procède.

Supprimer des Pods

# Supprimer un Pod par son nom
kubectl delete pod mon-nginx

# Supprimer avec un délai de grâce réduit (urgence)
kubectl delete pod mon-nginx --grace-period=10

# Forcer la suppression (Pod bloqué en Terminating)
kubectl delete pod mon-nginx --force --grace-period=0

# Supprimer tous les Pods d'un namespace
kubectl delete pods --all -n mon-namespace

# Supprimer par label
kubectl delete pods -l app=legacy-api

Attention : si le Pod est géré par un Deployment, il sera immédiatement recréé. Pour arrêter définitivement un workload, supprimez le contrôleur parent (le Deployment, le StatefulSet, etc.).

Diagnostiquer un Pod en erreur

Quand un Pod ne démarre pas ou crash en boucle, voici ma méthodologie de diagnostic en quatre étapes :

1. kubectl get pods : vérifier le statut (CrashLoopBackOff, ImagePullBackOff, Pending…)
2. kubectl describe pod <nom> : lire la section Events en bas, elle contient presque toujours la cause
3. kubectl logs <nom> : consulter les logs applicatifs. Ajouter --previous pour voir les logs du conteneur précédent en cas de crash
4. kubectl exec -it <nom> -- /bin/sh : entrer dans le conteneur pour inspecter l’environnement (fichiers, variables, connectivité réseau)

Pour les cas complexes, la commande kubectl debug (disponible depuis Kubernetes 1.25) permet d’attacher un conteneur éphémère de débogage à un Pod en cours d’exécution, sans le redémarrer. C’est un outil que j’utilise régulièrement quand l’image de production ne contient pas les outils de diagnostic nécessaires.

Si vous gérez des secrets dans vos Pods, pensez à les protéger correctement avec un outil comme Ansible Vault pour le chiffrement de vos données sensibles avant déploiement.

Lucie Moreau

Formatrice IT indépendante depuis 2016, ancienne étudiante BTS SIO SLAM. 6 ans d'expérience en entreprise.