Что нужно сделать чтобы pod не приходил на конкретную node?

Управление размещением Pod на узлах Kubernetes

Чтобы предотвратить попадание Pod на конкретную Node в Kubernetes, существует несколько механизмов, которые можно разделить на два основных подхода: изоляция узла (node isolation) и прямое ограничение размещения (placement restriction).

Основные механизмы предотвращения размещения Pod

1. Использование Taints и Tolerations (Загрязнения и Допуски)

Это наиболее стандартный и рекомендуемый подход. Вы "загрязняете" ноду Taint, а Pod сможет быть размещен на ней только если имеет соответствующий Toleration.

Настройка Taint на узле:

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

Пример для ноды worker-node-1:

kubectl taint nodes worker-node-1 app=critical:NoSchedule

Что это делает:

• NoSchedule - новые Pod не будут планироваться на эту ноду
• PreferNoSchedule - система попытается избежать размещения на этой ноде
• NoExecute - существующие Pod, которые не переносят этот taint, будут выселены

2. NodeSelector и Node Affinity/Anti-Affinity

Хотя обычно эти механизмы используются для притягивания Pod к узлам, их можно настроить так, чтобы Pod избегал конкретной ноды.

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

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - node-to-avoid-1
            - node-to-avoid-2
  containers:
  - name: nginx
    image: nginx:latest

3. Пометка узла как недоступного (Cordon)

Временное решение для обслуживания узла:

# Пометить ноду как недоступную для планирования новых Pod
kubectl cordon <node-name>

# Вернуть ноду в рабочее состояние
kubectl uncordon <node-name>

Важно: Это не удалит существующие Pod с ноды, только предотвратит размещение новых.

Рекомендуемый подход в зависимости от сценария

Для постоянного исключения узла из общего пула:

# 1. Добавляем постоянный taint
kubectl taint nodes <node-name> dedicated=reserved:NoSchedule

# 2. Помечаем ноду (опционально, для ясности)
kubectl label nodes <node-name> role=reserved

Для временного обслуживания:

# 1. Помечаем ноду как недоступную
kubectl cordon <node-name>

# 2. Освобождаем ноду от существующих Pod (опционально)
kubectl drain <node-name> --ignore-daemonsets --delete-local-data

# 3. После обслуживания возвращаем в строй
kubectl uncordon <node-name>

Для выделенных узлов под специфичные workload:

# В конфигурации Deployment/Pod
spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "special-app"
    effect: "NoSchedule"
  nodeSelector:
    role: "special-nodes"

Практические рекомендации и нюансы

1. DaemonSets игнорируют taints с NoSchedule если у них есть соответствующие tolerations, что стоит учитывать.

2. Комбинированный подход часто наиболее эффективен:

   # Сначала помечаем ноду
   kubectl label nodes node-1 environment=staging
   
   # Затем добавляем taint для предотвращения production workload
   kubectl taint nodes node-1 environment=production:NoSchedule
   

3. Для системных компонентов (kube-proxy, CNI плагины) обычно настроены tolerations для всех taints, поэтому они продолжат работать на узле.

4. Мониторинг размещения после настройки:

   # Проверить taints ноды
   kubectl describe node <node-name> | grep Taints
   
   # Найти Pod на конкретной ноде
   kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<node-name>
   

Безопасность и контроль доступа

Для предотвращения случайного или злонамеренного размещения Pod на защищенных узлах можно использовать Admission Controllers и OPA/Gatekeeper, создавая политики вроде:

# Политика Gatekeeper: запрет размещения Pod на нодах с taint "security=high"
violation[{"msg": msg}] {
    input.review.object.spec.nodeName == "secure-node-1"
    not input.review.object.spec.tolerations[_].key == "security"
    msg := "Pod не может быть размещен на защищенной ноде без соответствующих tolerations"
}

Выбор конкретного механизма зависит от ваших требований: taints для постоянных ограничений, cordon для временных операций, anti-affinity для сложных сценариев распределения workload.