Ограничение запуска Pod на конкретный узел с помощью nodeSelector

Ключевые термины в одну строку

• PodSpec: поле манифеста Pod/Deployment, где задаётся nodeSelector.
• nodeSelector: простое соответствие меток узла; если метки узла совпадают с nodeSelector, Pod может быть запланирован на этот узел.

Предварительные требования

1. Kubernetes-кластер с как минимум одним worker-узлом.
   Если вы ещё не создали кластер, используйте официальные гайды или провайдера облака.

Что мы сделаем

1. Проверим, есть ли Taints на узлах.
2. Создадим Deployment без nodeSelector и посмотрим, на каких узлах размещаются Pod.
3. Присвоим метку master‑узлу и создадим Deployment с nodeSelector, ограничив расписание Pod только master‑узлом.

Настройка nodeSelector — пошагово

Сначала получим список узлов в кластере:

kubectl get nodes # Получить список узлов в кластере

Проверим наличие taints на конкретных узлах (пример):

kubectl describe nodes node01 | grep Taint # Описание node01: поиск Taint

kubectl describe nodes master | grep Taint # Описание master: поиск Taint

В примере выше видно, что taints отсутствуют, значит Pod могут быть запланированы на любом узле, включая master.

Создадим Deployment без nodeSelector

Создайте файл с описанием Deployment, например:

vim my-deployment-without-node-selector.yaml # Создать файл описания Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: frontend
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - image: httpd:2.4-alpine
        name: frontend

Создадим Deployment и посмотрим Pod:

kubectl get pods # Список Pod в кластере

kubectl create -f my-deployment-without-node-selector.yaml # Создать Deployment

kubectl get pods # Проверить запущенные Pod

Если увеличить число реплик и применить изменения, новые Pod могут оказаться на master‑узле, поскольку taints отсутствуют:

kubectl apply -f my-deployment-without-node-selector.yaml # Применить изменения в Deployment

kubectl get pods -o wide # Подробная информация о Pod (включая узел)

Видно, что Pod разворачиваются и на master‑узле, потому что узлы не содержат taints.

Добавим метку на master‑узел

Чтобы явно ограничить выполнение Pod только master‑узлом, присвоим ему метку:

kubectl label nodes master on-master=true # Присвоить метку master‑узлу

Проверим описание узла:

kubectl describe node master # Показать детали узла master (включая метки)

Теперь на master есть метка on-master=true.

Создадим Deployment с nodeSelector

Создайте файл Deployment с полем nodeSelector, чтобы Pod запускались только на узлах с меткой on-master=true:

vim my-deployment-with-node-selector.yaml # Создать файл описания Deployment с nodeSelector

apiVersion: apps/v1
kind: Deployment
metadata:
  name: streamer-v4-deployment
  labels:
    app: streamer-v4
spec:
  replicas: 2
  selector:
    matchLabels:
      app: streamer-v4
  template:
    metadata:
      labels:
        app: streamer-v4
    spec:
      containers:
      - name: streamer-v4
        image: nginx
        ports:
        - containerPort: 8880
      nodeSelector:
        on-master: "true"

Применим Deployment и проверим, где запущены Pod:

kubectl create -f my-deployment-with-node-selector.yaml # Создать Deployment с nodeSelector

kubectl get pods -o wide | grep streamer-v4-deployment # Посмотреть узлы, на которых запущены Pod

В выводе видно, что Pod запланированы только на узле master.

Если увеличить число реплик (например, replicas: 50) и применить манифест, все Pod будут стремиться разместиться только на master‑узле; если ресурсов master недостаточно, часть Pod останется в состоянии Pending.

vim my-deployment-with-node-selector.yaml # Изменить количество реплик
kubectl apply -f my-deployment-with-node-selector.yaml # Применить изменения

Важно: если на целевом узле недостаточно ресурсов, контроллер не будет автоматически перемещать Pod на другие узлы. nodeSelector вынуждает соответствие меток, а не масштабирование по ресурсам.

Когда nodeSelector подходит, а когда нет

• Подходит: нужно строго привязать Pod к узлам с определёнными аппаратными/локальными условиями (GPU, локальный диск, специфические сервисы).
• Не подходит: когда требуется гибкая политика — используйте node affinity (более гибкая), taints/tolerations (обратная логика) или централизацию планирования.

Альтернативы и быстрые подсказки

• nodeAffinity: поддерживает операторы (In, NotIn, Exists) и предпочтительные правила (preferredDuringSchedulingIgnoredDuringExecution).
• taints/tolerations: отброс Pod с узла, если они не содержат соответствующих tolerations.
• PodTopologySpread и PodDisruptionBudget: для распределения и отказоустойчивости.

Мини‑методология для введения nodeSelector в production

1. Определите точные требования: почему нужен отдельный узел (ресурсы, сеть, безопасность).
2. Пометьте узлы семантическими метками (on-master=true, gpu=true, ssd=true).
3. Тестируйте на dev‑кластере: примените nodeSelector, увеличьте replicas и следите за Pending/Unschedulable.
4. Добавьте мониторинг ресурсов и алерты на Pending Pod.
5. Документируйте метки и политики для команды.

Роль‑основанный чеклист перед применением

• Администратор кластера:
  • Проверил наличие taints на узлах.
  • Создал и задокументировал метки узлов.
  • Убедился в наличии ресурсов на целевых узлах.
• Разработчик/DevOps:
  • Обновил Deployment с nodeSelector.
  • Тестировал поведение при росте реплик.
  • Добавил стратегию обработки Pending Pod (HPA, масштабирование узлов).

Модель принятия решения (диаграмма)

flowchart TD
  A[Нужно ли жёстко привязывать Pod к узлу?] -->|Да| B[nodeSelector или nodeAffinity]
  A -->|Нет| C[Не использовать nodeSelector]
  B --> D{Нужны гибкие правила?}
  D -->|Да| E[nodeAffinity]
  D -->|Нет| F[nodeSelector]
  C --> G[Taints/Tolerations или балансировка]

Критерии приёмки

• Pod с nodeSelector запускаются только на узле с соответствующей меткой.
• При недостатке ресурсов на целевом узле Pod помечаются как Pending и генерируют оповещение.
• Документация: список меток узлов и их назначение доступен команде.

Заключение

В статье показано, как с помощью меток узлов и поля nodeSelector в PodSpec ограничить размещение Pod на конкретном узле (в примере — master). nodeSelector прост в использовании, но жёстко ограничивает расписание: при недостатке ресурсов Pod останутся в Pending. Для гибких политик рассмотрите nodeAffinity и taints/tolerations.

Важно: всегда документируйте метки узлов и проверяйте ресурсы целевых узлов перед массовым развёртыванием.