Le Pod est la plus petite unité que Kubernetes place et fait tourner. Un ou plusieurs conteneurs y partagent le réseau, le hostname et, souvent, des volumes. Ils se voient en localhost, et ils naissent et meurent ensemble. C’est l’unité d’exécution, pas l’unité de gestion.
Un Pod créé à la main — kubectl run oublié, un manifeste kind: Pod appliqué tel quel — a un propriétaire : vous. Personne d’autre.
Si le conteneur meurt, le kubelet le relance sur le même nœud, selon restartPolicy. Si le nœud disparaît, le Pod disparaît avec lui. Pas de réplica de remplacement, pas de mise à jour progressive, pas d’historique à annuler. Vous avez un processus, pas un service.
C’est pour cela que, hors diagnostic ponctuel, on déclare un contrôleur :
Le contrôleur possède le Pod. C’est lui qui le recrée ailleurs, qui en tient trois, qui en remplace un pendant un rolling update.
Pas la définition du pause container. Il vérifie que vous avez compris la frontière : le Pod est jetable par conception. Le traiter comme un serveur nommé, auquel on se connecte en SSH et qu’on soigne, est le réflexe qui trahit quelqu’un qui vient de la VM et n’a pas encore changé de modèle.
La phrase qui clôt la réponse : vous déclarez l’état désiré — « je veux deux exemplaires de cette image, prêts avant de recevoir du trafic » — et vous laissez le contrôleur le maintenir. Vous ne « lancez » pas un Pod en production.
« Alors à quoi sert encore un manifeste de Pod ? »
À deux choses, et seulement celles-là. D’abord, le champ template d’un Deployment est un Pod : c’est là que vous écrivez sondes, ressources, volumes. Ensuite, un Pod nu reste utile pour un debug éphémère — un kubectl debug, un conteneur de dépannage que vous détruisez ensuite. Ce n’est pas un mode de vie.
La chaîne complète, de l’image jusqu’au Service, est dans Docker et Kubernetes : qui fait quoi. Pourquoi le Deployment est le premier objet à apprendre plutôt que le Pod, dans votre premier Deployment vraiment fiable.