Placement des pods : taints, tolerations, nodeSelector, affinité

Comment on contrôle où un pod atterrit sur le cluster. Né de #114 (segmentation en node groups core / observability), ce guide explique les mécanismes et le pourquoi de nos choix, en particulier la toleration operator: Exists des DaemonSets.

L'idée en une phrase

Par défaut, le scheduler Kubernetes place un pod sur n'importe quel nœud qui a la place. Pour un cluster segmenté (trafic d'un côté, observabilité de l'autre), ça ne suffit pas : on a besoin de repousser, autoriser et forcer des placements. Trois leviers, à ne surtout pas confondre.

flowchart LR
    POD["Pod à placer"] --> Q{Le nœud a-t-il<br/>un taint ?}
    Q -->|non| OK1["Placé si la place<br/>+ le nodeSelector collent"]
    Q -->|oui| T{Le pod<br/>tolère-t-il<br/>ce taint ?}
    T -->|non| REJ["REJETÉ de ce nœud"]
    T -->|oui| OK2["Autorisé sur ce nœud<br/>(puis nodeSelector décide)"]

1. Les trois leviers (et leur rôle exact)

Levier	Posé sur	Verbe	Effet
taint	le nœud	repousse	aucun pod ne vient, sauf ceux qui le tolèrent
toleration	le pod	autorise	le pod a le droit d'aller sur un nœud taché (ne l'y attire pas)
nodeSelector	le pod	force	le pod doit aller sur un nœud qui porte ce label

Le piège mental classique : une toleration n'attire pas un pod, elle lève juste un barrage. Un pod qui tolère le taint observability peut aller sur le nœud obs, mais il peut tout aussi bien rester sur un autre nœud sans taint. Pour le forcer sur le nœud obs, il faut en plus un nodeSelector. Taint + toleration + nodeSelector forment le trio complet d'un placement dédié.

Pourquoi le nœud est taché et pas seulement étiqueté

Un label seul (sans taint) dirait « ce nœud est l'obs » mais n'empêcherait personne d'autre de s'y installer. Le taint est ce qui en fait une chasse gardée : sans lui, le scheduler bourrerait le nœud obs avec n'importe quoi dès que le nœud core est plein, et on reperdrait l'isolation qu'on a payée (#114).

2. Anatomie d'un taint

# Posé sur un nœud (chez nous : par le managed node group EKS, via Terraform)
kubectl taint nodes <node> workload=observability:NoSchedule
#                          └── key ──┘ └── value ──┘ └── effect ──┘

Trois effects, du plus doux au plus dur :

Effect	Sur un pod sans toleration
PreferNoSchedule	le scheduler évite ce nœud si possible (préférence molle)
NoSchedule	le pod ne sera pas schedulé sur ce nœud (mais ceux déjà là restent)
NoExecute	le pod est refusé ET les pods déjà présents sont évincés

Notre choix #114 : NoSchedule. Le cluster est greenfield à chaque aws-start (infra éphémère détruite le soir) : il n'y a jamais de pod « déjà là à évincer » au moment où les nœuds montent. NoExecute serait inutilement violent ; PreferNoSchedule trop laxiste (on veut une vraie chasse gardée, pas une préférence). NoSchedule est le point d'équilibre.

3. Anatomie d'une toleration : Equal vs Exists

Une toleration matche un taint. C'est le champ operator qui change toute la logique de matching.

operator: Equal (match exact)

tolerations:
  - key: workload
    operator: Equal        # défaut si omis
    value: observability
    effect: NoSchedule

Tolère uniquement le taint workload=observability:NoSchedule. Il faut que key, value et effect correspondent. C'est ce qu'on met sur les workloads épinglés à l'obs (prometheus, grafana, alertmanager, loki, kube-state-metrics, prometheus-operator), en binôme avec leur nodeSelector.

operator: Exists (match sur l'existence)

Exists ne regarde pas la value, seulement la présence d'un key :

Forme	Tolère...
operator: Exists + key: workload	tout taint dont le key = workload, quelle que soit la value
operator: Exists + key: workload + effect: NoSchedule	idem, mais limité à l'effect NoSchedule
operator: Exists SANS key	TOUS les taints : n'importe quel key, n'importe quelle value, n'importe quel effect

C'est cette dernière forme, le joker absolu, qu'on utilise pour les DaemonSets :

prometheus-node-exporter:
  tolerations:
    - operator: Exists     # <-- aucun key, aucune value : "je tolère n'importe quel taint"

« operator: Exists, mais quel key/value doit exister ? »

Aucun, et c'est tout l'intérêt. Sans key, le Exists ne teste l'existence de rien en particulier : il dit littéralement « peu importe ce qui est taché sur le nœud, j'y vais ». Si on précisait un key, alors il faudrait que ce key existe sur le taint du nœud pour que la toleration matche. Le joker nu, lui, matche tout.

4. nodeSelector vs nodeAffinity

Deux façons de forcer un pod vers une catégorie de nœud :

• nodeSelector (ce qu'on utilise) : le plus simple, une égalité de labels stricte.

  nodeSelector:
    workload: observability
  

  Hard : si aucun nœud ne porte ce label, le pod reste Pending. C'est voulu pour nous (un pod obs DOIT être sur le nœud obs, sinon on a un problème à voir, pas à masquer).
• nodeAffinity : plus riche (opérateurs In/NotIn/Exists, règles required dures ou preferred souples avec un poids). Utile pour « de préférence sur tel type, mais sinon ailleurs ». Overkill ici : on veut du dur et du simple. Noté pour l'entretien (un node group app dédié avec une préférence souple serait un cas nodeAffinity).

5. Le cas DaemonSet : toleration OUI, nodeSelector NON

Un DaemonSet déploie un pod par nœud (agents de nœud : métriques, logs, CNI, CSI). Sa logique de placement est l'inverse d'un Deployment :

flowchart TB
    subgraph CORE["nœud core (sans taint)"]
        NE1["node-exporter"]
        AL1["alloy"]
    end
    subgraph OBS["nœud observability (taint NoSchedule)"]
        NE2["node-exporter"]
        AL2["alloy"]
    end
    DS["DaemonSet<br/>toleration: operator Exists<br/>(pas de nodeSelector)"]
    DS --> NE1
    DS --> NE2

• Pas de nodeSelector : un DaemonSet doit tourner partout. Lui mettre un nodeSelector: workload=observability le confinerait au nœud obs et on perdrait les métriques / logs du nœud core. C'est le piège n°1.
• Une toleration quand même : sans elle, le pod du DaemonSet serait repoussé du nœud obs taché, et on perdrait la télémétrie du nœud obs cette fois. Donc il faut tolérer le taint.
• Pourquoi le joker Exists et pas la toleration précise : les deux marchent pour le taint d'aujourd'hui. Mais le joker est future-proof :

Toleration sur le DaemonSet	node-exporter tourne sur...	Si on ajoute un 3e node group taché autrement
Equal workload=observability (précise)	core + obs	PAS sur le nouveau nœud → trou de métriques
Exists (joker, notre choix)	tous les nœuds	sur le nouveau nœud aussi, sans rien changer

La règle à retenir

Pour un agent de nœud (node-exporter, alloy, et plus largement tout DaemonSet d'infra), on tolère tout (operator: Exists nu) et on ne met jamais de nodeSelector. C'est le pattern idiomatique : un agent de nœud doit voir chaque nœud, présent ou futur, quelle que soit sa raison d'être tachée.

6. Nos choix concrets pour #114

Workload	Type K8s	nodeSelector	toleration	Pourquoi
prometheus	StatefulSet	workload=observability	Equal workload=obs	gros conso mémoire, à isoler du trafic
grafana	Deployment	workload=observability	Equal workload=obs	idem
alertmanager	StatefulSet	workload=observability	Equal workload=obs	partie monitoring
kube-state-metrics	Deployment	workload=observability	Equal workload=obs	partie monitoring
prometheus-operator	Deployment	workload=observability	Equal workload=obs	partie monitoring
loki	StatefulSet	workload=observability	Equal workload=obs	logs, jetable
node-exporter	DaemonSet	aucun	Exists (joker)	métriques par nœud → partout
alloy	DaemonSet	aucun	Exists (joker)	logs par nœud → partout
fastapi, envoy, argocd, cert-manager, ESO, external-dns	divers	aucun	aucune	le taint obs les repousse tout seul → ils restent sur core

Le dernier point est subtil : les workloads core ne portent rien. Ils n'ont pas besoin de tolérer le nœud obs (ils n'y vont pas) ni d'un nodeSelector pour core (le taint obs suffit à les y maintenir, par élimination). Moins de YAML, et c'est correct.

Le gain Spot, chiffré (mesuré le 2026-06-26, eu-west-3)

Le nœud obs est en Spot : c'est ce qui rend acceptable de le prendre plus gros (t3.large) pour absorber l'observabilité et Tempo à venir. Prix relevés via aws ec2 describe-spot-price-history sur les 3 types du node group :

Type	Spot (le moins cher)	On-demand (≈)	Économie
t3a.large	0,0284 $/h (eu-west-3c)	~0,085 $/h	-67 %
t3.large	0,0306 $/h (eu-west-3c)	~0,094 $/h	-67 %
m5.large	0,0323 $/h (eu-west-3b)	~0,112 $/h	-71 %

Deux lectures : (1) l'économie ~-70 % annoncée est confirmée par la mesure ; (2) l'écart entre tous les prix est serré (0,028 → 0,041 $/h), signe d'un marché Spot stable sur ces types en eu-west-3 → peu d'interruptions attendues. C'est précisément l'intérêt de diversifier les types : AWS pioche le moins cher et le plus disponible (ici t3a.large en 3c) sans qu'on ait à choisir à la main.

7. Comment vérifier en live

# Les labels des nœuds
kubectl get nodes -L workload

# Les taints (sur quel nœud)
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

# Où chaque pod a atterri
kubectl get pods -A -o wide

# Pourquoi un pod est Pending (lire les events : taint non toléré ? selector ?)
kubectl describe pod <pod> | sed -n '/Events/,$p'

# Vérifier qu'un DaemonSet couvre bien tous les nœuds
kubectl get pods -A -o wide | grep -E "node-exporter|alloy"   # 1 par nœud

8. Grille entretien

• « Différence entre un taint et un nodeSelector ? » → le taint repousse (sur le nœud), le nodeSelector force (sur le pod) ; ils se complètent avec la toleration qui autorise.
• « operator: Exists sans key, ça tolère quoi ? » → tout taint, c'est le joker des DaemonSets.
• « Pourquoi un DaemonSet n'a pas de nodeSelector ? » → il doit tourner sur chaque nœud ; un selector le confinerait et on perdrait la télémétrie ailleurs.
• « NoSchedule vs NoExecute ? » → NoExecute évince en plus les pods déjà présents.
• « Un pod obs est Pending, par où tu regardes ? » → describe les events : taint non toléré, label de nœud absent, ou capacité insuffisante (cf capacité).

Pour aller plus loin

• La stratégie de capacité qui a motivé la segmentation : guide capacité et ADR 026.
• Pourquoi la gouvernance des ressources rend la capacité nécessaire : ADR 025.
• Autoscaling des nœuds à la demande (Karpenter) : Sprint 6.