Kubernetes 039 – Affinites : le podAntiAffinity

TL;DR

podAntiAffinity exprime une contrainte d’eloignement entre pods. Elle est utile pour eviter que plusieurs replicas d’une meme application finissent sur le meme noeud. En mode required, elle peut bloquer le scheduling. En mode preferred, elle oriente le placement sans garantir le resultat.

La video de reference

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

L’episode se concentre sur le cas inverse de podAffinity: ne pas colocaliser certains pods.

Pourquoi eloigner des pods ?

Si trois replicas d’une application tournent sur le meme noeud, la panne de ce noeud coupe tous les replicas. Kubernetes peut les recreer ailleurs, mais il y a une interruption plus forte que si les replicas etaient deja repartis.

podAntiAffinity aide a repartir les pods pour ameliorer la resilience.

Exemple required

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - web
              topologyKey: kubernetes.io/hostname
      containers:
        - name: nginx
          image: nginx

Cette regle demande a ne pas mettre deux pods app=web sur le meme hostname.

Attention au nombre de noeuds

Avec 3 replicas et seulement 2 noeuds, une anti-affinite required par hostname rendra un pod impossible a scheduler. Il restera en Pending.

Cette situation est normale: la demande est mathematiquement impossible.

Version preferred

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: web
          topologyKey: kubernetes.io/hostname

Ici, Kubernetes essaie de repartir les pods, mais peut en placer deux ensemble si le cluster ne permet pas mieux.

topologyKey

La cle topologyKey definit ce que signifie "ensemble". Avec kubernetes.io/hostname, on parle du meme noeud. Avec une zone, on parle de la meme zone.

Le choix depend du risque que l’on veut reduire: panne d’un noeud, d’une zone, d’un rack ou d’un domaine logique.

Comparaison avec topologySpreadConstraints

podAntiAffinity exprime une interdiction ou une preference d’eloignement. topologySpreadConstraints exprime une repartition plus quantitative avec maxSkew.

Pour un usage moderne, topology spread est souvent plus direct pour repartir des replicas. Mais podAntiAffinity reste tres utile et tres courant.

Commandes de diagnostic

kubectl apply -f deploy-web.yaml
kubectl get pods -l app=web -o wide
kubectl describe pod <pod-pending>
kubectl get events --sort-by=.metadata.creationTimestamp

Les events du scheduler indiquent pourquoi un pod ne trouve pas de noeud.

Liens utiles

• Video: https://www.youtube.com/watch?v=e4dpaiIEltk
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Inter-pod affinity and anti-affinity: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
• Topology spread constraints: https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/

FAQ

Anti-affinity garantit-elle la haute disponibilite ?

Non. Elle ameliore le placement, mais il faut aussi des probes, ressources, replicas, PDB et une architecture applicative correcte.

Pourquoi mon pod reste Pending ?

La contrainte required est probablement impossible a satisfaire avec les noeuds disponibles.

Peut-on utiliser anti-affinity entre applications differentes ?

Oui, le selecteur peut viser une autre application si leurs labels sont bien definis.

Erreurs frequentes

• Demander plus de separation que le nombre de noeuds ne permet.
• Oublier les labels sur les pods cibles.
• Utiliser une topologie non presente sur les noeuds.
• Confondre anti-affinity et taints/tolerations.

Pour pratiquer

Lancez un Deployment a 3 replicas sur un cluster a 2 workers avec anti-affinite required. Observez le pod Pending, puis passez en preferred pour comparer.

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 040 – Affinities : persistent volumes with nodeAffinity.

Conclusion

podAntiAffinity est un outil de placement puissant pour reduire les risques de colocalisation. Il faut toutefois adapter la durete de la regle a la capacite reelle du cluster.