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

Механизмы контроля размещения Pods в Kubernetes

В Kubernetes существует несколько ключевых механизмов для ограничения или запрета запуска подов на определённых узлах (нодах). Эти механизмы обеспечивают гибкое управление распределением workloads в кластере.

1. Taints и Tolerations

Это основной механизм для запрета запуска подов на нодах. Taint (отметка) — это свойство узла, которое препятствует размещению на нем всех подов, кроме тех, у которых есть соответствующее Toleration (толерантность, допуск). Это похоже на "запрещающий знак" на узле.

• Taint добавляется на ноду: она указывает, что нода принимает только определенные поды.
• Pod должен иметь Toleration: чтобы быть запущенным на этой ноде, под должен явно допускать эту отметку.

Команда для добавления taint на ноду:

kubectl taint nodes node1 key=value:NoSchedule

Пример Pod с Toleration в манифесте:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"
  containers:
  - name: nginx
    image: nginx

Эффекты (effect) Taint могут быть разными:

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

2. Node Selectors

Это простейший механизм для ограничения запуска подов на нодах с определёнными метками (labels). Pod указывает, на каких нодах он хочет запускаться.

Пример использования в Pod манифесте:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  nodeSelector:
    disktype: ssd
    gpu: "true"
  containers:
  - name: nginx
    image: nginx

Pod будет запущен только на узлах, имеющих метки disktype=ssd и gpu=true.

3. Node Affinity и Anti-Affinity

Это более мощная и выразительная версия Node Selectors. Affinity определяет правила, по которым Pod стремится быть размещенным на определенных нодах. Anti-Affinity определяет правила, по которым Pod стремится избегать размещения на определенных нодах. Используется для сложных сценариев, таких как распределение инстансов приложения по разным зонам доступности или аппаратным пулам.

Существует два типа:

• requiredDuringSchedulingIgnoredDuringExecution: жесткое правило, которое должно быть выполнено для размещения Pod. Это "хард" требование.
• preferredDuringSchedulingIgnoredDuringExecution: мягкое правило, которое планировщик пытается выполнить, но не гарантирует. Это "софт" предпочтение.

Пример жесткого Anti-Affinity (Pod избегает нод с меткой zone=unsafe):

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: zone
            operator: NotIn
            values:
            - unsafe
  containers:
  - name: nginx
    image: nginx

4. Pod Affinity и Anti-Affinity

Этот механизм ограничивает размещение Pod не относительно свойств узлов, а относительно места размещения других Pod. Например, можно гарантировать, что Pods одного сервиса будут запущены на одном узле для уменьшения latency (Pod Affinity), или наоборот, распределены по разным узлам для повышения отказоустойчивости (Pod Anti-Affinity).

5. Inter-Pod Topology Constraints

Это расширение Pod Affinity/Anti-Affinity с использованием topologyKey. Позволяет задавать правила относительно топологии кластера (например, "не размещать два Pod из этого Deployment в одной зоне доступности", используя topologyKey: topology.kubernetes.io/zone).

Стратегия применения в реальных сценариях

В практике DevOps эти правила используются комплексно:

• Taints/Tolerations часто применяют для выделения специальных узлов (например, только для GPU workloads или только для инстансов с высокой памятью). Также это стандартный механизм для защиты мастер-узлов (control-plane nodes) от запуска пользовательских подов (на них обычно стоит taint node-role.kubernetes.io/master:NoSchedule).
• Node Selectors/Affinity используют для направления подов на узлы с определенными характеристиками (SSD, определенным поколением CPU, географическим расположением).
• Pod Anti-Affinity критически важен для обеспечения отказоустойчивости StatefulSets или Deployment, чтобы инстансы приложения не оказались все на одном узле, который может выйти из строя.

Таким образом, Kubernetes предоставляет богатый набор инструментов от простого запрета (Taints) до сложных интеллектуальных правил размещения (Affinity/Anti-Affinity), позволяя администраторам кластера и разработчикам точно контролировать распределение нагрузки и обеспечивать оптимальную работу приложений.