← Back to blog

Kubernetes Scheduling: taints, tolerations, affinity

⚙️ Теория

🧠 Как scheduler принимает решение

Планирование включает два этапа:

  • filtering: на каких node pod вообще можно разместить;
  • scoring: какая из подходящих node предпочтительнее.

Taints/tolerations и affinity влияют именно на эти этапы.


Taints и Tolerations

Taint ставится на node и отталкивает pod.

Эффекты taint:

  • NoSchedule
  • PreferNoSchedule
  • NoExecute

Toleration в pod не "притягивает" pod к node, а только разрешает игнорировать соответствующий taint.


📌 Node Affinity / Anti-Affinity

requiredDuringSchedulingIgnoredDuringExecution:

  • жесткое правило, без него pod не запланируется.

preferredDuringSchedulingIgnoredDuringExecution:

  • мягкое предпочтение.

Pod affinity/anti-affinity управляет соразмещением pod относительно других pod (по labels/topology).


⚠️ Где ломается production

  • конфликтующие обязательные правила (pod становится Pending);
  • чрезмерный anti-affinity при небольшом числе node;
  • taint на node без соответствующих tolerations у критичных сервисов.

Что нужно уметь объяснить

Почему toleration не гарантирует размещение?

Потому что это только "пропуск" через taint-фильтр. Дальше действуют ресурсы, affinity, topology constraints и другие фильтры scheduler.

Когда использовать taint, а когда affinity?

  • taint: изоляция/защита node от нерелевантных workload;
  • affinity: выражение предпочтений и требований pod к topology/labels.

Главный риск anti-affinity?

Недопланирование при пиках нагрузки, если кластер не дает достаточной топологической емкости.


🧪 Практика

1. Пример taint/toleration

kubectl taint nodes node-a workload=ml:NoSchedule
tolerations:
  - key: "workload"
    operator: "Equal"
    value: "ml"
    effect: "NoSchedule"

2. Пример node affinity

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: node.kubernetes.io/instance-type
              operator: In
              values: ["c6i.2xlarge"]

3. Диагностика Pending pod

kubectl describe pod <pod>
kubectl get events --sort-by=.lastTimestamp
kubectl describe node <node>

🧾 Вывод

Стабильное планирование строится на комбинации taints/tolerations и affinity с учетом реальной емкости кластера. Слишком жесткие правила без capacity planning быстро создают Pending и деградацию.


📚 Ссылки


Проверка источников

Kubernetes Scheduling: taints, tolerations, affinity | Aleksandr Suprun