Какие есть правила, которые могут запретить или ограничить запуск подов на определённых нодах в Kubernetes?

Kubernetes предоставляет мощный набор механизмов для тонкого контроля размещения подов. Вот основные из них:

1. Taints и Tolerations: Запрещают запуск подов на нодах, если у пода нет соответствующего "допуска" (toleration). Это механизм отталкивания.

   • Taint (метка-ограничение) на ноде: kubectl taint nodes node1 app=monitoring:NoSchedule
   • Toleration в спецификации пода: позволяет поду быть запланированным на node1.

     
     tolerations:

   • key: "app" operator: "Equal" value: "monitoring" effect: "NoSchedule"

   • Эффекты: NoSchedule (запрет), PreferNoSchedule (мягкий запрет), NoExecute (выселение существующих подов).

2. Node Affinity / Anti-Affinity: Гибкие правила притягивания (affinity) или отталкивания (anti-affinity) подов к нодам на основе их меток.

   affinity:
     nodeAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
         nodeSelectorTerms:
         - matchExpressions:
           - key: "accelerator"
             operator: In
             values:
             - "gpu"

3. Pod Affinity / Anti-Affinity: Правила размещения подов относительно других подов. Например, можно разнести инстансы одного приложения по разным нодам (anti-affinity) для отказоустойчивости.

4. Node Selector: Простейшая форма привязки, выбирающая ноды по их меткам. Устаревший, но простой способ.

   nodeSelector:
     disktype: ssd

5. Resource Requests/Limits: Поды запрашивают CPU и память. Если на ноде недостаточно свободных ресурсов для удовлетворения запросов пода, он не будет на ней запланирован.

6. Inter-pod Affinity/Anti-affinity: Более продвинутая версия Pod Affinity, позволяющая учитывать топологию (например, разносить по разным зонам доступности).

Практический пример: Мы используем taints для выделенных нод с GPU (gpu=true:NoSchedule) и tolerations в DaemonSet для мониторинга, чтобы он запускался везде, включая мастер-ноды.