Настройка Kubernetes DaemonSets для системных агентов

Представьте: вы добавили новую ноду в кластер, настроили autoscaling, но Node Exporter на ней не запустился. Метрики с этой ноды отсутствуют, запросы к Prometheus — с дырами в данных. Причина — DaemonSet без tolerations не запускается на нодах с taint control-plane. Потеря видимости увеличивает MTTR на 30-50% и приводит к слепым зонам мониторинга.

DaemonSet гарантирует запуск ровно одного пода на каждой ноде кластера. Мы используем этот ресурс для деплоя агентов мониторинга, log collectors, CNI-плагинов и runtime security — всего, что должно работать на каждом хосте без исключений. Без DaemonSet вы рискуете потерять видимость на новой ноде или при сбое. Снижение MTTR на 40-60% и экономия операционных расходов — результат правильной конфигурации.

Почему DaemonSet — единственный правильный выбор для системных агентов?

Любой агент, который должен собирать данные с каждой ноды, логично запускать через DaemonSet. Попытка использовать ReplicaSet или Deployment приводит к дырам в покрытии. Например, при автоматическом масштабировании или замене ноды новый под может не запуститься, если контроллер не синхронизирован с lifecycle ноды. DaemonSet лучше Deployment в плане покрытия: 100% нод против вероятностного распределения, что критически важно для мониторинга.

Node Exporter (Prometheus) — классический DaemonSet. Собирает метрики CPU, памяти, диска, сети с каждой ноды. Один под на ноду, hostNetwork: true для доступа к сетевым интерфейсам хоста, hostPID: true для статистики процессов. Fluent Bit для сбора логов читает /var/log/containers/*.log через hostPath volume. Без DaemonSet логи с новой ноды просто не попадут в центральное хранилище. Falco — runtime security агент, детектирует неожиданный execve, изменение /etc/passwd, подозрительные network connection. Если нода без Falco — слепое пятно.

Как гарантировать запуск агента на каждой ноде?

Ключевые параметры манифеста:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9100"
    spec:
      tolerations:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
          effect: NoSchedule
        - key: node.kubernetes.io/not-ready
          operator: Exists
          effect: NoSchedule
      hostNetwork: true
      hostPID: true
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.7.0
          args:
            - '--path.rootfs=/host'
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            runAsUser: 65534
          volumeMounts:
            - name: host-root
              mountPath: /host
              readOnly: true
              mountPropagation: HostToContainer
      volumes:
        - name: host-root
          hostPath:
            path: /
      priorityClassName: system-node-critical

Критичные моменты:

• tolerations — без них DaemonSet не запустится на control-plane (taint NoSchedule) и на проблемных нодах (NotReady). Для агентов мониторинга нужен именно такой список.
• priorityClassName: system-node-critical — агент не будет вытеснен обычными подами при перегрузке.
• mountPropagation: HostToContainer — log collector увидит новые container log файлы, созданные после старта пода.

Когда использовать OnDelete вместо RollingUpdate?

Для кластера из 200 нод RollingUpdate может занять часы, если health check медленный. В таких случаях используйте maxUnavailable: 10% для ускорения.

Как ограничить DaemonSet только на определённые ноды?

Не всегда агент нужен на всех нодах. Например, GPU-метрики только на нодах с ускорителями:

nodeSelector: accelerator: nvidia-tesla-k80 

Или через nodeAffinity для сложной логики: регион, тип инстанса, label от автоматического provisioner.

Настройка DaemonSet: пошаговая инструкция

1. Определите, какие ноды должны запускать агент: все или только с определёнными label.
2. Создайте манифест DaemonSet: укажите tolerations для control-plane и not-ready нод, а также priorityClassName.
3. Настройте updateStrategy: RollingUpdate для обычных агентов, OnDelete для критичных.
4. Добавьте ресурсы: requests и limits для CPU и памяти, исходя из тестовой нагрузки.
5. Протестируйте на staging кластере: убедитесь, что поды запускаются на каждой целевой ноде.
6. Разверните в production с помощью GitOps (ArgoCD или Flux).

Типовые ресурсы для агентов:

Что входит в настройку DaemonSet под ключ

Мы предоставляем:

• Аудит текущего состояния кластера и выявление агентов, которые запущены некорректно (без tolerations, с низким приоритетом).
• Разработку манифестов DaemonSet под ваш стек: Node Exporter, Fluent Bit, Falco, CNI-плагины, custom eBPF-агенты.
• Конфигурацию updateStrategy и priorityClass с учётом SLA ваших сервисов.
• Интеграцию с существующим monitoring stack (Prometheus, Thanos, Grafana).
• Документацию и runbook для оперативной замены агента без потери данных.
• Обучение команды: как обновлять DaemonSet, как диагностировать проблемы.

Почему стоит доверить настройку профессионалам?

Мы — команда DevOps-инженеров с 10+ годами опыта в продакшене сотен кластеров (AWS EKS, GCP GKE, Yandex Cloud, bare-metal). За нашими плечами более 100 проектов по миграции, оптимизации и поддержке Kubernetes. DaemonSet для нас — базовая, но критичная деталь, которую мы настраиваем с учётом вашей инфраструктуры, budget и timeline. Свяжитесь с нами для предварительной оценки вашего проекта — получите консультацию по оптимизации DaemonSet.

Сроки

Деплой стандартного агента (Node Exporter, Fluent Bit) с корректными tolerations и ресурсами: несколько часов. Настройка нескольких агентов с разными nodeSelector, приоритетами и интеграцией: 1 день. Закажите настройку — мы предложим оптимальное решение под ваш кластер.

Дополнительные ресурсы

• DaemonSet — официальная документация Kubernetes.
• Node Exporter — руководство по установке.