Есть ли реплики в DaemonSet

Вопрос: Есть ли реплики в DaemonSet?

Короткий ответ: Нет, у DaemonSet в Kubernetes нет прямого понятия "реплик" (replicas) в том же смысле, как у Deployment или ReplicaSet. Вместо этого DaemonSet гарантирует запуск ровно одного экземпляра Pod на каждом Node (узле), соответствующем определённым критериям селектора. Количество Pod'ов управляется не заданным числом реплик, а автоматически масштабируется в зависимости от количества подходящих узлов в кластере.

Как работает DaemonSet

Основная задача DaemonSet — развернуть и поддерживать Pod на всех (или определённых) узлах кластера. Это поведение фундаментально отличается от контроллеров, основанных на репликах:

• Deployment/ReplicaSet: Вы задаёте желаемое количество replicas: 5. Контроллер создаёт 5 идентичных Pod'ов, распределяя их по узлам без гарантии, что на каждом узле будет Pod. Если узел выходит из строя, Pod пересоздаётся на другом узле, сохраняя общее количество реплик.
• DaemonSet: Вы не задаёте количество реплик. Контроллер DaemonSet автоматически создаёт по одному Pod'у на каждом узле, который соответствует его nodeSelector или tolerations. Если в кластер добавляется новый узел с подходящими метками — DaemonSet немедленно создаёт на нём Pod. Если узел удаляется — Pod с ним удаляется. Количество Pod'ов равно количеству подходящих узлов.

Аналогия для понимания

Представьте себе, что Deployment — это команда копий-агентов, которых вы нанимаете в количестве 5 человек для работы в офисе (кластере). Сколько их окажется на каждом этаже (узле) — неважно, главное — общее число. DaemonSet — это обязательный охранник (например, агент безопасности или сборщик логов), который должен дежурить на каждом входе в здание (на каждом узле). Если в здании 10 входов (узлов) — будет 10 охранников. Количество "реплик" охранников напрямую зависит от архитектуры здания, а не от вашего произвольного решения.

Управление "масштабированием" DaemonSet

Хотя вы не управляете репликами напрямую, вы контролируете, на скольких узлах будет работать Pod DaemonSet, используя два ключевых механизма:

1. nodeSelector: Позволяет выбирать узлы по их меткам (labels).

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: fluentd-logging
   spec:
     selector:
       matchLabels:
         name: fluentd
     template:
       metadata:
         labels:
           name: fluentd
       spec:
         nodeSelector:
           disktype: ssd # Pod будет запущен только на узлах с меткой disktype=ssd
         containers:
         - name: fluentd
           image: fluent/fluentd:v1.7
   

2. tolerations и nodeAffinity: Позволяют Pod'ам DaemonSet планироваться на узлы с taints (пометками, обычно защищающими узлы). Это критично для запуска системных DaemonSet (например, kube-proxy) на мастер-узлах.

   spec:
     template:
       spec:
         tolerations:
         - key: node-role.kubernetes.io/control-plane
           operator: Exists
           effect: NoSchedule
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: node-role.kubernetes.io/control-plane
                   operator: Exists
   

Проверка количества Pod'ов DaemonSet

Так как количество Pod'ов зависит от узлов, для проверки состояния DaemonSet вы смотрите не на количество реплик, а на:

• Desired Number Scheduled: Сколько Pod'ов должно быть запущено (по одному на каждом подходящем узле).
• Current Number Scheduled: Сколько Pod'ов фактически запланировано на узлы.
• Number Available: Сколько Pod'ов работают и готовы.

Эти данные можно получить командой:

kubectl describe daemonset <daemonset-name>

Или:

kubectl get daemonset

Вывод будет выглядеть так:

NAME              DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
fluentd-logging   3         3         3       3            3           disktype=ssd    5d

Здесь DESIRED: 3 означает, что в кластере есть 3 узла, соответствующих селектору disktype=ssd.

Исключение: Можно ли имитировать "реплики" в DaemonSet?

Технически — нет, это противоречит его предназначению. Однако, если стоит задача запустить несколько идентичных Pod'ов на одном узле, для этого следует использовать другие контроллеры:

• Deployment с настройкой PodAntiAffinity (чтобы Pod'ы не собирались на одном узле) или, наоборот, PodAffinity.
• StatefulSet для stateful-приложений.
• Простой ReplicaSet с ручной настройкой планировщика.

Выводы и ключевые отличия

Таким образом, при проектировании инфраструктуры в Kubernetes выбор DaemonSet обоснован, когда требуется гарантированное присутствие сервиса на каждом вычислительном узле, а не произвольное количество реплик приложения в пуле. Это делает его незаменимым инструментом для развёртывания инфраструктурных компонентов кластера.