Kubernetes 005 – Le Pod : c’est quoi ?

TL;DR

Un Pod est la plus petite unite deployable dans Kubernetes. Il encapsule un ou plusieurs conteneurs qui partagent un reseau, une adresse IP, des volumes et un cycle de vie commun. En pratique, on manipule souvent les pods via des controleurs comme Deployment ou ReplicaSet.

La video de reference

Video: https://www.youtube.com/watch?v=maD16sgsFTY

Elle marque l’entree dans les objets concrets de Kubernetes.

Un pod n’est pas juste un conteneur

Un conteneur execute un processus isole. Un pod est une enveloppe Kubernetes autour d’un ou plusieurs conteneurs. Tous les conteneurs d’un meme pod partagent le meme namespace reseau: meme IP, memes ports, communication locale possible via localhost.

Ce choix permet de regrouper des conteneurs qui doivent vivre ensemble, par exemple une application et un sidecar.

Exemple minimal de pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

Application:

kubectl apply -f pod.yaml
kubectl get pods
kubectl describe pod nginx

Pourquoi Kubernetes ne recommande pas toujours de creer des pods seuls

Un pod seul n’offre pas de logique de remplacement avancee. S’il disparait, il n’est pas necessairement recree comme on l’attendrait dans une application durable. Pour cela, Kubernetes utilise des controleurs comme ReplicaSet ou Deployment.

Liens utiles

• Video: https://www.youtube.com/watch?v=maD16sgsFTY
• Documentation Pods: https://kubernetes.io/docs/concepts/workloads/pods/
• Cycle de vie des pods: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
• Depot Xavki: https://gitlab.com/xavki/tutorials-kubernetes-v2

FAQ

Combien de conteneurs dans un pod ?

Le cas le plus courant est un conteneur applicatif principal. Plusieurs conteneurs sont possibles quand ils partagent un meme cycle de vie.

Un pod a-t-il sa propre IP ?

Oui, Kubernetes attribue une IP au pod. Les conteneurs du pod partagent cette IP.

Faut-il deployer des pods directement en production ?

Generalement non. On passe plutot par des controleurs comme Deployment.

Anatomie d’un pod

Un pod contient principalement des metadonnees et une specification. Les metadonnees donnent un nom, des labels et parfois des annotations. La specification decrit les conteneurs, les images, les ports, les volumes, les variables d’environnement, les probes et les contraintes d’execution.

Cette structure est importante car Kubernetes ne manipule pas directement votre code. Il manipule des objets. Le pod devient donc la fiche d’identite technique de l’execution applicative.

Ce que les conteneurs partagent dans un pod

Dans un meme pod, les conteneurs partagent le reseau. Cela veut dire qu’ils peuvent communiquer via localhost. Ils peuvent aussi partager des volumes declares au niveau du pod. En revanche, chaque conteneur garde son image, son processus et ses logs.

Cette logique explique pourquoi un pod multi-conteneurs doit rester une exception reflechie. Si deux composants n’ont pas besoin de partager reseau, volumes et cycle de vie, ils meritent souvent deux pods separes.

Cycle de vie simplifie

Un pod peut etre cree, planifie, execute, redemarre ou termine. Kubernetes suit aussi des conditions comme Ready, qui ne signifie pas seulement que le conteneur tourne, mais qu’il est considere pret a recevoir du trafic si des probes sont configurees.

Pour observer ce cycle de vie:

kubectl get pod nginx -w
kubectl describe pod nginx
kubectl logs nginx

Erreurs frequentes

• Croire qu’un pod est equivalent a une application complete.
• Oublier qu’un pod est ephemere: son nom et son IP ne sont pas des points d’ancrage stables.
• Mettre plusieurs services independants dans un meme pod.
• Lire seulement kubectl get pods sans regarder describe et les events.

Pour pratiquer

Essayez de creer un pod, de le decrire, puis de supprimer son conteneur en provoquant une erreur d’image:

kubectl run test --image=nginx
kubectl describe pod test
kubectl delete pod test
kubectl run bad --image=image-qui-nexiste-pas
kubectl describe pod bad

L’objectif est de voir comment Kubernetes remonte les informations et comment les events expliquent les problemes.

Pod, application et service: ne pas tout melanger

Un pod execute une charge de travail, mais il ne fournit pas a lui seul tous les elements necessaires pour une application exploitable. Il n’offre pas un nom stable, il peut changer d’IP, et il ne porte pas la strategie de mise a jour. C’est pour cela qu’on le retrouve souvent derriere d’autres objets Kubernetes.

Dans une application reelle, un Deployment gere la creation et le remplacement des pods, un Service fournit un point d’acces stable, et parfois un Ingress expose l’application vers l’exterieur. Le pod reste donc essentiel, mais il n’est qu’une brique dans un ensemble plus large.

Cette distinction aide beaucoup au debut. Quand un pod ne repond pas, on cherche dans les logs, le status et les events. Quand une application n’est pas joignable, il faut aussi verifier le Service, les selectors, les endpoints, le DNS et l’exposition reseau.

Champs a regarder dans un manifest

Dans un manifest de pod, certains champs deviennent vite familiers:

• metadata.name donne le nom de l’objet;
• metadata.labels permet de classer et selectionner le pod;
• spec.containers liste les conteneurs attendus;
• image indique l’image a tirer;
• ports documente les ports exposes par le conteneur;
• volumeMounts et volumes relient le pod a du stockage.

Il ne faut pas chercher a tout apprendre d’un coup. Le bon reflexe consiste a partir d’un manifest minimal, puis a ajouter les champs au fur et a mesure des besoins: variables d’environnement, probes, ressources, volumes, contraintes de placement.

Exemple de lecture d’un probleme

Supposons un pod en ImagePullBackOff. Le probleme ne vient probablement pas du code applicatif, car le conteneur n’a meme pas demarre. Il faut plutot verifier le nom de l’image, le tag, l’acces a la registry et les secrets de pull.

Supposons maintenant un pod en CrashLoopBackOff. L’image a ete tiree, le conteneur demarre, puis il s’arrete. On lit alors les logs, si besoin avec --previous, puis les events. Cette methode evite de diagnostiquer au hasard.

Notions et definitions

• Pod: plus petite unite deployable dans Kubernetes.
• Controleur: objet qui maintient un etat attendu, comme Deployment, ReplicaSet, DaemonSet ou StatefulSet.
• Reconciliation: boucle permanente qui compare l’etat reel et l’etat desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment a trois replicas recree automatiquement un pod supprime afin de revenir a l’etat attendu declare dans sa specification.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Declarer le workload avec un manifest YAML ou une commande kubectl.
• Observer les pods crees et leurs labels.
• Lire les events pour comprendre scheduling, pulls d’images et redemarrages.
• Modifier le controleur plutot que les pods generes directement.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le passage d’un conteneur isole a un workload controle par Kubernetes. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pods -o wide --show-labels
• kubectl describe pod <pod> pour lire scheduling, events et conditions
• kubectl rollout history deployment/<name> quand un Deployment est concerne

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• modifier un pod gere par un controleur au lieu de modifier le controleur lui-meme
• ignorer les events alors qu’ils expliquent souvent le probleme
• oublier que les labels sont le lien entre controleurs, pods et Services

Exercice conseille

Lancez un Deployment nginx a trois replicas, supprimez un pod manuellement, puis observez comment le controleur reconcilie l’etat attendu.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 006 – Cluster : le lightweight de K0s pour debuter.

Conclusion

Comprendre le pod est indispensable: presque tous les objets de workload finissent par creer ou gerer des pods. C’est la brique de base avant les ReplicaSets, Deployments et mecanismes de scaling.