Kubernetes 038 – Affinities : preferences et skew

TL;DR

Les preferences d’affinite orientent le scheduler sans bloquer le pod si la condition n’est pas possible. Les contraintes de repartition, avec topologySpreadConstraints et maxSkew, permettent d’eviter de concentrer tous les replicas sur le meme domaine topologique.

La video de reference

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

Elle complete l’episode sur les affinites required avec une approche plus souple du placement.

Required vs preferred

Une regle required est obligatoire. Une regle preferred est un souhait. Le scheduler essaie de la respecter, mais peut placer le pod ailleurs si necessaire.

Cette difference est importante pour la disponibilite. Une preference mal satisfaite lance quand meme l’application; une contrainte required trop stricte peut la bloquer.

Exemple de nodeAffinity preferee

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 80
              preference:
                matchExpressions:
                  - key: disk
                    operator: In
                    values:
                      - ssd
      containers:
        - name: nginx
          image: nginx

Le poids indique l’importance relative de cette preference dans le calcul du scheduler.

Pourquoi utiliser une preference ?

Une preference convient quand le placement ideal est souhaitable mais pas vital. Par exemple, utiliser des noeuds SSD pour de meilleures performances, sans empecher l’application de demarrer si ces noeuds sont pleins.

La preference evite les labs ou productions bloques par une regle trop dure.

Topology spread constraints

Les topologySpreadConstraints servent a repartir des pods sur plusieurs domaines: noeuds, zones, racks, etc. Elles repondent a une autre question: comment eviter que tous les replicas soient au meme endroit ?

Exemple de repartition par hostname:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 4
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: api
      containers:
        - name: nginx
          image: nginx

Comprendre maxSkew

maxSkew definit l’ecart maximal autorise entre domaines topologiques. Avec maxSkew: 1, Kubernetes essaie de ne pas avoir beaucoup plus de pods dans un domaine que dans un autre.

La valeur doit etre adaptee au nombre de replicas et au nombre de domaines disponibles.

whenUnsatisfiable

Deux comportements sont possibles:

• DoNotSchedule: la contrainte bloque le scheduling si elle n’est pas respectee;
• ScheduleAnyway: le scheduler essaie de respecter la repartition, mais peut continuer.

Ce choix ressemble a la difference entre required et preferred.

Observer le placement

kubectl apply -f deploy-api.yaml
kubectl get pods -l app=api -o wide
kubectl describe pod <pod>
kubectl get nodes --show-labels

La colonne NODE donne rapidement une idee de la repartition.

Liens utiles

• Video: https://www.youtube.com/watch?v=zXCFyKc1_H4
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Pod topology spread constraints: https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/
• Assign pods to nodes: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/

FAQ

Une preference garantit-elle le placement ?

Non. Elle influence le score du scheduler, mais ne garantit pas le resultat.

maxSkew remplace-t-il podAntiAffinity ?

Pas totalement. Les deux peuvent aider a repartir, mais topology spread est souvent plus lisible pour l’equilibrage.

Faut-il toujours utiliser ScheduleAnyway ?

Non. Pour une contrainte de disponibilite forte, DoNotSchedule peut etre justifie.

Erreurs frequentes

• Croire qu’une preference est une obligation.
• Utiliser un labelSelector qui ne correspond pas aux pods.
• Oublier que la topologie depend des labels presents sur les noeuds.
• Choisir maxSkew sans tenir compte du nombre de replicas.

Pour pratiquer

Creez un Deployment a 6 replicas sur 3 workers, puis comparez le placement avec et sans topologySpreadConstraints. Changez ensuite ScheduleAnyway en DoNotSchedule.

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 039 – Affinites : le podAntiAffinity.

Conclusion

Les preferences et le skew permettent de guider Kubernetes sans toujours bloquer le scheduling. C’est une approche plus souple et souvent plus adaptee aux environnements reels.