PrepBro
← Назад к вопросам

В чем разница между Deployments и DaemonSets?

2.3 Middle🔥 241 комментариев
#Kubernetes

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Разница между Deployments и DaemonSets в Kubernetes

Deployments и DaemonSets — это два фундаментальных объекта управления рабочими нагрузками в Kubernetes, предназначенные для разных сценариев развертывания. Оба являются контроллерами, которые поддерживают желаемое состояние подов (Pods), но их логика управления, стратегии и области применения существенно различаются.

Основная философия и назначение

Deployment: Управление реплицируемыми приложениями

Deployment — это абстракция высокого уровня, предназначенная для управления набором идентичных подов (реплик). Его основная цель — обеспечить декларативное обновление и масштабирование приложений, работающих в кластере. Он идеально подходит для статусных (stateless) приложений, таких как веб-серверы, API-сервисы или микросервисы, где каждая реплика функционально идентична и не привязана к конкретному узлу (Node).

Ключевые характеристики:

  • Управляет желаемым количеством реплик (replicas: N).
  • Обеспечивает стратегии обновления (RollingUpdate, Recreate) с возможностью отката (rollback).
  • Поды планируются на любые доступные узлы, соответствующие селекторам и ограничениям.
  • Основной инструмент для CI/CD-пайплайнов, так как позволяет плавно обновлять версии приложения.

Пример манифеста Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-frontend
spec:
  replicas: 3 # Запустить 3 идентичных пода
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

DaemonSet: Обеспечение работы системного демона на каждом узле

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

Ключевые характеристики:

  • Размещает по одному поду на каждом узле, соответствующем селектору узлов (nodeSelector).
  • Не имеет поля replicas. Количество подов равно количеству подходящих узлов.
  • Поды обычно имеют привилегированный доступ к хосту (hostPath, сетевое пространство хоста).
  • Используется для сетевых плагинов (Calico, Flannel), агентов мониторинга (Prometheus Node Exporter), лог-агентов (Fluentd, Filebeat) и агентов хранения.

Пример манифеста DaemonSet:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      # Этот под будет запущен на каждом узле
      containers:
      - name: fluentd
        image: fluent/fluentd:latest
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule

Сравнительная таблица ключевых различий

КритерийDeploymentDaemonSet
Основная цельЗапуск и управление реплицируемым приложениемЗапуск системного демона на каждом (или выбранном) узле
Связь с узламиНет привязки. Планировщик (Scheduler) размещает поды на любых узлах.Жесткая привязка: по одному поду на узел.
МасштабированиеРучное или автоматическое (HPA) через изменение replicas.Автоматическое при добавлении/удалении узлов. Зависит от количества узлов.
Сценарии использованияВеб-приложения, API, микросервисы (stateless).Сетевые плагины, мониторинг, сбор логов, кэширование на уровне узла.
ОбновлениеПоддерживает стратегии RollingUpdate и Recreate.Поддерживает RollingUpdate (OnDelete или RollingUpdate).
Доступ к хостуОбычно не требуется.Часто требуется (hostPath, hostNetwork).

Практические примеры выбора

  • Вы выбираете Deployment, если:
    1.  Вам нужно запустить 5 копий веб-сервера для балансировки нагрузки.
    2.  Вы хотите обновить версию приложения с минимальным временем простоя, используя плавное развертывание.
    3.  Вам необходимо масштабировать приложение вручную или на основе метрик CPU.
  • Вы выбираете DaemonSet, если:
    1.  Вам необходимо собирать логи со всех контейнеров на всех узлах кластера в единую систему (например, Elasticsearch).
    2.  Вы разворачиваете SDN-плагин, который должен настраивать сетевые политики на каждой машине.
    3.  Вам нужен агент мониторинга (например, для сбора метрик узла) на каждом сервере.

Важные технические нюансы

  1. Tolerations и Node Selectors: DaemonSets часто используют tolerations (например, для node-role.kubernetes.io/master:NoSchedule), чтобы их поды могли работать на master-узлах. Они также могут использовать nodeSelector для запуска только на узлах с определенными метками (например, для GPU).

  2. Обновление DaemonSet: Стратегия RollingUpdate для DaemonSet обновляет поды на каждом узле по одному. Стратегия OnDelete требует ручного удаления пода для его обновления на конкретном узле.

  3. Совместное использование: В реальной архитектуре оба объекта часто используются вместе. Например, DaemonSet запускает Fluentd на каждом узле для сбора логов, а Deployment запускает 3 реплики приложения Kibana для визуализации этих логов.

Итог: Выбор между Deployment и DaemonSet определяется не типом приложения, а топологией его развертывания. Deployment отвечает на вопрос "Сколько копий приложения мне нужно?", а DaemonSet — на вопрос "На каких конкретных машинах должна работать эта системная служба?". Понимание этой разницы является краеугольным камнем для проектирования отказоустойчивых и эффективных кластеров Kubernetes.

В чем разница между Deployments и DaemonSets? | PrepBro