Чем Deployment отличается от DaemonSet и когда стоит выбрать DaemonSet?

Короткий ответ

Deployment поддерживает заданное число реплик, размещаемых планировщиком по любым подходящим узлам, а DaemonSet гарантирует ровно один экземпляр Pod на каждом (или на выбранном подмножестве) узле кластера — число реплик определяется числом узлов, а не задаётся вручную.

Как это работает подробнее

DaemonSet автоматически добавляет Pod при появлении нового узла и удаляет при выводе узла из кластера, минуя обычный процесс планирования по ресурсам в привычном смысле — по умолчанию он игнорирует часть ограничений, чтобы гарантированно разместиться на каждом узле (с учётом taints/tolerations).

Пример кода

manifest.yamlКопировать

apiVersion: apps/v1
kind: DaemonSet
metadata: { name: node-exporter }
spec:
  selector: { matchLabels: { app: node-exporter } }
  template:
    metadata: { labels: { app: node-exporter } }
    spec:
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.7.0

Что использовать на практике

• Практика. DaemonSet используют для инфраструктурных агентов, которые должны работать на каждом узле: сборщики логов (Fluentd/Fluent Bit), экспортеры метрик (node-exporter), сетевые плагины (CNI), агенты безопасности. Обычное приложение с бизнес-логикой почти никогда не разворачивают через DaemonSet.

Подводные камни

• Риски. использовать DaemonSet для масштабирования обычного веб-приложения вместо Deployment — это привязывает число реплик к числу узлов и не даёт независимо управлять масштабированием; забывать, что DaemonSet по умолчанию размещается в том числе на управляющих (control-plane) узлах, если явно не настроены исключающие toleration/affinity.