Quand j’ai commencé à enseigner Kubernetes à mes étudiants en BTS SIO, la première question revenait systématiquement : c’est quoi exactement un Pod ? Cette notion est le point d’entrée incontournable pour comprendre l’orchestration de conteneurs. Je vais vous expliquer concrètement ce qu’est un Pod, comment il fonctionne, et surtout comment l’utiliser efficacement dans vos projets. Que vous prépariez une formation Kubernetes ou que vous débutiez en DevOps, ce guide couvre tout ce que vous devez savoir.

Définition : qu’est-ce qu’un Pod Kubernetes ?

Un Pod est la plus petite unité déployable et planifiable dans Kubernetes. Concrètement, c’est une enveloppe logique qui encapsule un ou plusieurs conteneurs (généralement Docker), partageant le même espace réseau, le même stockage et les mêmes spécifications de cycle de vie. Le terme « Pod » vient de l’anglais et fait référence à un groupe de baleines (« a pod of whales »), illustrant l’idée de conteneurs qui voyagent ensemble.

Pour le dire en termes simples : si un conteneur est une application empaquetée avec ses dépendances, le Pod est l’enveloppe qui permet à Kubernetes de gérer ce conteneur. Kubernetes ne manipule jamais directement un conteneur ; il passe toujours par le Pod. C’est un concept fondamental que je répète souvent en cours, car il conditionne toute la suite de l’apprentissage.

Selon la documentation officielle de Kubernetes, un Pod représente un ensemble de conteneurs applicatifs colocalisés, partageant un contexte d’exécution commun. Ce contexte inclut les namespaces Linux (réseau, PID, IPC), ce qui signifie que les conteneurs d’un même Pod peuvent communiquer via localhost sans configuration réseau supplémentaire.

En pratique, je constate que la grande majorité des déploiements utilisent des Pods mono-conteneur. Le pattern multi-conteneur existe, mais il est réservé à des cas bien précis que nous verrons plus loin. Si vous débutez, retenez simplement qu’un Pod équivaut généralement à une instance de votre application.

Comment fonctionne un Pod en interne ?

Pour bien comprendre le fonctionnement d’un Pod, il faut visualiser ce qui se passe quand Kubernetes en crée un. Le processus se déroule en plusieurs étapes que je vais détailler.

Lorsque vous soumettez une définition de Pod au kube-apiserver, celui-ci valide la requête et l’enregistre dans etcd (la base de données du cluster). Le kube-scheduler analyse ensuite les ressources disponibles sur chaque nœud et affecte le Pod au nœud le plus adapté. Enfin, le kubelet du nœud sélectionné récupère la spécification et demande au runtime de conteneurs (containerd, CRI-O) de démarrer les conteneurs.

Chaque Pod reçoit automatiquement :

• Une adresse IP unique au sein du cluster
• Un espace réseau partagé entre tous ses conteneurs
• Des volumes de stockage accessibles par tous les conteneurs du Pod
• Un conteneur invisible appelé pause container qui maintient les namespaces réseau

Ce dernier point est souvent méconnu. Kubernetes crée systématiquement un conteneur « pause » (aussi appelé infra container) avant vos conteneurs applicatifs. Ce conteneur minimaliste a pour seule fonction de maintenir les namespaces réseau et IPC du Pod. Si vos conteneurs applicatifs redémarrent, l’adresse IP du Pod reste stable grâce à ce mécanisme.

Les conteneurs au sein d’un même Pod partagent également l’espace de stockage via les Volumes Kubernetes. Un volume de type emptyDir, par exemple, permet à deux conteneurs d’échanger des fichiers sans configuration complexe. C’est cette proximité qui rend le pattern sidecar si puissant, comme je l’explique souvent à mes étudiants qui se préparent au métier de DevOps Engineer.

Pod vs conteneur : quelle différence concrète ?

C’est la confusion la plus fréquente chez les débutants, et je la comprends parfaitement. La différence entre un Pod et un conteneur est à la fois simple et fondamentale.

Un conteneur est un processus isolé qui exécute une application avec toutes ses dépendances. Il est créé à partir d’une image (Docker, OCI) et fonctionne de manière autonome. Un conteneur, c’est votre application empaquetée.

Un Pod, en revanche, est une abstraction Kubernetes qui enveloppe un ou plusieurs conteneurs. Il ajoute une couche de gestion : adresse IP, politique de redémarrage, sondes de santé, limites de ressources, affinités de placement. Le Pod est le point de contact entre votre application et l’orchestrateur.

Pour faire une analogie que j’utilise en cours : si le conteneur est un passager, le Pod est le siège dans l’avion. Kubernetes gère les sièges (Pods), pas les passagers (conteneurs) directement. Si vous venez du monde Docker et souhaitez comprendre comment ces deux technologies s’articulent, je vous recommande de consulter mon guide sur Kubernetes vs Docker.

Pod vs cluster : comprendre la hiérarchie

Un cluster Kubernetes est l’ensemble de l’infrastructure : les nœuds (machines physiques ou virtuelles), le plan de contrôle (API server, scheduler, controller manager, etcd) et les composants réseau. Le cluster est le terrain de jeu ; les Pods sont les joueurs.

Voici la hiérarchie complète pour bien situer le Pod :

• Cluster : l’infrastructure complète Kubernetes
• Namespace : partition logique au sein du cluster (dev, staging, prod)
• Node : une machine (physique ou virtuelle) qui exécute des Pods
• Pod : la plus petite unité déployable, hébergée sur un Node
• Container : le processus applicatif à l’intérieur du Pod

Un cluster de production typique contient plusieurs dizaines à plusieurs milliers de Pods répartis sur différents nœuds. Les clusters managés (EKS, GKE, AKS) supportent couramment de 5 000 à 150 000 Pods selon la taille du cluster et la configuration réseau. Le scheduler de Kubernetes s’occupe de placer chaque Pod sur le nœud le plus approprié en fonction des ressources disponibles, des contraintes d’affinité et des politiques définies.

Ce que je souligne toujours à mes étudiants : un Pod est éphémère par conception. Il peut être détruit et recréé à tout moment par le cluster, sur un nœud différent. C’est pourquoi on ne déploie presque jamais un Pod seul en production ; on utilise des contrôleurs qui garantissent le nombre souhaité de réplicas. Pour bien comprendre ces mécanismes, une bonne maîtrise de la virtualisation matérielle est un prérequis utile.

Les types de Pods et leurs cas d’usage

Pod mono-conteneur

C’est le cas d’usage standard et le plus répandu. Un Pod contient un seul conteneur qui exécute votre application (serveur web, API, worker de file d’attente). Ce pattern couvre plus de 90 % des déploiements que je rencontre en entreprise et en cours.

Exemple de manifeste YAML pour un Pod mono-conteneur :

apiVersion: v1
kind: Pod
metadata:
  name: mon-api
  labels:
    app: api
    env: production
spec:
  containers:
  - name: api-container
    image: mon-registre/api:v2.1
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 15

Pod multi-conteneur

Dans certains cas, il est pertinent de regrouper plusieurs conteneurs dans un même Pod. Ce pattern est utilisé quand les conteneurs sont étroitement couplés et doivent partager des ressources. Les trois patterns reconnus sont :

• Sidecar : un conteneur auxiliaire qui enrichit le conteneur principal (collecte de logs, proxy Envoy pour un service mesh, agent de monitoring)
• Ambassador : un conteneur qui agit comme proxy vers des services externes, simplifiant la configuration du conteneur principal
• Adapter : un conteneur qui transforme ou normalise les sorties du conteneur principal (conversion de format de logs, adaptation de métriques)

Depuis Kubernetes 1.28, le concept de sidecar container natif a été introduit avec les initContainers dotés de la propriété restartPolicy: Always. Cette évolution simplifie considérablement la gestion des conteneurs auxiliaires, car ils sont désormais démarrés avant le conteneur principal et arrêtés après lui, de manière ordonnée.

Pod statique

Les Pods statiques sont gérés directement par le kubelet d’un nœud, sans passer par l’API server. Ils sont utilisés principalement pour les composants du plan de contrôle (kube-apiserver, kube-scheduler, etcd). En tant que développeur, vous n’aurez probablement jamais à en créer, mais il est bon de savoir qu’ils existent.

Créer et gérer un Pod : commandes essentielles

Voici les commandes kubectl que j’enseigne en priorité à mes étudiants. Elles couvrent l’essentiel de la gestion quotidienne des Pods.

Créer un Pod rapidement

# Créer un Pod à partir d'une image
kubectl run mon-nginx --image=nginx:latest --port=80

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

# Créer un Pod et ouvrir un shell interactif
kubectl run debug-pod --image=busybox -it --rm -- /bin/sh

Observer et diagnostiquer

# Lister les Pods du namespace courant
kubectl get pods

# Lister les Pods avec plus de détails (IP, nœud)
kubectl get pods -o wide

# Voir les détails complets d'un Pod
kubectl describe pod mon-nginx

# Consulter les logs d'un 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-conteneur
kubectl logs mon-pod -c sidecar-container

Interagir avec un Pod en cours d’exécution

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

# Copier un fichier depuis/vers un Pod
kubectl cp mon-nginx:/var/log/app.log ./app.log

# Rediriger un port local vers le Pod
kubectl port-forward mon-nginx 8080:80

# Supprimer un Pod
kubectl delete pod mon-nginx

Je recommande vivement de pratiquer ces commandes dans un environnement local comme Minikube ou kind avant de toucher à un cluster de production. Pour approfondir votre maîtrise des outils DevOps, un portfolio BTS SIO SISR bien construit incluant des projets Kubernetes est un excellent atout.

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

Comprendre le cycle de vie d’un Pod est essentiel pour diagnostiquer les problèmes en production. Voici les différentes phases qu’un Pod traverse, avec les états que vous observerez via kubectl get pods.

Phase 1 : Pending. Le Pod est accepté par le cluster mais pas encore planifié. Le scheduler cherche un nœud disponible. Si le Pod reste bloqué en Pending, c’est souvent un problème de ressources insuffisantes (CPU, mémoire) ou de contraintes d’affinité impossibles à satisfaire.

Phase 2 : ContainerCreating. Le nœud a été sélectionné, le kubelet télécharge les images et crée les conteneurs. Un blocage à cette étape indique généralement un problème de pull d’image (image inexistante, registre inaccessible, credentials manquants).

Phase 3 : Running. Tous les conteneurs sont démarrés. Les sondes de santé (liveness et readiness) surveillent l’état du Pod. Un Pod en Running n’est pas forcément prêt à recevoir du trafic ; il faut que la readiness probe soit positive.

Phase 4 : Succeeded ou Failed. Le Pod a terminé son exécution. Succeeded signifie que tous les conteneurs ont retourné un code de sortie 0. Failed indique qu’au moins un conteneur a échoué. Ces états concernent principalement les Jobs et CronJobs.

Phase 5 : Terminating. Le Pod reçoit un signal SIGTERM, puis dispose d’un grace period de 30 secondes par défaut pour s’arrêter proprement. Passé ce délai, un SIGKILL force l’arrêt. Vous pouvez ajuster ce délai via terminationGracePeriodSeconds dans la spécification du Pod.

Les trois types de sondes de santé jouent un rôle central dans ce cycle :

En cours, j’insiste toujours sur l’importance de configurer au minimum une livenessProbe et une readinessProbe. Sans elles, Kubernetes ne peut pas savoir si votre application fonctionne correctement, ce qui conduit à des comportements imprévisibles en production. Pour en savoir plus sur la sécurisation de vos déploiements, consultez le guide sur Ansible Vault qui traite du chiffrement des secrets dans vos pipelines.

Bonnes pratiques pour utiliser les Pods en production

Après plusieurs années à accompagner des équipes sur Kubernetes, voici les recommandations que je donne systématiquement.

Ne déployez jamais un Pod seul

En production, utilisez toujours un Deployment, un StatefulSet ou un DaemonSet selon votre cas d’usage. Ces contrôleurs garantissent que le nombre souhaité de réplicas est maintenu, gèrent les mises à jour progressives (rolling updates) et permettent le rollback en cas de problème. Un Pod orphelin qui tombe ne sera jamais recréé automatiquement.

Définissez toujours les ressources

Spécifiez les requests et limits pour le CPU et la mémoire de chaque conteneur. Les requests influencent le placement du Pod par le scheduler, tandis que les limits protègent le nœud contre un conteneur gourmand. Un Pod sans limits peut consommer toute la mémoire d’un nœud et provoquer un OOMKill en cascade.

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "1000m"

Utilisez des labels cohérents

Les labels sont la clé du service discovery dans Kubernetes. Adoptez une convention de nommage dès le départ : app, env, version, team. Ces labels permettent aux Services, aux Deployments et aux politiques réseau de cibler précisément les bons Pods.

Configurez les sondes de santé

J’ai vu trop de clusters de production sans aucune sonde configurée. C’est l’équivalent de conduire sans tableau de bord. Configurez au minimum une readinessProbe HTTP sur un endpoint /healthz ou /ready. Pour les applications avec un démarrage long (JVM, applications .NET), ajoutez une startupProbe avec un failureThreshold généreux.

Sécurisez vos Pods

Appliquez le principe du moindre privilège. Configurez un securityContext qui empêche l’exécution en root, désactive les capabilities Linux inutiles et monte le système de fichiers en lecture seule quand c’est possible. Selon les standards de sécurité Pod de Kubernetes, le profil « restricted » est recommandé pour les workloads de production.

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

Pour les étudiants qui souhaitent approfondir la sécurité des infrastructures, je recommande de consulter les ressources sur les entreprises de sécurité informatique et d’explorer les certifications associées.

Gérez les secrets correctement

Ne mettez jamais de données sensibles en dur dans vos manifestes YAML. Utilisez les objets Secret de Kubernetes, et idéalement un gestionnaire de secrets externe comme HashiCorp Vault ou les solutions managées des cloud providers. Les secrets montés en tant que volumes sont préférables aux variables d’environnement, car elles apparaissent dans les logs de debug et les inspections de conteneurs.

Ce qu’il faut retenir sur les Pods Kubernetes

Le Pod est la brique élémentaire de Kubernetes. Comprendre son fonctionnement, son cycle de vie et ses bonnes pratiques d’utilisation est indispensable pour quiconque travaille avec l’orchestration de conteneurs. Que vous soyez en alternance en développement informatique ou ingénieur confirmé, la maîtrise des Pods conditionne votre efficacité sur toute la stack Kubernetes.

Le passage de Docker seul à Kubernetes peut sembler intimidant, mais une fois que vous avez compris qu’un Pod n’est rien d’autre qu’un wrapper intelligent autour de vos conteneurs, tout le reste devient plus clair. Les Deployments, les Services, les Ingress : tout repose sur cette unité fondamentale. Si vous envisagez une reconversion en informatique, sachez que la maîtrise de Kubernetes est aujourd’hui l’une des compétences les plus demandées sur le marché DevOps.

Lucie Moreau

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