Quand j’ai commencé à former mes étudiants en formation Kubernetes, la notion de pod revenait systématiquement comme le premier point de confusion. Pourtant, c’est le concept fondamental à maîtriser avant d’aller plus loin. Dans ce guide, je vous explique tout ce que vous devez savoir sur les pods Kubernetes pour les comprendre, les créer et les gérer efficacement.

Qu’est-ce qu’un pod Kubernetes exactement

Un pod représente la plus petite unité déployable dans l’écosystème Kubernetes. En informatique, le terme « pod » désigne un regroupement logique, à l’image d’un pod de baleines (un groupe qui se déplace ensemble). Dans Kubernetes, un pod encapsule un ou plusieurs conteneurs qui partagent les mêmes ressources réseau et stockage.

Concrètement, imaginez un pod comme un hôte logique pour vos conteneurs. Les processus à l’intérieur d’un même pod peuvent communiquer entre eux via localhost, exactement comme s’ils tournaient sur la même machine physique. Cette proximité est la raison d’être du pod : regrouper des processus étroitement couplés qui doivent fonctionner ensemble.

Selon la documentation officielle de Kubernetes, un pod modélise un « hôte logique spécifique à une application ». C’est une abstraction au-dessus du conteneur qui ajoute des capacités de gestion, de mise en réseau et d’orchestration que le conteneur seul ne possède pas.

En pratique, quand vous déployez une application sur Kubernetes, vous ne déployez jamais un conteneur directement. Vous déployez toujours un pod qui contient votre conteneur. C’est une distinction fondamentale que je souligne systématiquement à mes étudiants en BTS SIO SISR.

Pod vs conteneur : quelle différence

La confusion entre pod et conteneur est probablement la plus fréquente chez les débutants. Un conteneur est une instance isolée d’une application empaquetée avec ses dépendances (image Docker, par exemple). Un pod est l’enveloppe Kubernetes qui héberge un ou plusieurs de ces conteneurs.

Pour bien saisir la nuance, pensez au conteneur comme un processus applicatif et au pod comme la machine (virtuelle) sur laquelle ce processus tourne. Le pod fournit au conteneur :

• Une adresse IP unique partagée entre tous les conteneurs du pod
• Un espace de stockage partagé via les volumes
• Des métadonnées de gestion (labels, annotations, namespace)
• Des règles de redémarrage et de cycle de vie

Un point important : dans Kubernetes, le conteneur n’est jamais manipulé directement. Toutes les opérations passent par le pod. C’est pourquoi comprendre les kubernetes pods est un prérequis avant de travailler avec des Deployments ou des Services.

Pod, cluster et node : comprendre la hiérarchie

Pour situer le pod dans l’architecture globale de Kubernetes, il faut comprendre la hiérarchie complète. Un cluster Kubernetes est l’ensemble de l’infrastructure : il regroupe toutes les machines (physiques ou virtuelles) qui participent à l’orchestration. Un node (nœud) est une machine individuelle au sein du cluster, qu’il s’agisse d’un serveur physique ou d’une VM. Le pod, lui, est l’unité de travail qui s’exécute sur un node.

La relation est donc la suivante : un cluster contient plusieurs nodes, et chaque node héberge plusieurs pods. Le scheduler de Kubernetes décide automatiquement sur quel node placer chaque pod en fonction des ressources disponibles (CPU, mémoire, affinités).

Pour illustrer cette hiérarchie dans un contexte concret, prenons l’exemple d’un DevOps Engineer qui gère une application e-commerce :

• Cluster : l’infrastructure complète hébergée chez un cloud provider
• Nodes : 5 serveurs virtuels de 4 CPU et 16 Go de RAM chacun
• Pods : 12 pods répartis entre le frontend, le backend API, la base de données et le cache Redis

Cette distinction est essentielle. Quand on parle de scalabilité horizontale, on ajoute des pods (pas des nodes, sauf si les ressources sont insuffisantes). Quand on parle de haute disponibilité, on répartit les pods sur plusieurs nodes pour résister à la panne d’une machine.

Architecture interne d’un pod

L’architecture interne d’un pod mérite qu’on s’y attarde, car elle explique beaucoup de comportements que vous observerez en production. Chaque pod contient au minimum un conteneur applicatif, mais il embarque aussi un conteneur système invisible appelé pause container.

Le pause container joue un rôle crucial : il maintient les namespaces réseau et IPC du pod. Même si votre conteneur applicatif crash et redémarre, l’adresse IP du pod reste stable grâce à ce conteneur système. C’est un détail d’implémentation que vous n’avez pas besoin de gérer, mais qui explique pourquoi un pod conserve son identité réseau malgré les redémarrages de conteneurs.

Un pod peut contenir plusieurs types de conteneurs :

• Conteneur principal : votre application (serveur web, API, worker)
• Conteneurs sidecar : des processus complémentaires (collecteur de logs, proxy, agent de monitoring)
• Conteneurs d’initialisation (init containers) : des processus qui s’exécutent avant le conteneur principal pour préparer l’environnement

Les conteneurs d’un même pod partagent plusieurs espaces :

• Espace réseau : même adresse IP, communication via localhost
• Volumes montés : accès aux mêmes répertoires partagés
• Espace IPC : communication inter-processus via mémoire partagée
• PID namespace (optionnel) : visibilité des processus entre conteneurs

Cette architecture permet des patterns puissants. Par exemple, un sidecar Envoy peut gérer tout le trafic réseau de votre application sans que celle-ci ait besoin de connaître les détails du service mesh. C’est exactement ce que font des outils comme Istio ou Linkerd, très utilisés dans les environnements de production avancés. Pour approfondir le fonctionnement interne, je vous recommande notre article sur le fonctionnement détaillé d’un pod Kubernetes.

Cycle de vie des pods Kubernetes

Comprendre le cycle de vie d’un pod est indispensable pour diagnostiquer les problèmes en production. Un pod traverse 5 phases au cours de son existence :

Pending : le pod a été accepté par le cluster, mais un ou plusieurs conteneurs ne sont pas encore prêts. Le scheduler cherche un node adapté, ou les images sont en cours de téléchargement. Si votre pod reste bloqué en Pending, vérifiez les ressources disponibles sur vos nodes.

Running : le pod est assigné à un node et tous les conteneurs ont été créés. Au moins un conteneur est en cours d’exécution ou en train de démarrer. C’est l’état nominal de fonctionnement.

Succeeded : tous les conteneurs du pod se sont terminés avec un code de sortie 0. Cette phase concerne principalement les Jobs et CronJobs, pas les applications longue durée.

Failed : tous les conteneurs se sont terminés et au moins un a retourné un code d’erreur. C’est le signal qu’un conteneur a crashé ou a été tué par le système (OOMKilled par exemple).

Unknown : l’état du pod ne peut pas être déterminé, généralement à cause d’un problème de communication avec le node. Cela peut indiquer une panne réseau ou un node défaillant.

En parallèle de ces phases, Kubernetes utilise des probes (sondes) pour vérifier la santé de vos conteneurs :

• Liveness probe : vérifie si le conteneur est vivant, le redémarre sinon
• Readiness probe : vérifie si le conteneur est prêt à recevoir du trafic
• Startup probe : gère les applications lentes au démarrage

Je recommande de toujours configurer au minimum une liveness probe et une readiness probe sur vos pods de production. Sans elles, Kubernetes n’a aucun moyen fiable de savoir si votre application fonctionne correctement.

Créer son premier pod en pratique

Passons à la pratique. Pour créer un pod, vous avez deux approches : la commande impérative (rapide, idéale pour tester) et le fichier YAML déclaratif (recommandé pour la production).

La commande impérative la plus simple :

kubectl run mon-premier-pod --image=nginx:latest --port=80

Cette commande crée un pod nommé mon-premier-pod qui exécute un conteneur Nginx. C’est parfait pour un test rapide, mais en production, on préfère un fichier YAML :

apiVersion: v1
kind: Pod
metadata:
  name: mon-app-pod
  labels:
    app: mon-app
    env: production
spec:
  containers:
  - name: mon-app
    image: nginx:1.25
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5

Pour appliquer ce fichier :

kubectl apply -f mon-app-pod.yaml

Quelques commandes essentielles pour vérifier votre pod :

# Lister les pods
kubectl get pods

# Détail complet d'un pod
kubectl describe pod mon-app-pod

# Voir les logs
kubectl logs mon-app-pod

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

Pour un guide pas à pas complet, consultez notre guide pratique sur les Kubernetes Pod qui détaille chaque étape avec des exemples concrets.

Les différents types de pods

En pratique, on distingue plusieurs façons d’utiliser les pods selon le cas d’usage. Voici les configurations les plus courantes que je rencontre en entreprise et en formation :

Pod mono-conteneur : c’est le cas le plus fréquent, représentant plus de 80 % des déploiements. Un seul conteneur applicatif par pod. Simple, efficace, facile à scaler. C’est la configuration que vous utiliserez dans la majorité des cas.

Pod multi-conteneurs (sidecar pattern) : un conteneur principal accompagné d’un ou plusieurs conteneurs auxiliaires. Cas d’usage typiques : collecte de logs avec Fluentd, proxy inverse avec Envoy, synchronisation de fichiers. Le pattern sidecar est devenu natif dans Kubernetes 1.28+ avec les sidecar containers officiels.

Pod avec init containers : des conteneurs d’initialisation qui s’exécutent séquentiellement avant le conteneur principal. Idéal pour vérifier des prérequis (base de données disponible, configuration chargée, migrations appliquées).

Pods statiques : créés directement par le kubelet sur un node spécifique, sans passer par l’API server. Utilisés principalement pour les composants système du cluster lui-même (etcd, kube-apiserver sur les control plane nodes).

Notez que dans le langage courant, on parle parfois de « pod » dans d’autres contextes en informatique. Un pod en transport désigne une capsule autonome (comme les pods de transport Hyperloop). En cigarette électronique, un pod est une cartouche préremplie de liquide. Ces usages n’ont rien à voir avec Kubernetes ; ici, le terme pod désigne exclusivement l’unité d’exécution de l’orchestrateur.

Bonnes pratiques pour gérer vos pods en production

Après plusieurs années à accompagner des équipes en production, voici les bonnes pratiques que je considère non négociables pour gérer vos pods Kubernetes :

Ne jamais créer de pods isolés. En production, utilisez toujours un Deployment ou un StatefulSet qui crée les pods pour vous. Un pod isolé ne sera pas recréé automatiquement en cas de panne du node. Le Deployment garantit que le nombre souhaité de réplicas est toujours respecté.

Définir les requests et limits de ressources. Sans ces valeurs, le scheduler ne peut pas placer intelligemment vos pods et un conteneur gourmand peut déstabiliser tout un node. Je recommande de fixer les requests à la consommation moyenne et les limits à 2 fois les requests pour absorber les pics.

Utiliser des labels structurés. Les labels sont le mécanisme de sélection dans Kubernetes. Adoptez une convention comme app, env, version, team dès le départ. Sans labels cohérents, la gestion devient chaotique à mesure que le nombre de pods augmente.

Configurer les probes systématiquement. La liveness probe et la readiness probe sont vos gardiennes en production. Sans elles, Kubernetes envoie du trafic vers des pods potentiellement défaillants. Selon les recommandations de la documentation Kubernetes francophone, ces sondes doivent être adaptées au comportement réel de votre application.

Limiter un processus par conteneur. Résistez à la tentation de regrouper plusieurs services dans un même conteneur. Le principe « un processus par conteneur » facilite le debugging, le scaling et les mises à jour indépendantes.

Si vous travaillez dans un environnement qui nécessite la virtualisation matérielle, assurez-vous qu’elle est bien activée sur vos machines avant de déployer votre cluster Kubernetes, car les nodes en ont besoin pour fonctionner de manière optimale.

Outils et commandes pour superviser vos pods

La supervision des pods est un aspect critique de l’exploitation quotidienne. Voici les outils et commandes que j’utilise le plus souvent dans mes environnements de travail et que j’enseigne en priorité :

kubectl top pods : affiche la consommation CPU et mémoire en temps réel de chaque pod. Nécessite le metrics-server installé dans le cluster. C’est votre premier réflexe pour identifier un pod qui consomme trop de ressources.

kubectl get pods -o wide : ajoute des colonnes utiles comme le node d’exécution et l’adresse IP du pod. Indispensable pour le debugging réseau.

kubectl logs -f –previous : le flag --previous affiche les logs du conteneur précédent (avant le dernier redémarrage). Crucial pour comprendre pourquoi un pod a crashé, car les logs du conteneur actuel ne contiennent pas l’erreur fatale.

Pour aller au-delà de la ligne de commande, plusieurs outils offrent une interface graphique pour gérer vos pods :

• Kubernetes Dashboard : l’interface web officielle, simple mais limitée
• Lens : un IDE Kubernetes complet avec visualisation en temps réel
• k9s : un outil terminal interactif, rapide et puissant
• Grafana + Prometheus : la stack de monitoring standard pour les métriques avancées

En tant que futur professionnel de l’infrastructure, maîtriser ces outils fait partie des compétences recherchées. Consultez notre article sur le salaire d’un chef de projet informatique pour voir comment ces compétences valorisent votre profil, ou explorez les opportunités de reconversion en informatique si vous venez d’un autre domaine. Les outils DevOps comme Ansible Tower complètent parfaitement l’écosystème Kubernetes pour l’automatisation globale de l’infrastructure.

L’intelligence artificielle commence également à transformer la gestion des clusters, avec des outils capables d’optimiser automatiquement le placement et le dimensionnement des pods en fonction des patterns de charge observés.

Lucie Moreau

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