Quand j’ai commencé à enseigner Kubernetes à mes étudiants en BTS SIO, la première question revenait systématiquement : « C’est quoi un pod, concrètement ? ». Et je comprends la confusion. Entre les conteneurs Docker qu’ils maîtrisaient déjà et cette nouvelle couche d’abstraction, le kubernetes pod semblait être un concept superflu. Pourtant, c’est la brique fondamentale sur laquelle repose toute l’orchestration Kubernetes. Sans comprendre les pods, impossible de maîtriser le reste. Dans ce guide, je vous partage mon approche pratique, celle que j’utilise en formation et en production, pour que vous puissiez créer, observer et optimiser vos pods en toute confiance.

Qu’est-ce qu’un Kubernetes Pod exactement

Un pod kubernetes est la plus petite unité de calcul que vous pouvez créer et gérer dans Kubernetes. Pensez-y comme une enveloppe logique qui encapsule un ou plusieurs conteneurs partageant les mêmes ressources réseau et de stockage. Le terme « pod » vient de l’anglais et fait référence à un groupe de baleines ou à une cosse de petits pois : un ensemble cohérent d’éléments qui fonctionnent ensemble.

Concrètement, quand vous déployez une application sur Kubernetes, vous ne déployez pas directement un conteneur. Vous déployez un pod qui contient ce conteneur. Cette distinction est essentielle. Le pod fournit un contexte d’exécution partagé : une adresse IP unique, un espace de noms réseau commun, et la possibilité de monter des volumes Kubernetes accessibles par tous les conteneurs du pod.

Selon la documentation officielle de Kubernetes, un pod modélise un « hôte logique » spécifique à une application. Il peut contenir un seul conteneur (le cas le plus fréquent, que j’observe dans 90 % des déploiements de mes étudiants) ou plusieurs conteneurs étroitement couplés qui doivent partager des ressources.

Si vous découvrez tout juste l’univers Kubernetes, je vous recommande de consulter d’abord mon article sur la formation Kubernetes pour poser les bases avant de plonger dans les détails techniques des pods.

Différence entre un pod et un conteneur

C’est la question que je reçois le plus souvent en cours. Un conteneur est un processus isolé qui exécute une image (Docker ou OCI). Un pod est un groupe d’un ou plusieurs conteneurs qui partagent le même environnement réseau et de stockage. La nuance est subtile mais fondamentale.

Voici comment je l’explique à mes étudiants : le conteneur est l’appartement, le pod est l’immeuble. Chaque appartement (conteneur) a ses propres pièces, mais tous les résidents de l’immeuble (pod) partagent la même adresse postale (IP) et le même parking (volumes).

En pratique, quand deux conteneurs ont besoin de communiquer via localhost ou de partager des fichiers sur un même volume, ils appartiennent au même pod. Si ce couplage n’existe pas, séparez-les dans des pods distincts. Pour mieux comprendre la relation entre Docker et Kubernetes, mon article Kubernetes vs Docker détaille les différences clés entre ces deux technologies.

Architecture et fonctionnement interne d’un pod

Pour bien utiliser les pods, il faut comprendre ce qui se passe sous le capot. Quand Kubernetes crée un pod, il lance d’abord un conteneur spécial appelé pause container (ou infrastructure container). Ce conteneur ne fait rien de visible : il maintient l’espace de noms réseau et IPC du pod. Tous les autres conteneurs du pod rejoignent cet espace de noms.

Cette architecture explique pourquoi les conteneurs d’un même pod :

• Partagent la même adresse IP et le même espace de ports
• Peuvent communiquer via localhost
• Partagent les volumes montés dans la pod spec
• Sont toujours co-schedulés sur le même nœud du cluster

Le kubelet, l’agent qui tourne sur chaque nœud, est responsable de la gestion locale des pods. Il reçoit les spécifications du pod depuis l’API server, demande au container runtime (containerd, CRI-O) de lancer les conteneurs, et surveille leur santé en continu.

Un concept important est le kubernetes pod template hash. Quand vous utilisez un Deployment, Kubernetes génère un hash à partir du template de pod. Ce hash est ajouté comme label au ReplicaSet et aux pods correspondants, ce qui permet de tracer la version exacte du template utilisé pour créer chaque pod. Si vous modifiez le template, un nouveau hash est généré et un nouveau ReplicaSet est créé pour le rolling update.

Les init containers sont un autre mécanisme essentiel. Ces conteneurs s’exécutent séquentiellement avant les conteneurs principaux du pod. Je les utilise fréquemment pour préparer le système de fichiers, attendre qu’une base de données soit disponible, ou télécharger des fichiers de configuration.

Cycle de vie complet d’un pod Kubernetes

Comprendre le cycle de vie d’un pod est crucial pour le dépannage. Un pod passe par 5 phases distinctes, et chacune vous donne des informations précieuses sur l’état de votre application :

• Pending : le pod est accepté par le cluster mais un ou plusieurs conteneurs ne sont pas encore prêts. Le téléchargement des images ou l’attente de scheduling peut prendre du temps.
• Running : le pod est attaché à un nœud et tous les conteneurs sont créés. Au moins un conteneur est en cours d’exécution ou en phase de démarrage.
• Succeeded : tous les conteneurs du pod se sont terminés avec succès (code de sortie 0) et ne seront pas relancés. Typique des Jobs et CronJobs.
• Failed : au moins un conteneur s’est terminé avec un code d’erreur. Le pod ne sera pas relancé automatiquement (sauf via un contrôleur).
• Unknown : l’état du pod ne peut pas être déterminé, généralement à cause d’une perte de communication avec le nœud.

Chaque conteneur dans le pod a aussi ses propres états : Waiting, Running et Terminated. Les probes (sondes) jouent un rôle déterminant dans les transitions entre ces états. J’y reviendrai dans la section sur les bonnes pratiques.

Un point que je souligne toujours à mes étudiants : les pods sont éphémères par conception. Kubernetes peut les supprimer et les recréer à tout moment (éviction, mise à jour, panne de nœud). Ne stockez jamais de données critiques dans le filesystem local d’un pod sans un volume persistant. Cette philosophie rejoint les principes du métier de DevOps Engineer, où la résilience est une priorité absolue.

Créer et gérer un pod avec kubectl

Passons à la pratique. La commande kubectl est votre interface principale pour interagir avec les pods. Voici les kubernetes pod command essentielles que j’enseigne dès la première séance :

Créer un pod rapidement

# Créer un pod nginx en une ligne
kubectl run mon-nginx --image=nginx:1.25 --port=80

# Vérifier que le pod est en cours d'exécution
kubectl get pods

# Obtenir des détails complets sur le pod
kubectl describe pod mon-nginx

Observer et débugger

# Voir les logs du conteneur principal
kubectl logs mon-nginx

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

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

# Voir les événements liés au pod
kubectl get events --field-selector involvedObject.name=mon-nginx

Gérer le cycle de vie

# Supprimer un pod
kubectl delete pod mon-nginx

# Supprimer avec un délai de grâce de 0 seconde (force)
kubectl delete pod mon-nginx --grace-period=0 --force

# Appliquer un manifeste YAML
kubectl apply -f mon-pod.yaml

Je conseille à mes étudiants d’utiliser l’option -o wide avec kubectl get pods pour afficher l’adresse IP du pod et le nœud sur lequel il tourne. C’est un réflexe de dépannage qui fait gagner un temps précieux.

Anatomie d’un pod spec : le manifeste YAML expliqué

En production, on ne crée jamais de pod avec kubectl run. On écrit un manifeste YAML qui décrit précisément la kubernetes pod spec. Voici un exemple complet que j’utilise comme base en formation :

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
    environment: production
spec:
  containers:
  - name: webapp
    image: mon-registre/webapp:2.1.0
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    env:
    - name: DATABASE_URL
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: url
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: webapp-config
  restartPolicy: Always

Décortiquons les éléments clés de cette pod définition :

• metadata.labels : les labels sont indispensables pour le filtrage et la sélection par les Services et Deployments
• resources.requests : la quantité minimum de CPU et mémoire garantie au conteneur. Le scheduler utilise ces valeurs pour placer le pod.
• resources.limits : le plafond au-delà duquel le conteneur sera throttlé (CPU) ou OOMKilled (mémoire)
• livenessProbe : vérifie que le conteneur est vivant. En cas d’échec, Kubernetes le redémarre.
• readinessProbe : vérifie que le conteneur est prêt à recevoir du trafic. En cas d’échec, le pod est retiré du Service.
• restartPolicy : définit le comportement de redémarrage (Always, OnFailure, Never)

Pour la gestion des secrets et des configurations sensibles, la combinaison de Kubernetes avec des outils comme Ansible Vault offre une couche de sécurité supplémentaire, notamment dans les pipelines CI/CD.

Bonnes pratiques pour vos pods en production

Après plusieurs années à déployer des applications en production et à accompagner mes étudiants sur leurs projets, voici les règles que j’applique systématiquement :

Ne déployez jamais un pod seul

Un pod nu (bare pod) n’est pas géré par un contrôleur. S’il tombe, personne ne le relance. Utilisez toujours un Deployment, un StatefulSet ou un DaemonSet selon votre cas d’usage. Le Deployment est le choix par défaut dans 95 % des situations.

Définissez requests et limits pour chaque conteneur

Sans requests, le scheduler ne peut pas placer intelligemment vos pods. Sans limits, un conteneur peut consommer toutes les ressources du nœud et impacter les autres workloads. Je recommande de fixer les requests à 70-80 % des limits pour laisser une marge de burst.

Configurez les probes systématiquement

Les trois types de probes sont complémentaires :

• livenessProbe : « Mon conteneur est-il bloqué ? » Si oui, redémarre-le.
• readinessProbe : « Mon conteneur peut-il recevoir des requêtes ? » Si non, retire-le du load balancer.
• startupProbe : « Mon conteneur a-t-il fini de démarrer ? » Utile pour les applications lentes au boot (JVM, Spring Boot).

Utilisez les labels et annotations de manière cohérente

Adoptez une convention de nommage dès le début. La recommandation officielle Kubernetes suggère d’utiliser les labels préfixés app.kubernetes.io/ comme app.kubernetes.io/name, app.kubernetes.io/version et app.kubernetes.io/component.

Un conteneur par pod, sauf exception justifiée

Le pattern multi-conteneur se justifie dans trois cas principaux :

• Sidecar : un conteneur auxiliaire qui enrichit le conteneur principal (proxy Envoy, collecteur de logs Fluentd)
• Ambassador : un proxy qui simplifie l’accès à un service externe
• Adapter : un conteneur qui normalise les sorties du conteneur principal

Si vous hésitez, c’est probablement que les conteneurs doivent être dans des pods séparés. Pensez à consulter mon guide détaillé sur les pods pour des exemples concrets de ces patterns.

Sécurisez vos pods avec un Security Context

En production, ne faites jamais tourner vos conteneurs en root. Configurez un securityContext restrictif :

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: webapp
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Ces mesures de sécurité sont d’autant plus critiques si votre infrastructure est exposée. Pour renforcer votre posture globale, les principes décrits dans mon article sur les entreprises de sécurité informatique s’appliquent aussi à l’orchestration de conteneurs.

Dépannage et erreurs courantes

Au fil de mes formations et missions, j’ai identifié les problèmes les plus fréquents rencontrés avec les pods :

CrashLoopBackOff

Le conteneur démarre, plante, et Kubernetes le relance en boucle avec un backoff exponentiel. Causes habituelles : erreur dans la commande de démarrage, variable d’environnement manquante, port déjà utilisé. Utilisez kubectl logs mon-pod --previous pour voir les logs du crash précédent.

ImagePullBackOff

Kubernetes n’arrive pas à télécharger l’image du conteneur. Vérifiez le nom et le tag de l’image, les credentials du registre (imagePullSecrets), et la connectivité réseau du nœud.

Pending indéfiniment

Le pod ne trouve pas de nœud pour être schedulé. Causes fréquentes : resources requests trop élevées, nodeSelector ou affinité incompatible, ou tout simplement un cluster sous-dimensionné. La commande kubectl describe pod affiche les événements qui expliquent le blocage.

OOMKilled

Le conteneur a dépassé sa memory limit et a été tué par le kernel. Augmentez la limit ou optimisez la consommation mémoire de votre application. Pour les applications Java, n’oubliez pas de configurer -XX:MaxRAMPercentage en cohérence avec la limit du pod.

La maîtrise de ces scénarios de dépannage fait partie des compétences attendues dans un portfolio BTS SIO SISR. Je recommande à mes étudiants de documenter chaque problème rencontré et sa résolution.

Pod vs cluster, pod vs VM : les confusions fréquentes

Pour clore ce guide, dissipons deux confusions que je rencontre régulièrement :

Pod vs Cluster

Un cluster Kubernetes est l’infrastructure complète composée d’un plan de contrôle (API server, scheduler, controller manager, etcd) et de nœuds workers. Un pod est une ressource à l’intérieur de ce cluster. L’analogie est simple : le cluster est la ville, les nœuds sont les quartiers, et les pods sont les bâtiments. Un cluster peut héberger des centaines, voire des milliers de pods répartis sur ses nœuds.

Pod vs Machine Virtuelle

Non, un pod Kubernetes n’est pas une VM. Une machine virtuelle émule un hardware complet avec son propre noyau OS. Un pod partage le noyau Linux de son nœud hôte et utilise les namespaces et cgroups du kernel pour l’isolation. Le pod est beaucoup plus léger : il démarre en quelques secondes contre plusieurs minutes pour une VM, et consomme nettement moins de ressources. Pour mieux comprendre le rôle de la virtualisation dans ce contexte, consultez mon guide sur comment activer la virtualisation matérielle, une étape souvent nécessaire pour faire tourner un cluster local.

En résumé, le pod est une abstraction de niveau applicatif, pas une abstraction de niveau infrastructure. Il répond à la question « quels conteneurs doivent tourner ensemble ? » et non « comment isoler un système d’exploitation complet ? ».

Si vous envisagez une reconversion vers les métiers DevOps, sachez que la maîtrise des pods Kubernetes est devenue un prérequis dans la majorité des offres d’emploi. Mon guide sur la reconversion en informatique vous donnera une vue d’ensemble des parcours possibles.

Lucie Moreau

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