# DaemonSet > DaemonSet определяет Поды, предоставляющие локальные для узла возможности. Они могут быть критически важны для работы кластера, например, в роли вспомогательного сетевого инструмента или как часть дополнения. --- LLMS index: [llms.txt](/llms.txt) --- _DaemonSet_ гарантирует, что на всех (или некоторых) узлах запущена копия Пода. При добавлении узлов в кластер Поды автоматически добавляются на них. При удалении узлов из кластера эти Поды удаляются сборщиком мусора. Удаление DaemonSet приведёт к удалению всех созданных им Подов. Типичные случаи использования DaemonSet: - запуск демона кластерного хранилища на каждом узле - запуск демона сбора логов на каждом узле - запуск демона мониторинга узлов на каждом узле В простом случае для каждого типа демона используется один DaemonSet, охватывающий все узлы. В более сложных конфигурациях может использоваться несколько DaemonSet для одного типа демона, но с разными флагами и/или разными запросами памяти и CPU для различных типов оборудования. ## Написание спецификации DaemonSet ### Создание DaemonSet DaemonSet можно описать в YAML-файле. Например, файл `daemonset.yaml` ниже описывает DaemonSet, запускающий Docker-образ fluentd-elasticsearch:
controllers/daemonset.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # these tolerations are to have the daemonset runnable on control plane nodes
      # remove them if your control plane nodes should not run pods
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v5.0.1
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      # it may be desirable to set a high priority class to ensure that a DaemonSet Pod
      # preempts running Pods
      # priorityClassName: important
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
Создание DaemonSet на основе YAML-файла: ``` kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ``` ### Обязательные поля Как и для любой другой конфигурации Kubernetes, DaemonSet требует наличия полей `apiVersion`, `kind` и `metadata`. Общую информацию о работе с конфигурационными файлами см. в разделах [запуск stateless-приложений](/docs/tasks/run-application/run-stateless-application-deployment/) и [управление объектами с помощью kubectl](/ru/docs/concepts/overview/working-with-objects/object-management/). Имя объекта DaemonSet должно быть допустимым [DNS-именем поддомена](/ru/docs/concepts/overview/working-with-objects/names/#имена-поддоменов-dns). DaemonSet также требует наличия секции [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). ### Шаблон Пода Поле `.spec.template` является одним из обязательных полей в `.spec`. Поле `.spec.template` представляет собой [шаблон Пода](/ru/docs/concepts/workloads/pods/#pod-templates). Оно имеет точно такую же схему, как и Под, за исключением того, что является вложенным и не имеет полей `apiVersion` и `kind`. Помимо обязательных полей для Пода, шаблон Пода в DaemonSet должен указывать соответствующие метки (см. [селектор Подов](#селектор-подов)). Шаблон Пода в DaemonSet должен иметь [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy), равную `Always`, или не указывать её, что по умолчанию означает `Always`. ### Селектор Подов Поле `.spec.selector` является селектором Подов. Оно работает так же, как `.spec.selector` у [Job](/docs/concepts/workloads/controllers/job/). Необходимо указать селектор Подов, который соответствует меткам в `.spec.template`. Также, после создания DaemonSet, его `.spec.selector` не может быть изменён. Изменение селектора Подов может привести к непреднамеренному осиротению Подов, что может запутать пользователей. Поле `.spec.selector` представляет собой объект, состоящий из двух полей: * `matchLabels` — работает так же, как `.spec.selector` у [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/). * `matchExpressions` — позволяет создавать более сложные селекторы, указывая ключ, список значений и оператор, связывающий ключ и значения. Когда указаны оба поля, результат объединяется по логическому И (AND). Поле `.spec.selector` должно соответствовать `.spec.template.metadata.labels`. Конфигурация с несовпадающими значениями будет отклонена API. ### Запуск Подов на выбранных узлах Если указано поле `.spec.template.spec.nodeSelector`, контроллер DaemonSet будет создавать Поды на узлах, соответствующих этому [селектору узлов](/ru/docs/concepts/scheduling-eviction/assign-pod-node/). Аналогично, если указано поле `.spec.template.spec.affinity`, контроллер DaemonSet будет создавать Поды на узлах, соответствующих этим [правилам совместного существования (node affinity)](/ru/docs/concepts/scheduling-eviction/assign-pod-node/). Если ни одно из полей не указано, контроллер DaemonSet будет создавать Поды на всех узлах. ## Как планируются Поды демонов DaemonSet может использоваться для обеспечения того, чтобы все подходящие узлы запускали копию Пода. Контроллер DaemonSet создаёт Под для каждого подходящего узла и добавляет поле `spec.affinity.nodeAffinity` в Под для соответствия целевому хосту. После создания Пода обычно управление берёт на себя планировщик по умолчанию, который привязывает Под к целевому хосту, устанавливая поле `.spec.nodeName`. Если новый Под не помещается на узле, планировщик по умолчанию может вытеснить (evict) некоторые из существующих Подов на основе [приоритета](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) нового Пода.

Примечание:

Если важно, чтобы Под DaemonSet'а запускался на каждом узле, обычно желательно установить .spec.template.spec.priorityClassName для DaemonSet в PriorityClass с более высоким приоритетом, чтобы гарантировать это вытеснение.
Пользователь может указать другой планировщик для Подов DaemonSet'а, установив поле `.spec.template.spec.schedulerName` у DaemonSet. Исходная привязка к узлам, указанная в поле `.spec.template.spec.affinity.nodeAffinity` (если указана), учитывается контроллером DaemonSet при оценке подходящих узлов, но заменяется в созданном Поде на привязку к узлу, соответствующую имени подходящего узла. ```yaml nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchFields: - key: metadata.name operator: In values: - target-host-name ``` ### Ограничения (taints) и допуски (tolerations) Контроллер DaemonSet автоматически добавляет набор допусков (tolerations) к Подам DaemonSet'а:
Допуски для Подов DaemonSet
Ключ допуска Эффект Описание
node.kubernetes.io/not-ready NoExecute Поды DaemonSet могут планироваться на узлы, которые не готовы или не могут принимать поды. Любые поды DaemonSet, работающие на таких узлах, не будут вытеснены.
node.kubernetes.io/unreachable NoExecute Поды DaemonSet могут планироваться на узлы, недоступные для контроллера узлов. Любые поды DaemonSet, работающие на таких узлах, не будут вытеснены.
node.kubernetes.io/disk-pressure NoSchedule Поды DaemonSet могут планироваться на узлы с проблемами нехватки дискового пространства.
node.kubernetes.io/memory-pressure NoSchedule Поды DaemonSet могут планироваться на узлы с проблемами нехватки памяти.
node.kubernetes.io/pid-pressure NoSchedule Поды DaemonSet могут планироваться на узлы с проблемами нехватки идентификаторов процессов (PID).
node.kubernetes.io/unschedulable NoSchedule Поды DaemonSet могут планироваться на узлы, помеченные как непланируемые.
node.kubernetes.io/network-unavailable NoSchedule Добавляется только для Подов DaemonSet, запрашивающих сеть хоста, т.е. Подов с spec.hostNetwork: true. Такие Поды DaemonSet могут планироваться на узлы с недоступной сетью.
Вы также можете добавить собственные допуски (tolerations) к Подам DaemonSet'а, определив их в шаблоне Пода DaemonSet'a. Поскольку контроллер DaemonSet автоматически устанавливает допуск `node.kubernetes.io/unschedulable:NoSchedule`, Kubernetes может запускать Поды DaemonSet'а на узлах, помеченных как _непланируемые_. Если вы используете DaemonSet для предоставления важной функции уровня узла, такой как [сеть в кластере](/ru/docs/concepts/cluster-administration/networking/), будет полезным, если Kubernetes разместит Поды DaemonSet'а на узлах до того, как они будут готовы. Например, без этого специального допуска вы можете оказаться в тупиковой ситуации, когда узел не помечен как готовый, потому что сетевой плагин там не запущен, и в то же время сетевой плагин не запущен на этом узле, потому что узел ещё не готов. ## Взаимодействие с Подами демонов Некоторые возможные паттерны взаимодействия с Подами в DaemonSet'е: - **Push**: Поды в DaemonSet'е настроены на отправку обновлений в другой сервис, например, в базу данных статистики. У них нет клиентов. - **IP узла и известный порт**: Поды в DaemonSet могут использовать `hostPort`, чтобы быть доступными по IP-адресам узлов. Клиенты каким-либо образом знают список IP-адресов узлов и знают порт благодаря предварительному соглашению. - **DNS**: Создайте [headless-сервис](/docs/concepts/services-networking/service/#headless-services) с тем же селектором Подов, а затем обнаруживайте DaemonSet'ы, используя ресурс `endpoints` или получая несколько A-записей из DNS. - **Service**: Создайте сервис с тем же селектором Подов и используйте сервис для доступа к демону на случайном узле. Используйте [политику внутреннего трафика сервиса (Service Internal Traffic Policy)](/docs/concepts/services-networking/service-traffic-policy/) для ограничения Подами на том же узле. ## Обновление DaemonSet При изменении меток узлов DaemonSet оперативно добавит Поды на узлы, которые теперь соответствуют условиям, и удалит Поды с узлов, которые больше не соответствуют. Вы можете изменять Поды, созданные DaemonSet'ом. Однако Поды не позволяют обновлять все поля. Кроме того, контроллер DaemonSet будет использовать исходный шаблон при следующем создании узла (даже с тем же именем). Вы можете удалить DaemonSet. Если указать `--cascade=orphan` с `kubectl`, то Поды останутся на узлах. Если впоследствии создать новый DaemonSet с тем же селектором, новый DaemonSet примет существующие Поды. Если какие-либо Поды требуют замены, DaemonSet заменит их в соответствии со своей `updateStrategy`. Вы можете [выполнить плавное обновление (rolling update)](/docs/tasks/manage-daemon/update-daemon-set/) DaemonSet'а. ## Альтернативы DaemonSet ### Init-скрипты Безусловно, можно запускать процессы-демоны напрямую на узле (например, используя `init`, `upstartd` или `systemd`). Это вполне допустимо. Однако есть несколько преимуществ запуска таких процессов через DaemonSet: - Возможность мониторинга и управления логами демонов так же, как и приложений. - Один и тот же язык конфигурации и инструменты (например, шаблоны Подов, `kubectl`) для демонов и приложений. - Запуск демонов в контейнерах с ограничениями ресурсов повышает изоляцию между демонами и контейнерами приложений. Однако этого также можно достичь, запуская демоны в контейнере, но не в Поде. ### Обычные Поды (Bare Pods) Можно создавать Поды напрямую, указывая конкретный узел для запуска. Однако DaemonSet заменяет Поды, которые были удалены или завершены по любой причине, например, в случае сбоя узла или из-за последствий таких операций по обслуживанию узла, как обновление ядра. По этой причине следует использовать DaemonSet вместо создания отдельных Подов. ### Статические Поды Можно создавать Поды, записывая файл в определённый каталог, отслеживаемый Kubelet. Такие Поды называются [статическими Подами](/docs/tasks/configure-pod-container/static-pod/). В отличие от DaemonSet, статическими Подами нельзя управлять с помощью kubectl или других клиентов Kubernetes API. Статические Поды не зависят от apiserver, что делает их полезными в сценариях первичной загрузки кластера. Также статические Поды могут быть объявлены устаревшими в будущем. ### Deployment'ы DaemonSet'ы похожи на [Deployment'ы](/docs/concepts/workloads/controllers/deployment/) тем, что оба создают Поды, и эти Поды содержат процессы, которые не должны завершаться (например, веб-серверы, серверы хранения). Используйте Deployment для stateless-сервисов, таких как фронтенд-приложения, где важнее масштабировать вверх и вниз количества реплик и развёртывать обновления, чем контролировать то, на каком именно хосте запускается Под. Используйте DaemonSet, когда важно, чтобы копия Пода всегда работала на всех или определённых хостах, если DaemonSet предоставляет функциональность уровня узла, позволяющую другим Подам корректно работать на этом конкретном узле. Например, [сетевые плагины](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) часто включают компонент, работающий как DaemonSet. Компонент DaemonSet обеспечивает работу кластерной сети на узле, где он запущен. ## Что дальше * Узнайте больше о [Подах](/ru/docs/concepts/workloads/pods): * Узнайте о [статических Подах](/docs/tasks/configure-pod-container/static-pod/), которые полезны для запуска компонентов управляющего слоя (control plane) Kubernetes. * Узнайте, как использовать DaemonSet'ы: * [Выполнение плавного обновления (rolling update) DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/). * [Выполнение отката DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/) (например, если развёртывание прошло не так, как ожидалось). * Узнайте, [как Kubernetes назначает Поды на узлы](/ru/docs/concepts/scheduling-eviction/assign-pod-node/). * Узнайте о [плагинах устройств](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) и [дополнениях](/ru/docs/concepts/cluster-administration/addons/), которые часто работают как DaemonSet'ы. * `DaemonSet` является ресурсом верхнего уровня в Kubernetes REST API. Прочитайте определение объекта , чтобы понять API для DaemonSet'ов.