Kubernetes 010 – Pods : manifests et outputs

TL;DR

Un manifest YAML rend un pod reproductible. Les outputs de kubectl, comme -o yaml, -o json ou -o wide, permettent d’observer l’objet sous differents angles. C’est une etape cle pour passer du test rapide a la configuration durable.

La video de reference

Video: https://www.youtube.com/watch?v=MbQllww-qRw

Elle prolonge l’episode sur les premiers pods en introduisant une approche plus declarative.

Pourquoi ecrire un manifest ?

Une commande est rapide, mais elle disparait de l’historique mental du projet. Un manifest peut etre relu, versionne, corrige et partage. Il sert aussi de base pour comprendre les champs apiVersion, kind, metadata et spec.

Exemple de manifest pod

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

kubectl apply -f pod.yaml
kubectl get pod web -o yaml
kubectl get pod web -o json
kubectl get pods -o wide

Lire les outputs

-o wide ajoute des colonnes utiles. -o yaml expose l’objet complet, y compris les champs ajoutes par Kubernetes. -o jsonpath permet d’extraire une valeur precise.

Liens utiles

• Video: https://www.youtube.com/watch?v=MbQllww-qRw
• Gestion declarative: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/
• Pods: https://kubernetes.io/docs/concepts/workloads/pods/
• Kubectl output: https://kubernetes.io/docs/reference/kubectl/

FAQ

Faut-il ecrire tout le YAML a la main ?

Pas toujours. On peut generer une base avec kubectl run --dry-run=client -o yaml, puis la nettoyer.

Pourquoi l’objet retourne par Kubernetes contient-il plus de champs ?

Parce que l’API enrichit l’objet avec des metadonnees, statuts et valeurs par defaut.

Quel output utiliser pour debug ?

describe et -o yaml sont souvent les plus utiles.

Differencier spec et status

Dans un objet Kubernetes, il faut souvent distinguer spec et status. La partie spec decrit ce que l’utilisateur demande. La partie status decrit ce que Kubernetes observe. Cette separation est fondamentale pour comprendre le declaratif.

Dans un pod, spec.containers decrit les conteneurs attendus. status.containerStatuses raconte ce qui est reellement arrive: image tiree, conteneur pret, redemarrages, dernier etat connu. Lire les deux parties ensemble permet de comprendre un ecart entre intention et realite.

Utiliser jsonpath pour cibler une information

Quand la sortie YAML devient trop longue, jsonpath permet d’extraire un champ:

kubectl get pod web -o jsonpath='{.status.phase}'
kubectl get pod web -o jsonpath='{.spec.containers[0].image}'
kubectl get pod web -o jsonpath='{.status.podIP}'

Ce n’est pas indispensable au premier jour, mais c’est tres pratique dans des scripts ou pour verifier rapidement une valeur.

Construire un manifest propre

Un manifest lisible ne doit pas contenir tout ce que l’API retourne. Quand on fait kubectl get pod web -o yaml, Kubernetes ajoute de nombreux champs: resourceVersion, uid, managedFields, status. Ces champs ne doivent generalement pas etre recopies dans un fichier source.

Un bon manifest contient ce que vous voulez vraiment maintenir: apiVersion, kind, metadata utile, spec, labels, containers, ports, volumes et options necessaires.

Erreurs frequentes

• Copier-coller tout le YAML retourne par l’API dans Git.
• Oublier que status est gere par Kubernetes, pas par l’utilisateur.
• Ne pas mettre de labels des le debut.
• Modifier un objet avec edit puis perdre la trace dans les fichiers.

Pour pratiquer

kubectl run web --image=nginx --dry-run=client -o yaml > pod.yaml
kubectl apply -f pod.yaml
kubectl get pod web -o yaml
kubectl get pod web -o jsonpath='{.status.phase}'

Comparez le fichier pod.yaml et la sortie complete de l’API. Cette comparaison fait comprendre la difference entre configuration voulue et objet vivant.

Nettoyer un YAML exporte

Quand on exporte un objet existant avec kubectl get pod web -o yaml, la sortie contient de nombreux champs geres par Kubernetes. Pour en faire un manifest propre, il faut retirer ce qui decrit l’objet vivant plutot que l’intention.

Champs generalement a ne pas conserver dans un fichier source:

• metadata.uid;
• metadata.resourceVersion;
• metadata.managedFields;
• metadata.creationTimestamp;
• toute la section status.

Conserver ces champs peut rendre le manifest bruyant, difficile a relire, voire impossible a appliquer correctement. Le fichier doit rester centre sur ce que l’on veut declarer.

Labels des le premier manifest

Ajouter des labels tot est une excellente habitude. Meme sur un pod de test, un label comme app: web permet ensuite de filtrer, selectionner et comprendre les relations entre objets:

kubectl get pods -l app=web
kubectl describe pod -l app=web

Plus tard, les Services, ReplicaSets et Deployments s’appuieront aussi sur les labels. Les prendre au serieux des les premiers manifests evite beaucoup de confusions.

Outputs utiles selon le besoin

Chaque format de sortie a son usage:

• -o wide pour une vue rapide enrichie;
• -o yaml pour lire l’objet complet;
• -o json pour l’exploitation par des outils;
• -o jsonpath pour extraire une valeur precise;
• --show-labels pour visualiser les labels directement dans une liste.

Le bon format depend de la question posee. Pour comprendre un probleme, describe et -o yaml sont souvent complementaires: l’un raconte les evenements, l’autre montre l’etat exact de l’objet.

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 011 – Pods : les multi-conteneurs, sidecars, adapters et ambassadors.

Conclusion

Les manifests et outputs transforment kubectl en outil d’apprentissage. On ne se contente plus de lancer un pod: on comprend l’objet que Kubernetes manipule.