infra / kubernetes

Les Pods

Leçon 31 exercice

Explication

Ce que vous allez apprendre

Définir le Pod comme la plus petite unité déployable de Kubernetes, et pourquoi ce n'est pas simplement "un conteneur"
Expliquer ce que les conteneurs d'un même Pod partagent (réseau, IP, volumes)
Distinguer le cas mono-conteneur (largement majoritaire) du pattern sidecar multi-conteneurs
Justifier pourquoi un Pod créé seul, sans objet de plus haut niveau, n'est jamais recréé automatiquement
Écrire un manifeste de Pod minimal en YAML et le déployer avec kubectl apply

Dans quel contexte ?

Un développeur teste rapidement une nouvelle image Docker en créant un Pod directement avec kubectl run mon-app --image=mon-app:latest. Tout fonctionne bien, jusqu'à ce que le node qui héberge ce Pod redémarre pour une mise à jour de sécurité planifiée. Le Pod disparaît purement et simplement, sans jamais être recréé, car aucun Deployment ne le surveillait. C'est exactement pourquoi, en dehors du débogage ponctuel, un Pod n'est presque jamais créé directement en production : un Deployment (leçon suivante) s'en charge à sa place.

Le plus petit objet manipulable par Kubernetes

D'abord, il faut savoir que Kubernetes ne manipule jamais un conteneur isolé : sa plus petite unité est le Pod. Pourquoi cette couche supplémentaire ?

Prérequis

Cette leçon suppose que vous avez un cluster local fonctionnel et savez utiliser kubectl get, kubectl describe et kubectl apply, vus à la leçon précédente.

Le besoin derrière cette couche

Certaines applications ont besoin de plusieurs processus étroitement liés, qui doivent tourner ensemble, sur la même machine, et partager le même réseau local. Le Pod encapsule exactement ce groupe.

Une image simple pour comprendre le partage

Pense à une colocation : les conteneurs d'un même Pod partagent la même adresse IP et peuvent se parler via localhost, exactement comme des colocataires partagent la même adresse postale.

Le cas de très loin le plus courant

Dans l'immense majorité des cas, un Pod ne contient qu'UN seul conteneur : c'est la situation la plus simple, et celle que tu rencontreras le plus souvent dans ce cours.

Un cas plus avancé : le sidecar

Le cas multi-conteneurs existe aussi, avec un "sidecar" : un conteneur compagnon qui apporte une fonctionnalité annexe, comme la synchronisation de fichiers ou la collecte de logs. Réserve ce pattern à des besoins précis, pas comme réflexe par défaut.

Cas	Nombre de conteneurs dans le Pod	Exemple
Cas standard (large majorité)	1	Une API REST, un serveur web
Sidecar	2 ou plus	Application + agent de collecte de logs
Init container	Conteneurs exécutés avant les autres, puis terminés	Préparation de configuration, migration de base

Un point essentiel à retenir dès maintenant

Un Pod n'est pas fait pour durer. S'il plante, ou si le node qui l'héberge tombe, il disparaît, et rien ne le recrée automatiquement si tu l'as créé "tout nu", directement, sans passer par un objet de plus haut niveau.

Piège fréquent

Créer un Pod directement (kubectl run sans Deployment) ne donne aucune résilience : si le Pod plante ou si son node tombe, rien ne le recrée automatiquement. Cette confusion entre "Pod" et "objet résilient" est l'une des erreurs les plus fréquentes chez les débutants Kubernetes.

Le piège classique du débutant

Beaucoup de débutants créent des Pods directement en pensant obtenir de la résilience. Ce n'est pas le cas : la vraie résilience viendra du Deployment, l'objet de la prochaine leçon, qui surveille et recrée les Pods à ta place.

Une bonne pratique à prendre dès le premier manifeste

Enfin, chaque conteneur devrait déclarer combien de CPU et de mémoire il a besoin (requests) et le maximum qu'il peut consommer (limits). Sans cela, un conteneur mal codé peut monopoliser toute la mémoire d'un node et faire tomber les autres applications qui s'y trouvent.

Maintenant que tu connais les limites d'un Pod isolé, la leçon suivante introduit le Deployment, qui comble précisément ce manque de résilience.

Commandes & code

Pods

Le Pod est la plus petite unité déployable : un ou plusieurs conteneurs partageant réseau et stockage.

# pod-simple.yaml
apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels:
    app: web
spec:
  containers:
    - name: nginx
      image: nginx:1.27-alpine
      ports:
        - containerPort: 80
      resources:
        requests:
          cpu: "100m"
          memory: "128Mi"
        limits:
          cpu: "250m"
          memory: "256Mi"

kubectl apply -f pod-simple.yaml
kubectl get pods -o wide
kubectl port-forward pod/web-pod 8080:80   # accéder au Pod depuis localhost:8080

# Pod multi-conteneurs : sidecar qui synchronise du contenu pour nginx
apiVersion: v1
kind: Pod
metadata:
  name: web-with-sidecar
spec:
  volumes:
    - name: shared-html
      emptyDir: {}
  containers:
    - name: nginx
      image: nginx:1.27-alpine
      volumeMounts:
        - name: shared-html
          mountPath: /usr/share/nginx/html
    - name: content-sync
      image: alpine/git
      command: ["sh", "-c", "while true; do git pull; cp -r repo/* /html; sleep 60; done"]
      volumeMounts:
        - name: shared-html
          mountPath: /html

# Les Pods sont éphémères : ne JAMAIS créer un Pod nu en production (voir Deployments)
kubectl delete pod web-pod
# -> disparaît définitivement, rien ne le recrée automatiquement

kubectl get events --sort-by=.lastTimestamp   # comprendre pourquoi un Pod est en Pending/CrashLoop

Résumé

Un Pod = groupe de conteneurs partageant réseau (localhost) et volumes.
Les conteneurs d'un même Pod communiquent via localhost et des ports différents.
Un Pod créé "nu" n'est pas auto-réparé : utiliser un Deployment en pratique.
requests/limits doivent être définis dès le premier manifest, pas ajoutés après coup.

Exercices pratiques

1 disponible

Mission : sauver une démo fragile

Objectif : Diagnostiquer pourquoi un Pod créé directement disparaît après un redémarrage de node, et corriger le manifeste pour respecter les bonnes pratiques de resources.

Contexte

Un collègue a testé rapidement une image avec kubectl run mon-app --image=mon-app:latest. La démo tournait très bien jusqu'à ce matin, où une mise à jour de sécurité planifiée a redémarré le node qui hébergeait ce Pod. Le Pod a disparu et personne ne comprend pourquoi rien ne l'a recréé. Tu dois expliquer ce qui s'est passé et proposer un manifeste corrigé.

Résoudre l’exercice →