Kubernetes 025 – Labels et Annotations : pourquoi, comment, demo

TL;DR

Les labels sont faits pour organiser et selectionner les objets Kubernetes. Les annotations stockent des informations non identifiantes pour des outils, controleurs ou conventions. Les deux vivent dans metadata, mais ils n’ont pas le meme role.

La video de reference

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

Elle formalise une notion deja croisee avec ReplicaSet, Deployment et Service.

Labels

Un label est une paire cle-valeur. Il sert a filtrer et a relier des objets.

metadata:
  labels:
    app: web
    component: frontend
    environment: dev

Les Services et controleurs utilisent les labels via des selectors.

Annotations

Une annotation est aussi une paire cle-valeur, mais elle n’est pas destinee a la selection.

metadata:
  annotations:
    description: "frontend nginx de demo"
    owner: "team-platform"

On y met des informations pour des outils, des traces, des URLs ou des configurations non selectives.

Selectionner

kubectl get pods -l app=web
kubectl get pods -l 'environment in (dev,staging)'
kubectl get all -l app=web --show-labels

Les selectors sont partout dans Kubernetes. Des labels propres rendent le cluster lisible.

Modifier

kubectl label pod <pod> environment=dev
kubectl label pod <pod> environment=prod --overwrite
kubectl annotate pod <pod> note='test debug'

En production, il est preferable que les labels importants soient dans les manifests versionnes.

Liens utiles

• Video: https://www.youtube.com/watch?v=5b3kkJ0pUjA
• Labels and selectors: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
• Annotations: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
• Recommended labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

FAQ

Peut-on selectionner avec une annotation ?

Non, pas pour les selectors Kubernetes standards.

Un label peut-il changer ?

Oui, mais il faut etre prudent si un Service ou un controleur depend de lui.

Faut-il standardiser les labels ?

Oui. Des conventions comme app.kubernetes.io/name aident beaucoup.

Erreurs frequentes

• Mettre trop d’information variable dans les labels.
• Utiliser des annotations pour selectionner mentalement des objets.
• Changer un label utilise par un Service sans verifier les endpoints.
• Oublier --show-labels pendant le debug.

Pour pratiquer

kubectl create deployment web --image=nginx
kubectl label deployment web environment=dev
kubectl get deploy -l environment=dev
kubectl annotate deployment web owner=formation
kubectl describe deploy web

Notions et definitions

• ConfigMap: configuration non sensible injectee dans les pods.
• Secret: donnees sensibles encodees et gerees comme ressource Kubernetes.
• Label et annotation: metadata servant respectivement a selectionner et a documenter/enrichir les objets.

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

Une application peut lire son niveau de log depuis une ConfigMap et son mot de passe depuis un Secret, sans reconstruire l’image Docker.

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

• Sortir les valeurs variables de l’image applicative.
• Creer une ConfigMap ou un Secret selon la sensibilite de la donnee.
• Injecter la valeur en variable d’environnement ou en fichier monte.
• Verifier dans le pod que la valeur est disponible au bon endroit.

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 la separation entre image applicative, configuration, metadata et parametrage d’execution. 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 configmap,secret --show-labels
• kubectl describe pod <pod> pour verifier variables, volumes et references
• kubectl get all -l <cle>=<valeur> pour valider l’usage des labels

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

• stocker une configuration variable directement dans l’image
• confondre Secret Kubernetes et coffre-fort de secrets complet
• sous-estimer l’importance des labels pour filtrer, selectionner et automatiser

Exercice conseille

Externalisez une variable d’environnement dans une ConfigMap, montez-la dans un pod, changez sa valeur, puis observez ce qui change sans redeployer et ce qui demande un redemarrage.

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 026 – ConfigMap et Secrets : variables, fichiers et montage.

Conclusion

Labels et annotations rendent les objets Kubernetes exploitables a grande echelle. Les labels structurent l’action, les annotations enrichissent le contexte.