Scheduling avancé : Affinity, Taints, Tolerations et Topology Spread

Kubernetes ne programme pas les Pods “au hasard”. Vous pouvez contrôler précisément où s’exécutent vos workloads grâce à plusieurs mécanismes complémentaires. Ce guide présente les outils modernes de scheduling : du simple nodeSelector jusqu’aux topologySpreadConstraints pour la haute disponibilité.

Ce que vous allez apprendre

• Cibler des nœuds spécifiques avec nodeSelector et nodeAffinity
• Gérer les relations entre Pods avec podAffinity / podAntiAffinity
• Répartir proprement les replicas avec topologySpreadConstraints
• Protéger et réserver des nœuds avec taints / tolerations
• Débugger les Pods bloqués en Pending

Vue d’ensemble des mécanismes

Mécanisme	Objectif	Agit sur
nodeName	Forcer un nœud précis (bypass scheduler)	Nœud
nodeSelector	Filtrer par labels (simple)	Nœud
nodeAffinity	Filtrer par labels (avancé, préférence/contrainte)	Nœud
podAffinity	Rapprocher des Pods liés	Pods
podAntiAffinity	Éloigner des Pods	Pods
topologySpreadConstraints	Répartir les replicas entre domaines	Topologie
taints / tolerations	Protéger/réserver des nœuds	Nœud

Glissez pour voir

Message clé

• nodeSelector et nodeAffinity servent à cibler des nœuds
• taints/tolerations servent à protéger ou réserver des nœuds
• podAffinity / podAntiAffinity servent à gérer les relations entre Pods
• topologySpreadConstraints sert à répartir proprement les replicas

Labels standardisés Kubernetes

Kubernetes définit des labels standardisés pour la topologie. Préférez-les aux labels custom quand ils existent :

Label	Description
kubernetes.io/hostname	Nom du nœud
topology.kubernetes.io/zone	Zone de disponibilité
topology.kubernetes.io/region	Région
node.kubernetes.io/instance-type	Type d’instance (cloud)

Glissez pour voir

# Voir les labels d'un nœud
kubectl get nodes --show-labels

1. nodeName : contourner le scheduler

Le champ nodeName lie directement un Pod à un nœud, sans passer par le scheduler.

apiVersion: v1
kind: Pod
metadata:
  name: pod-on-specific-node
spec:
  containers:
  - name: my-container
    image: my-image
  nodeName: my-node-1

nodeName contourne le scheduler

nodeName bypass complètement le scheduler. Le Pod est directement lié au nœud indiqué ; si ce nœud ne peut pas l’exécuter (inexistant, indisponible, ressources insuffisantes), Kubernetes ne cherchera pas automatiquement un autre nœud.

Cas d’usage :

• Dépannage ou tests sur un nœud précis
• Situations très spécifiques où vous savez exactement où placer le Pod

À éviter en production — préférez nodeSelector ou nodeAffinity pour des règles dynamiques.

2. nodeSelector : le filtre simple

nodeSelector est la méthode la plus simple pour contraindre un Pod à des nœuds ayant un label spécifique.

Poser un label sur un nœud

kubectl label nodes node-gpu accelerator=nvidia-gpu

Utiliser nodeSelector

apiVersion: v1
kind: Pod
metadata:
  name: pod-gpu
spec:
  containers:
  - name: my-container
    image: my-image
  nodeSelector:
    accelerator: nvidia-gpu

• Seuls les nœuds ayant accelerator=nvidia-gpu peuvent accueillir ce Pod
• Si aucun nœud ne correspond, le Pod reste en Pending
• Limitation : égalités strictes uniquement (key=value)

3. nodeAffinity : préférences et contraintes

nodeAffinity offre plus de flexibilité que nodeSelector avec deux modes :

Mode	Comportement
requiredDuringSchedulingIgnoredDuringExecution	Obligatoire — le Pod ne sera pas programmé si aucun nœud ne correspond
preferredDuringSchedulingIgnoredDuringExecution	Préférence — Kubernetes essaie de respecter la règle, mais peut la contourner

Glissez pour voir

IgnoredDuringExecution

Ces contraintes ne s’appliquent qu’au moment du scheduling. Si un nœud devient inéligible après coup, le Pod n’est pas automatiquement déplacé.

Affinité obligatoire

apiVersion: v1
kind: Pod
metadata:
  name: pod-gpu-required
spec:
  containers:
  - name: my-container
    image: my-image
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: accelerator
            operator: In
            values:
            - nvidia-gpu
            - amd-gpu

Le Pod ne sera programmé que sur un nœud avec accelerator=nvidia-gpu ou accelerator=amd-gpu.

Affinité préférée

apiVersion: v1
kind: Pod
metadata:
  name: pod-gpu-preferred
spec:
  containers:
  - name: my-container
    image: my-image
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        preference:
          matchExpressions:
          - key: accelerator
            operator: In
            values:
            - nvidia-gpu

Kubernetes préférera un nœud GPU, mais programmera le Pod ailleurs si aucun n’est disponible.

Opérateurs disponibles

Opérateur	Description
In	La valeur est dans la liste
NotIn	La valeur n’est pas dans la liste
Exists	La clé existe (peu importe la valeur)
DoesNotExist	La clé n’existe pas
Gt	Valeur supérieure à (numérique)
Lt	Valeur inférieure à (numérique)

Glissez pour voir

4. podAffinity et podAntiAffinity : relations entre Pods

Ces mécanismes influencent la répartition des Pods les uns par rapport aux autres, pas par rapport aux nœuds.

podAffinity : rapprocher des Pods

Utile pour réduire la latence entre services liés (ex : application + cache Redis).

apiVersion: v1
kind: Pod
metadata:
  name: web-app
  labels:
    app: web
spec:
  containers:
  - name: web-container
    image: my-web-image
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - redis
        topologyKey: kubernetes.io/hostname

Ce Pod sera programmé sur le même nœud qu’un Pod ayant app=redis.

podAntiAffinity : éloigner des Pods

Utile pour éviter les SPOF — répartir les replicas d’un même service.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
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: web-container
        image: my-web-image

Kubernetes empêchera plusieurs Pods app=web de tourner sur le même nœud.

topologyKey : niveau de la contrainte

topologyKey	Effet
kubernetes.io/hostname	Répartition par nœud
topology.kubernetes.io/zone	Répartition par zone
topology.kubernetes.io/region	Répartition par région

Glissez pour voir

Coût de l'inter-pod affinity/anti-affinity

L’inter-pod affinity et anti-affinity peuvent ralentir significativement le scheduling dans les grands clusters (centaines de nœuds, milliers de Pods). Pour de simples besoins de répartition de replicas, topologySpreadConstraints est souvent préférable.

5. topologySpreadConstraints : répartir proprement les replicas

topologySpreadConstraints est le mécanisme moderne pour contrôler la répartition des Pods entre domaines de topologie (nœuds, zones, régions). Il est souvent plus adapté que podAntiAffinity pour la haute disponibilité.

Pourquoi utiliser topologySpreadConstraints ?

Besoin	podAntiAffinity	topologySpreadConstraints
”Jamais 2 Pods sur le même nœud”	✅ Strict	⚠️ Possible mais pas l’usage principal
”Répartir équitablement entre zones”	⚠️ Complexe	✅ Conçu pour
”Tolérer un léger déséquilibre”	❌	✅ maxSkew
”Répartir sur zones ET nœuds”	⚠️ Complexe	✅ Multiple constraints

Glissez pour voir

Exemple basique

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web
      containers:
      - name: web-container
        image: my-web-image

Paramètres clés

Paramètre	Description
maxSkew	Écart maximum toléré entre domaines (1 = équilibré)
topologyKey	Label définissant les domaines (kubernetes.io/hostname, topology.kubernetes.io/zone)
whenUnsatisfiable	DoNotSchedule (strict) ou ScheduleAnyway (best-effort)
labelSelector	Sélectionne les Pods concernés par le spread

Glissez pour voir

Répartition multi-niveaux (zones + nœuds)

spec:
  topologySpreadConstraints:
  # D'abord répartir entre zones
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: web
  # Puis répartir entre nœuds dans chaque zone
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: web

Recommandation haute disponibilité

Pour répartir proprement des replicas entre nœuds ou zones, topologySpreadConstraints est souvent plus adapté qu’une anti-affinity stricte. Il permet de contrôler le maxSkew et de combiner plusieurs niveaux de topologie.

6. Taints et Tolerations : protéger et réserver des nœuds

Les taints et tolerations fonctionnent à l’inverse de l’affinité :

• Un taint sur un nœud repousse les Pods par défaut
• Une toleration sur un Pod lui permet d’ignorer ce taint

Une toleration n'attire pas un Pod

C’est un point fondamental souvent mal compris. Une toleration n’est pas une règle de sélection. Elle autorise seulement le Pod à être programmé sur un nœud tainté ; elle ne le dirige pas vers ce nœud. Pour cibler réellement un nœud tainté, combinez toleration + nodeSelector ou nodeAffinity.

Ajouter un taint à un nœud

kubectl taint nodes <node-name> <key>=<value>:<effect>

Effets disponibles

Effet	Comportement
NoSchedule	Bloque les nouveaux Pods sans toleration
PreferNoSchedule	Évite les nouveaux Pods sans toleration (best-effort)
NoExecute	Bloque + expulse les Pods existants sans toleration

Glissez pour voir

Exemple : réserver des nœuds GPU

# Tainter le nœud GPU
kubectl taint nodes node-gpu accelerator=nvidia-gpu:NoSchedule

Tous les Pods standards seront bloqués sur ce nœud.

Ajouter une toleration à un Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-gpu
spec:
  containers:
  - name: my-container
    image: my-image
  tolerations:
  - key: "accelerator"
    operator: "Equal"
    value: "nvidia-gpu"
    effect: "NoSchedule"
  # Pour CIBLER le nœud, ajoutez aussi un selector
  nodeSelector:
    accelerator: nvidia-gpu

Toleration + nodeSelector

La toleration permet au Pod d’être accepté sur le nœud tainté. Le nodeSelector (ou nodeAffinity) dirige le Pod vers ce nœud. Sans le selector, le Pod pourrait aller n’importe où.

Opérateurs de toleration

Opérateur	Description
Equal	La clé et la valeur doivent correspondre
Exists	La clé doit exister (valeur ignorée)

Glissez pour voir

tolerationSeconds : tolérer temporairement NoExecute

Avec NoExecute, vous pouvez permettre à un Pod de rester temporairement sur un nœud devenu tainté :

tolerations:
- key: "node.kubernetes.io/not-ready"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 300

Le Pod restera 5 minutes sur un nœud devenu not-ready avant d’être évincé. Utile pour tolérer des perturbations réseau temporaires.

Taints courants du système

Taint	Description
node.kubernetes.io/not-ready	Nœud pas prêt
node.kubernetes.io/unreachable	Nœud injoignable
node.kubernetes.io/disk-pressure	Pression disque
node.kubernetes.io/memory-pressure	Pression mémoire
node.kubernetes.io/unschedulable	Nœud en cordon

Glissez pour voir

Taints du control-plane

Dans de nombreux clusters, les nœuds de control-plane portent un taint NoSchedule pour éviter d’y placer des workloads classiques. C’est une pratique courante, pas une règle universelle.

Supprimer un taint

kubectl taint nodes <node-name> <key>:<effect>-
# Exemple :
kubectl taint nodes node-gpu accelerator:NoSchedule-

7. Stratégies combinées : exemples pratiques

Exemple 1 : Nœuds GPU dédiés

Objectif : réserver des nœuds GPU aux workloads ML/AI.

1. Labelliser et tainter les nœuds GPU

   kubectl label nodes node-gpu-1 node-gpu-2 accelerator=nvidia-gpu
   kubectl taint nodes node-gpu-1 node-gpu-2 accelerator=nvidia-gpu:NoSchedule

2. Créer le Pod ML avec toleration + nodeAffinity

   apiVersion: v1
   kind: Pod
   metadata:
     name: ml-training
   spec:
     containers:
     - name: training
       image: tensorflow/tensorflow:latest-gpu
     tolerations:
     - key: "accelerator"
       operator: "Equal"
       value: "nvidia-gpu"
       effect: "NoSchedule"
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: accelerator
               operator: In
               values:
               - nvidia-gpu

Exemple 2 : Haute disponibilité multi-zones

Objectif : répartir 6 replicas équitablement entre 3 zones.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-ha
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web-ha
  template:
    metadata:
      labels:
        app: web-ha
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web-ha
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: web-ha
      containers:
      - name: web
        image: nginx:alpine

Résultat : 2 replicas par zone, répartis sur différents nœuds dans chaque zone.

Exemple 3 : Nœuds infrastructure réservés

Objectif : réserver des nœuds pour les DaemonSets et composants d’infrastructure.

# Tainter les nœuds infra
kubectl taint nodes infra-1 infra-2 dedicated=infrastructure:NoSchedule
kubectl label nodes infra-1 infra-2 node-role=infrastructure

# DaemonSet monitoring avec toleration
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: prometheus-node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "infrastructure"
        effect: "NoSchedule"
      # Ce DaemonSet tourne sur TOUS les nœuds, y compris infra
      containers:
      - name: exporter
        image: prom/node-exporter

8. Comment choisir le bon mécanisme ?

Objectif	Solution recommandée
Cibler un type de nœud (GPU, SSD)	nodeSelector ou nodeAffinity
Réserver un nœud à certains workloads	taints + tolerations (+ affinity pour cibler)
Rapprocher des Pods liés	podAffinity
Éloigner quelques Pods sensibles	podAntiAffinity
Répartir des replicas entre nœuds/zones	topologySpreadConstraints
Tolérer temporairement un nœud instable	tolerationSeconds

Glissez pour voir

Règle de décision

• Besoin de cibler un nœud → nodeSelector / nodeAffinity
• Besoin de protéger/réserver un nœud → taints + tolerations
• Besoin de répartir des replicas → topologySpreadConstraints
• Besoin de relations entre Pods → podAffinity / podAntiAffinity

9. Débugger les Pods en Pending

Un Pod reste Pending quand le scheduler ne trouve pas de nœud satisfaisant toutes les contraintes.

Commandes de diagnostic

# Voir pourquoi un Pod est Pending
kubectl describe pod <pod-name>

# Voir les events récents (très utile)
kubectl get events --sort-by=.lastTimestamp

# Voir les labels de tous les nœuds
kubectl get nodes --show-labels

# Voir les taints d'un nœud
kubectl describe node <node-name> | grep -A5 Taints

Causes courantes

Symptôme dans events	Cause probable	Solution
FailedScheduling: 0/X nodes available	Aucun nœud ne satisfait les contraintes	Vérifier labels/taints/affinity
node(s) didn't match Pod's node affinity/selector	Label manquant sur les nœuds	kubectl label nodes
node(s) had taint that pod didn't tolerate	Toleration manquante	Ajouter toleration au Pod
node(s) didn't match pod topology spread constraints	Contraintes de spread trop strictes	Réduire maxSkew ou ajouter des nœuds
Insufficient cpu/memory	Ressources insuffisantes	Ajuster requests ou ajouter des nœuds

Glissez pour voir

Exemple de diagnostic complet

# 1. Identifier le problème
kubectl describe pod my-pending-pod | grep -A10 Events

# 2. Vérifier les nœuds disponibles
kubectl get nodes -o wide

# 3. Vérifier les labels
kubectl get nodes --show-labels | grep -E "accelerator|zone"

# 4. Vérifier les taints
for node in $(kubectl get nodes -o name); do
  echo "=== $node ==="
  kubectl describe $node | grep -A3 Taints
done

À retenir

Mécanisme	Rôle	Côté
nodeSelector	Filtre simple par label	Pod → Nœud
nodeAffinity	Filtre avancé (préférence/contrainte)	Pod → Nœud
podAffinity	Rapproche des Pods	Pod → Pod
podAntiAffinity	Éloigne des Pods	Pod → Pod
topologySpreadConstraints	Répartit les replicas	Pod → Topologie
taints	Repousse les Pods non autorisés	Nœud
tolerations	Autorise un Pod sur nœud tainté	Pod

Glissez pour voir

Points essentiels :

1. topologySpreadConstraints est le mécanisme moderne pour la répartition — ne l’oubliez pas
2. Une toleration n’attire pas un Pod — elle l’autorise seulement
3. Pour cibler un nœud tainté : toleration + nodeSelector/nodeAffinity
4. L’inter-pod affinity peut ralentir le scheduling dans les grands clusters
5. Utilisez labels standardisés (kubernetes.io/hostname, topology.kubernetes.io/zone)

Prochaines étapes

Volumes Persistez les données de vos applications

Autoscaling Dimensionnement automatique des workloads

Network Policies Sécurisez le trafic réseau entre Pods

Debug applications Diagnostiquez les problèmes de vos Pods

×

📖 Voir la documentation →