Оркестрация жизненного цикла подов зависит от правильного выбора контроллера (Workload API). Ошибка на этапе проектирования может привести к нарушению консистентности данных, неэффективной утилизации ресурсов нод или деградации stateful-приложений.
⚪️ Deployment: оркестрация Stateless-нагрузок
Этот контроллер спроектирован для приложений без сохранения состояния, где любой под является эфемерным и взаимозаменяемым.
Поды не имеют постоянного сетевого или дискового состояния. Имена генерируются динамически на основе хэша шаблона и случайной строки.
При обновлении старые поды уничтожаются, а новые создаются с нуля. Порядок деплоя реплик не гарантируется.
Использование PersistentVolume ограничено. Как правило, все реплики делят один том в режиме ReadWriteMany (например, NFS), либо работают исключительно с ephemeral-хранилищами.
Использование: REST API, микросервисы, фронтенд, stateless-воркеры очередей.
⚪️ StatefulSet: управление Stateful-нагрузками
Для приложений, требующих идентичности, стабильного сетевого имени и персистентного хранилища для каждой отдельной реплики.
Каждый под получает предсказуемый индекс (от 0 до N-1), который сохраняется при пересоздании (db-0, db-1).
Требует обязательного объявления Headless Service. Это позволяет формировать уникальные DNS для каждого пода, что критично для сборки кластерных топологий.
Каждому индексу пода соответствует свой PersistentVolumeClaim (через volumeClaimTemplates). При пересоздании или переносе пода на другую ноду, к нему монтируется его родной том. PVC не удаляются автоматически ни при масштабировании вниз, ни при удалении StatefulSet — это защищает данные от случайной потери. Это поведение можно переопределить полем .spec.persistentVolumeClaimRetentionPolicy с параметрами whenScaled и whenDeleted (Retain/Delete) — полезно, чтобы не копить orphaned-тома и не платить за неиспользуемое хранилище после scale down.
Для развертывания по умолчанию используется политика OrderedReady. Для оптимизации времени деплоя доступна политика Parallel.
Использование: распределенные СУБД, брокеры сообщений, координаторы (etcd, ZooKeeper).
⚪️ DaemonSet: гарантированное покрытие нод
Гарантирует, что экземпляр пода будет запущен на всех (или на строго определенных через nodeSelector / affinity) узлах кластера.
Количество реплик не задается вручную, а динамически масштабируется вместе с размером кластера. При вводе новой ноды под разворачивается на ней автоматически.
Размещение подов DaemonSet делегируется штатному kube-scheduler — через автоматическое добавление NodeAffinity и tolerations к системным taints, а не рассчитывается напрямую контроллером DaemonSet.
Поддерживает RollingUpdate. Параметр maxUnavailable управляет доступностью агентов с самого начала (по умолчанию 1).
Использование: агенты мониторинга и метрик, сборщики логов, системные компоненты сети и проксирования (kube-proxy, CNI-плагины вроде Cilium или Calico).
🎯 Чек-лист для архитектурного выбора
⚪️Deployment: нужна горизонтальная масштабируемость, поды идентичны, состояние хранится во внешних хранилищах (S3, внешняя БД)
⚪️StatefulSet: нужна строгая идентичность подов, кворумные алгоритмы (Raft/Paxos), фиксация сетевых имен и индивидуальные диски для каждой реплики
⚪️DaemonSet: нужна сквозная инфраструктурная обвязка хостов (логи, метрики, безопасность, сеть), которая должна жить на самой ноде независимо от бизнес-логики
@DevOpsKaz 😛