Приложению нужны разные постоянные сетевые имена для каждой реплики после пересоздания. Какой механизм оркестратора это обеспечивает?
Для этого используют StatefulSet в связке с headless Service. StatefulSet закрепляет за каждой репликой постоянный порядковый идентификатор и имя, например app-0 и app-1, а headless Service предоставляет DNS-имена, разрешающиеся в адреса конкретных подов. При пересоздании пода его имя и логическая идентичность сохраняются, хотя IP-адрес может измениться.
Обычные реплики в Deployment взаимозаменяемы: их имена и IP-адреса не предназначены для привязки к конкретному экземпляру. Такой подход хорошо подходит для stateless-приложений, где запрос можно направить на любую реплику.
Однако базы данных, брокеры сообщений и другие stateful-системы часто различают узлы. Им нужны стабильные имена для обнаружения участников кластера, восстановления роли узла или синхронизации данных. Для этого в Kubernetes появился StatefulSet с предсказуемой идентичностью реплик.
Если приложение обращается к репликам только через общий Service, оно получает балансировку между экземплярами, но не может адресовать конкретный узел. Использование IP-адресов напрямую ненадёжно: при пересоздании пода адрес обычно меняется.
Неверное решение может привести к потере маршрута к конкретному участнику кластера, ошибкам репликации или повторному добавлению узла как нового участника вместо восстановления прежнего. При этом стабильное имя не означает, что сам под всегда доступен или что его IP постоянен.
StatefulSet присваивает репликам порядковые номера: app-0, app-1, app-2. При пересоздании app-1 Kubernetes создаёт новый под с тем же логическим именем, поэтому приложение может использовать его как стабильную идентичность.
Для сетевого обнаружения обычно создают headless Service — Service без единого виртуального ClusterIP. DNS Kubernetes публикует отдельные записи для подов, например app-1.<имя-сервиса>.<пространство-имён>.svc, а клиент получает адрес конкретной реплики.
Стабильным является DNS-имя, а не IP-адрес. DNS-запись после пересоздания должна указывать на новый IP, поэтому клиентам и приложениям необходимо учитывать DNS-кэширование и повторное разрешение имени.
По умолчанию запись пода может публиковаться только при его готовности. Для систем, которым нужно обнаруживать под до прохождения readiness-проверки, применяют соответствующую настройку Service, но это увеличивает риск отправки трафика ещё неготовому экземпляру.
StatefulSet не заменяет репликацию и отказоустойчивость самого приложения. Он сохраняет идентичность и управляет жизненным циклом реплик, но не гарантирует корректность данных, доступность хранилища или успешное восстановление приложения после отказа.
Кластер брокера сообщений состоит из трёх узлов. После обновления один под пересоздаётся и получает новый IP. Если узлы используют случайные имена Deployment, брокер может воспринять новый экземпляр как неизвестный узел, что усложнит восстановление кластера.
Вариант с Deployment и обычным Service прост, но даёт только общий адрес и не сохраняет идентичность узлов. Ручное закрепление IP-адресов ненадёжно и плохо совместимо с динамическим планированием Kubernetes.
Выбран StatefulSet с headless Service. Каждый узел получает предсказуемое имя, а DNS автоматически указывает на актуальный IP. Это решает задачу обнаружения, но дополнительно потребовало настроить корректное удаление узлов, readiness-проверки и восстановление данных средствами самого брокера.
Нет. StatefulSet задаёт идентичность подов, но для стандартного DNS-обнаружения реплик нужен связанный headless Service. Без него не появляется привычная DNS-схема адресации отдельных подов через имя сервиса.
Нет. Имя и порядковый номер — это логическая идентичность. Сохранность данных зависит от постоянного тома, политики его привязки и корректной процедуры восстановления. Если StatefulSet использует только эфемерное хранилище, новый под может получить прежнее имя, но потерять локальные данные.
Нет. Под может быть остановлен, не готов или недоступен из-за сетевой проблемы. Кроме того, DNS-кэши способны временно хранить старый IP. Клиент должен корректно обрабатывать ошибки соединения, повторно разрешать имя и не воспринимать наличие DNS-записи как гарантию работоспособности реплики.