Налаштування 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 — посібник зі встановлення.