Можно ли сделать, чтобы Pod всегда попадал на определенную Node?

Обеспечение размещения Pod на конкретной Node в Kubernetes

Да, можно и даже несколькими способами, однако важно понимать философию Kubernetes, который изначально проектировался для декларативного управления и отказоустойчивости, предполагая, что Pod'ы могут быть пересозданы в любом месте кластера. Жёсткая привязка к конкретной ноде противоречит этим принципам, но для ряда сценариев (лицензирование, аппаратные особенности, низкая задержка) она необходима.

Основные механизмы привязки

1. NodeSelector: Простой выбор по меткам

Самый базовый способ. Вы назначаете ноде уникальную метку, а в спецификации Pod указываете эту метку в nodeSelector.

• Шаг 1: Помечаем целевую ноду.

  kubectl label nodes <node-name> topology.kubernetes.io/zone=special-rack
  

• Шаг 2: В манифесте Pod явно указываем селектор.

  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx-pod
  spec:
    containers:
    - name: nginx
      image: nginx
    nodeSelector:
      topology.kubernetes.io/zone: special-rack # Pod будет размещён только на ноде с этой меткой
  

    **Ограничение:** Если подходящих нод несколько, выбор будет произвольным. Не гарантирует размещение на *конкретной* ноде, только на *одной из группы*.

2. NodeAffinity: Гибкие правила сродства

Более мощный и рекомендуемый механизм. Позволяет задавать гибкие (soft) или жёсткие (hard) правила.

• requiredDuringSchedulingIgnoredDuringExecution (Жёсткое правило): Обязательное условие для планировщика (scheduler). Если ноды нет, Pod останется в состоянии Pending.

  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx-affinity
  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname # Используем встроенную метку с именем ноды
              operator: In
              values:
              - node-01 # Конкретное имя ноды
    containers:
    - name: nginx
      image: nginx
  

    **Это и есть ответ на ваш вопрос:** Используя метку `kubernetes.io/hostname` и оператор `In` с одним значением, вы жёстко привязываете Pod к конкретной ноде.

• preferredDuringSchedulingIgnoredDuringExecution (Гибкое правило): Предпочтение для планировщика. Он попытается выполнить правило, но если не выйдет — разместит Pod elsewhere.

3. nodeName: Прямое указание (Обход планировщика)

Самый жёсткий и низкоуровневый метод. Если поле nodeName указано в .spec, kube-scheduler игнорируется, и kubelet на указанной ноде пытается запустить Pod.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-direct
spec:
  nodeName: node-01 # Прямое указание имени ноды
  containers:
  - name: nginx
    image: nginx

Критически важные недостатки:

• Обходит планировщик: Проверки на достаточность ресурсов (CPU, memory), соблюдение taints/tolerations не выполняются.
• Нет гарантий запуска: Если нода недоступна, Pod останется в Pending навсегда, так как планировщик не будет искать альтернативу.
• Нарушает абстракцию: Жёстко завязано на инфраструктуру. Используйте только в особых случаях или для отладки.

4. Taints и Tolerations (Обратный подход)

Это не прямое указание "посади сюда", а механизм отталкивания Pod'ов от нод. Вы можете "загрязнить" (taint) все ноды, кроме одной, а ваш Pod снабдить "толерантностью" (toleration) к этому загрязнению. Это сложнее, но часто используется в паре с NodeAffinity для гарантированного запуска на выделенных нодах (например, для GPU).

Практические рекомендации и предупреждения

• Используйте NodeAffinity с меткой kubernetes.io/hostname для гарантированного размещения. Это наиболее корректный способ в рамках Kubernetes API.
• Избегайте nodeName для продакшен-работы. Это антипаттерн, лишающий кластер гибкости.
• Помните о последствиях:

    *   **Потеря отказоустойчивости:** Если нода упадёт, все привязанные к ней Pod'ы упадут и не будут пересозданы на других нодах (пока вы вручную не измените конфигурацию).
    *   **Сложность масштабирования:** Horizontal Pod Autoscaler (HPA) сможет создать новые реплики, но они все будут "стоять в очереди" (Pending) на одну ноду, если на ней не хватит ресурсов.
    *   **Нарушение балансировки:** Может привести к перегрузу одной ноды и простою других.

Вывод: Да, сделать жёсткую привязку Pod к конкретной Node можно и иногда нужно. Для этого следует использовать NodeAffinity с жёстким правилом (requiredDuringSchedulingIgnoredDuringExecution) и меткой kubernetes.io/hostname. Однако к такой практике стоит прибегать осознанно, взвешивая необходимость против потери гибкости и отказоустойчивости кластера. Часто более правильным решением является использование меток для группы нод (например, hardware: gpu) и привязки к этой группе, что даёт планировщику свободу выбора внутри неё.