Как будут называться поды в репликасете и в стейтфулсете

Общие принципы именования подов в Kubernetes

В Kubernetes имена подов генерируются автоматически на основе шаблонов, специфичных для каждого типа контроллера. Репликасет (ReplicaSet) и стейтфулсет (StatefulSet) имеют фундаментально разные подходы к именованию подов, что напрямую связано с их архитектурными различиями.

Именование подов в Репликасете (ReplicaSet)

В Репликасете имена подов формируются по шаблону:
<имя-репликасета>-<случайный-уникальный-суффикс>

Ключевые особенности:

• Декларативное управление: Репликасет обеспечивает наличие заданного количества идентичных реплик подов.
• Взаимозаменяемость: Все поды в наборе абсолютно равнозначны, не имеют индивидуальной идентичности и могут быть заменены в любой момент.
• Случайный суффикс: Суффикс генерируется автоматически (обычно это 5 случайных алфавитно-цифровых символов) и гарантирует уникальность имени в пределах пространства имен.
• Отсутствие порядка: Порядок создания, удаления или обновления подов не имеет значения.

Пример манифеста и результата:

Допустим, у нас есть ReplicaSet с именем webapp-rs.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: webapp-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx:alpine

После применения этого манифеста будут созданы поды со следующими именами:

webapp-rs-abc12
webapp-rs-def34
webapp-rs-ghi56

Проверить это можно командой:

kubectl get pods -l app=webapp

Именование подов в Стейтфулсете (StatefulSet)

В Стейтфулсете имена подов формируются по детерминированному шаблону:
<имя-стейтфулсета>-<порядковый-номер>

Ключевые особенности:

• Уникальная идентичность: Каждый под имеет устойчивый, предсказуемый идентификатор, который сохраняется на протяжении всего жизненного цикла.
• Порядковый номер: Нумерация начинается с 0 и идет последовательно (-0, -1, -2 и т.д.).
• Упорядоченность: Создание, масштабирование (как вверх, так и вниз) и обновление подов происходят в строгом порядке — от подов с меньшим номером к подам с большим номером. Удаление происходит в обратном порядке.
• Связь с устойчивым хранилищем: Имя пода напрямую связано с его устойчивым томом (PersistentVolume). Том для пода app-db-1 будет иметь Claim (PersistentVolumeClaim) с именем data-app-db-1.
• Стабильность сетевой идентичности: Под сохраняет свое DNS-имя даже после перезапуска: <pod-name>.<service-name>.<namespace>.svc.cluster.local.

Пример манифеста и результата:

Допустим, у нас есть StatefulSet с именем app-db.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: app-db
spec:
  serviceName: "app-db-service"
  replicas: 3
  selector:
    matchLabels:
      app: database
  template:
    metadata:
      labels:
        app: database
    spec:
      containers:
      - name: db
        image: postgres:13
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

После применения этого манифеста будут созданы поды со следующими именами:

app-db-0
app-db-1
app-db-2

Для каждого пода автоматически создастся PersistentVolumeClaim:

data-app-db-0
data-app-db-1
data-app-db-2

Поды будут доступны по стабильным DNS-именам внутри кластера:

app-db-0.app-db-service.default.svc.cluster.local
app-db-1.app-db-service.default.svc.cluster.local
app-db-2.app-db-service.default.svc.cluster.local

Сравнительная таблица

Практическое значение для DevOps-инженера

Понимание этих различий критически важно при проектировании приложений:

1. Выбор контроллера: Для бессервисных (stateless) приложений используйте ReplicaSet (чаще через Deployment). Для сервисных (stateful) приложений с требованием к устойчивому хранилищу, уникальной идентичности и предсказуемому сетевому взаимодействию — StatefulSet.
2. Отладка и мониторинг: В StatefulSet вы всегда знаете, с каким конкретным экземпляров (например, мастер-реплика -0 или реплика -1) работаете.
3. Работа с хранилищем: В StatefulSet каждый под "привязан" к своему тому, что предотвращает потерю данных при пересоздании пода.
4. Обновления: StatefulSet поддерживает различные стратегии обновления (RollingUpdate, OnDelete), которые учитывают упорядоченность, что важно для кластерных приложений, где, например, сначала должен обновиться мастер-узел.

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