Как запустить pod на каждой worker-ноде

Развертывание Pod на каждой Worker-ноде в Kubernetes

Чтобы запустить Pod на каждой Worker-ноде в кластере Kubernetes, основной и наиболее распространенный подход — использование DaemonSet. DaemonSet — это контроллер Kubernetes, который обеспечивает запуск и поддержку копии Pod на всех (или определенных) узлах кластера. Это идеально подходит для системных сервисов, таких как сборщики логов (например, Fluentd), мониторинговые агенты (например, Prometheus Node Exporter) или сетевые плагины (например, Calico).

Создание и настройка DaemonSet

DaemonSet создается через манифест YAML, аналогичный Deployment, но с типом DaemonSet. Вот базовый пример для запуска простого контейнера на каждой ноде:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: example-daemonset
  namespace: default
spec:
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-container
        image: nginx:latest
        ports:
        - containerPort: 80

После применения манифеста (kubectl apply -f daemonset.yaml) Kubernetes автоматически запустит Pod на каждой существующей worker-ноде и будет поддерживать это состояние: при добавлении новых нод на них будет развернут Pod, а при удалении ноды Pod также будет удален.

Ключевые аспекты и расширенные сценарии

• Селектор нод: По умолчанию DaemonSet запускает Pod на всех нодах, включая control-plane ноды (если они не имеют taints). Чтобы ограничить развертывание только worker-нодами или подмножеством нод, используются механизмы nodeSelector, affinity/anti-affinity и tolerations.

    *   Например, чтобы запускать Pod только на нодах с определенной меткой (`disktype: ssd`):

```yaml
spec:
  template:
    spec:
      nodeSelector:
        disktype: ssd
```

    *   Чтобы игнорировать taint'ы на control-plane нодах и запускать Pod и там (например, для мониторинга), необходимо добавить соответствующий **toleration**:

```yaml
spec:
  template:
    spec:
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
```

• Обновления и стратегия rollout: DaemonSet поддерживает различные стратегии обновления (updateStrategy), аналогичные Deployment. Наиболее распространена RollingUpdate, которая позволяет поэтапно обновлять Pod'ы на нодах с контролем доступности.

  spec:
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxUnavailable: 1  # Максимум одна нода может быть недоступна во время обновления
  

• Альтернативные подходы:

    *   **Static Pods:** Для системы с прямым доступом к нодам можно использовать Static Pods, управляемые kubelet через манифесты в директории (например, `/etc/kubernetes/manifests/`). Этот метод менее гибкий и не управляется через Kubernetes API. Пример размещения манифеста на ноде:

```bash
sudo cat <<EOF > /etc/kubernetes/manifests/static-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-example
spec:
  containers:
  - name: nginx
    image: nginx
EOF
```

    *   **Deployment с Pod Anti-Affinity и узким количеством реплик:** Можно создать Deployment с количеством реплик, равным числу нод, и жесткими правилами `podAntiAffinity`, чтобы Pod'ы не размещались на одной ноде. Однако этот метод сложен в поддержке при изменении количества нод и не является стандартным решением.

```yaml
spec:
  replicas: 3  # Должно совпадать с количеством нод
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - example-app
            topologyKey: kubernetes.io/hostname
```

Рекомендация: Для запуска системных или инфраструктурных сервисов на каждой ноде всегда следует использовать DaemonSet как нативное, надежное и самовосстанавливающееся решение. Static Pods подходят для специфических случаев, когда компоненты должны работать до инициализации кластера (например, сам kubelet или сетевые плагины). Подход с Deployment считается антипаттерном для данной задачи.

Управление и мониторинг

После развертывания проверить статус DaemonSet и расположение Pod'ов можно командами:

# Просмотр DaemonSet
kubectl get daemonset

# Просмотр Pod, созданных DaemonSet, с указанием нод
kubectl get pods -l app=example-app -o wide

# Подробное описание DaemonSet
kubectl describe daemonset example-daemonset

В реальных сценариях DaemonSet часто используется в связке с ServiceAccount, RBAC разрешениями и ConfigMaps/Secrets для конфигурации. Это обеспечивает безопасное и гибкое развертывание служебных сервисов во всем кластере.

Стратегии развертывания Pod на каждой Worker-Node в Kubernetes

Для запуска Pod на каждой рабочей ноде (worker-node) в кластере Kubernetes существует несколько стандартных подходов, каждый из которых решает задачу с разной степенью гибкости и контроля. Вот основные методы, которые я использую в практике.

1. DaemonSet: Основной и стандартный способ

DaemonSet — это контроллер Kubernetes, который гарантирует, что копия Pod будет работать на всех (или на выбранных) узлах кластера. Это идеальный инструмент для системных демонов, таких как сборщики логов (Fluentd, Filebeat), мониторинг (Node Exporter) или сетевые плагины (Calico).

Пример манифеста DaemonSet для запуска мониторинга:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-monitoring-daemonset
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      # Ключевой момент: часто требуется привязка к хосту
      hostNetwork: true
      hostPID: true
      containers:
      - name: exporter
        image: prom/node-exporter:latest
        ports:
        - containerPort: 9100
          hostPort: 9100
        # Используем tolerations для работы на мастер-нодах, если нужно
      tolerations:
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      # Позволяет планировать на всех нодах
      nodeSelector:
        kubernetes.io/os: linux

Ключевые особенности DaemonSet:

• Автоматически создает Pod на каждой новой ноде при ее добавлении в кластер.
• Позволяет использовать nodeSelector и tolerations для фильтрации узлов (например, запускать только на нодах с определенными лейблами или включая мастер-ноды).
• Управляет жизненным циклом Pod: при удалении ноды из кластера Pod также удаляется.

2. Использование Node Affinity и Pod Anti-Affinity в комбинации с Deployment

Если DaemonSet не подходит по какой-то причине (например, нужно больше контроля над обновлениями, как в Deployment), можно сымитировать его поведение. Это более сложный, но гибкий подход.

Стратегия: Мы создаем Deployment с количеством реплик (replicas), равным или большим числа нод. Затем с помощью podAntiAffinity (requiredDuringSchedulingIgnoredDuringExecution) запрещаем двум Pod'ам планироваться на одну ноду. Добавляем nodeAffinity для привязки к конкретным нодам, если требуется.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: on-every-node-deployment
spec:
  replicas: 6 # Указываем число, >= количеству целевых нод
  selector:
    matchLabels:
      app: distributed-agent
  template:
    metadata:
      labels:
        app: distributed-agent
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - distributed-agent
            topologyKey: "kubernetes.io/hostname" # Ключевой параметр
        # Опционально: притягиваем Pod к нодам с определенным лейблом
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-type
                operator: In
                values:
                - worker

Важные нюансы этого метода:

• Количество реплик (replicas) нужно вручную поддерживать в актуальном состоянии при добавлении/удалении нод.
• Если Pod на какой-то ноде завершится с ошибкой, он может перезапуститься на другой ноде, нарушив распределение. Нужна внимательная настройка стратегии перезапуска (restartPolicy, PodDisruptionBudget).
• Подходит для приложений, где важна высокая доступность (HA) и равномерное распределение, но не строгое требование "ровно один Pod на ноду".

3. Ручное планирование через nodeName

Наименее рекомендуемый, но возможный в исключительных случаях метод — явное указание имени ноды в спецификации Pod (spec.nodeName). Это обходит планировщик Kubernetes.

apiVersion: v1
kind: Pod
metadata:
  name: static-pod-on-node-xyz
spec:
  nodeName: ip-10-0-1-101.ec2.internal # Конкретное имя ноды
  containers:
  - name: static-app
    image: nginx:alpine

Почему это плохая практика для нашей задачи:

• Требует создания отдельного манифеста для каждой ноды.
• Нарушает принципы декларативного управления Kubernetes.
• Полностью ручное управление жизненным циклом.
• Pod не сможет перепланироваться при падении ноды.

Рекомендации и итог

Для 99% случаев задачи "запустить pod на каждой ноде" правильным выбором будет DaemonSet. Он создан именно для этого, абстрагирует вас от конкретных имен нод и надежно управляет состоянием системы.

Шаги для реализации:

1. Определите, нужны ли вашему Pod привилегии (securityContext, hostNetwork, hostPID).
2. Определите, на всех ли нодах должен быть Pod (например, включая мастер-ноды). Если нет — настройте nodeSelector и/или tolerations.
3. Создайте манифест DaemonSet, примените его командой kubectl apply -f.
4. Проверьте развертывание: kubectl get daemonset -n <namespace> и kubectl get pods -n <namespace> -o wide — вы должны увидеть по одному Pod на каждой целевой ноде.

Использование же подхода с Anti-Affinity имеет смысл для кастомных сценариев, где DaemonSet не предоставляет нужной функциональности (например, при работе с StatefulSet).