StatefulSet
Тема дорожной карты · Kubernetes
StatefulSet — контроллер рабочих нагрузок Kubernetes, предназначенный для stateful-приложений, требующих стабильных сетевых идентичностей, упорядоченного управления Pod'ами и постоянного хранилища, — в отличие от Deployment, который рассматривает все реплики как взаимозаменяемые. Каждый Pod в StatefulSet получает предсказуемое стабильное имя хоста в форме <statefulset-name>-<ordinal> (например, postgres-0, postgres-1), разрешаемое через headless Service (clusterIP: None) с DNS-записями вида postgres-0.postgres.default.svc.cluster.local. StatefulSet провизирует хранилище на каждую реплику через volumeClaimTemplates, создавая отдельные PersistentVolumeClaim, обеспеченные StorageClass и CSI-драйвером, гарантируя сохранность данных при удалении Pod'а без повторной привязки к тому другой реплики. Создание и удаление Pod'ов следует строгому порядку — Pod N не запускается, пока Pod N-1 не перешёл в состояние Running и Ready, а удаление происходит в обратном порядке, — что критично для распределённых систем консенсуса — etcd, Kafka или Cassandra, — предполагающих порядок инициализации лидер/последователь. kubectl apply управляет обновлениями StatefulSet через spec.updateStrategy.rollingUpdate.partition, обеспечивая частичные canary-выкатки, при которых обновляются только Pod'ы с порядковым номером >= значению partition.
Как это работает
StatefulSet — один из workload-примитивов Kubernetes. Определяет желаемое состояние набора pods — число реплик, pod template, стратегия обновления — а контроллер непрерывно сводит реальное состояние к желаемому. При падении pod или ноды контроллер планирует замену. При обновлении pod template контроллер оркестрирует rolling update с health-проверками между батчами.
Когда применять
Выбирайте StatefulSet по характеристикам нагрузки: Deployment для stateless-сервисов (HTTP API, воркеры), StatefulSet для stateful с stable network identity (БД, очереди), DaemonSet для one-pod-per-node инфраструктуры (log-коллекторы, CNI), Job для batch-задач, CronJob для запланированных batch. Смешивание типов без нужды создаёт операционную сложность; выбирайте простейший подходящий примитив.
Типичные ошибки
Workload-ловушки: слишком низкие resource requests (pods scheduled, но выселяются под нагрузкой) или слишком высокие (кластер выглядит полным при малом реальном использовании); отсутствие liveness/readiness-проб (load balancer шлёт трафик на полу-стартанутые pods); использование Deployment для stateful-нагрузок, которым нужна StatefulSet-упорядоченность. Всегда измеряйте реальное использование ресурсов до sizing.