Kubernetes 037 – Affinites : required de podAffinity et nodeAffinity

TL;DR

Les affinites permettent d’influencer ou d’imposer le placement des pods. nodeAffinity selectionne des noeuds selon leurs labels. podAffinity place un pod pres d’autres pods selon leurs labels et une cle de topologie. En mode required, la contrainte est obligatoire: si elle n’est pas satisfaite, le pod reste pending.

La video de reference

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

L’episode introduit les contraintes fortes du scheduler avant les preferences et les strategies plus souples.

Pourquoi parler d’affinite ?

Par defaut, Kubernetes essaie de placer les pods sur des noeuds disponibles. Mais certaines applications ont des contraintes: disque local, zone, type de machine, proximite avec un cache, separation par environnement.

Les affinites expriment ces contraintes dans le manifest, au lieu de choisir manuellement un noeud.

Labels de noeuds

Avant d’utiliser nodeAffinity, il faut des labels exploitables:

kubectl label node worker1 disk=ssd
kubectl label node worker2 disk=hdd
kubectl get nodes --show-labels

Un label doit representer une caracteristique stable ou utile pour le placement.

nodeAffinity required

apiVersion: v1
kind: Pod
metadata:
  name: nginx-ssd
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disk
                operator: In
                values:
                  - ssd
  containers:
    - name: nginx
      image: nginx

Ici, le pod ne peut etre planifie que sur un noeud avec disk=ssd.

Required signifie obligatoire

Si aucun noeud ne correspond, le pod reste en Pending. C’est volontaire: Kubernetes respecte la contrainte au lieu de la contourner.

Pour diagnostiquer:

kubectl get pod nginx-ssd
kubectl describe pod nginx-ssd

Les events expliquent souvent que le scheduler n’a trouve aucun noeud compatible.

podAffinity required

podAffinity raisonne par rapport a d’autres pods. Exemple: placer un pod applicatif sur le meme noeud qu’un pod portant app=cache.

apiVersion: v1
kind: Pod
metadata:
  name: app-near-cache
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - cache
          topologyKey: kubernetes.io/hostname
  containers:
    - name: app
      image: nginx

La cle topologyKey indique le niveau de proximite: ici le meme noeud.

Importance de topologyKey

topologyKey peut pointer vers le hostname, une zone, un rack ou un autre label de topologie. Le scheduler cherche des domaines topologiques ou les pods cibles existent deja.

Avec kubernetes.io/hostname, on parle du meme noeud. Avec une cle de zone, on parle de la meme zone.

Difference avec nodeSelector

nodeSelector est plus simple, mais moins expressif. nodeAffinity permet des operateurs comme In, NotIn, Exists et des termes multiples.

Pour une contrainte simple, nodeSelector peut suffire. Pour des regles evolutives, nodeAffinity est plus flexible.

Commandes utiles

kubectl get nodes --show-labels
kubectl label node worker1 role=frontend
kubectl apply -f pod-affinity.yaml
kubectl describe pod app-near-cache
kubectl get pods -o wide

Toujours verifier la colonne NODE apres un test d’affinite.

Liens utiles

• Video: https://www.youtube.com/watch?v=A0Q04eIg1kA
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Node affinity: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
• Scheduling: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/

FAQ

Que signifie IgnoredDuringExecution ?

La regle est verifiee au scheduling. Si les labels changent ensuite, le pod n’est pas automatiquement expulse.

Peut-on bloquer tout un deploiement avec required ?

Oui. Une contrainte trop stricte peut laisser tous les pods en Pending.

Faut-il preferer affinity a nodeName ?

Oui dans la plupart des cas. nodeName force un noeud precis et contourne une partie de la logique du scheduler.

Erreurs frequentes

• Oublier de labelliser les noeuds avant de tester.
• Utiliser une cle topologyKey absente des noeuds.
• Mettre une contrainte required alors qu’une preference suffirait.
• Confondre podAffinity et nodeAffinity.

Pour pratiquer

Creez deux noeuds labels differemment, deployeez un pod qui exige disk=ssd, puis retirez le label pour observer le comportement d’un pod deja lance et d’un nouveau pod.

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 038 – Affinities : preferences et skew.

Conclusion

Les affinites required donnent un pouvoir fort sur le scheduler. Elles doivent etre utilisees quand la contrainte est reelle, pas seulement pour orienter legerement le placement.