Для какого приложения использовал бы StatefulSet

Когда использовать StatefulSet в Kubernetes

StatefulSet — это ресурс Kubernetes, предназначенный для управления stateful-приложениями, которым требуется устойчивая идентификация, стабильное сетевое имя и постоянное хранилище. В отличие от Deployment, который идеален для stateless-сервисов, StatefulSet обеспечивает предсказуемый порядок развёртывания, масштабирования и обновления подов, а также гарантирует уникальность и сохранность их данных.

Ключевые характеристики приложений для StatefulSet

Я бы выбрал StatefulSet для приложений, которые соответствуют следующим критериям:

• Устойчивая идентификация: Каждый под должен иметь стабильное, предсказуемое имя (например, app-0, app-1), которое сохраняется при перезапусках.
• Стабильное сетевое имя: Доступ к подам должен осуществляться по постоянным DNS-именам (шаблон: <pod-name>.<service-name>.<namespace>.svc.cluster.local).
• Упорядоченность операций: Развёртывание, масштабирование и обновление подов должны происходить в строгом порядке (по индексу: 0, 1, 2...).
• Привязка к постоянному хранилищу: Каждому поду требуется свой уникальный PersistentVolume (PV), который должен следовать за подом при его пересоздании на том же узле. Это реализуется через VolumeClaimTemplates.

Типичные примеры приложений для StatefulSet

1. Распределённые базы данных (кластеры):

    *   **MongoDB Replica Set**, **Cassandra**, **CockroachDB**, **Elasticsearch**, **MySQL с репликацией** (например, Group Replication).
    *   Каждому инстансу БД (под) нужен свой уникальный том с данными. Инициализация кластера часто требует последовательного запуска узлов (например, для выбора мастера). Поды должны находить друг друга по стабильным DNS-именам.

```yaml
# Пример фрагмента StatefulSet для условной БД
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql-cluster
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
  volumeClaimTemplates: # Ключевой элемент! Создаёт уникальный PVC для каждого пода
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi
```

2. Очереди сообщений:

    *   **Apache Kafka**, **RabbitMQ в кластере**, **NATS Streaming**.
    *   Каждый брокер очереди хранит свои сегменты данных или состояние и должен быть идентифицируем для других членов кластера.

1. Ключ-значение хранилища:

    *   **Redis Sentinel** или **Redis Cluster**, **etcd** (хотя для etcd часто используют отдельные операторы).
    *   Требуют устойчивых сетевых идентификаторов для формирования кворума и репликации данных.

1. Приложения с уникальными ролями в кластере:

    *   Системы, где есть выделенные мастер- и рабочие-узлы, и каждый узел выполняет свою часть работы, привязанную к своим данным (например, некоторые распределённые обработчики данных).

Контраст с Deployment: когда НЕ использовать StatefulSet

Для stateless-приложений (веб-серверы, REST API, stateless микросервисы) всегда выбирайте Deployment. Их характеристики противоположны:

• Поды взаимозаменяемы.
• Нет необходимости в стабильном имени или привязке к конкретному хранилищу.
• Любой под может обработать любой запрос.
• Используют общие тома (ReadWriteMany) или вообще не используют постоянное хранилище.

Практические аспекты работы с StatefulSet

• Headless Service: Для работы сетевой идентификации StatefulSet требует создания Headless Service (.spec.clusterIP: None). Этот сервис не выполняет балансировку нагрузки, а предоставляет DNS-записи для каждого пода.
• Управление хранилищем: volumeClaimTemplates создаёт отдельный PersistentVolumeClaim (PVC) для каждого пода. При удалении StatefulSet PVC по умолчанию сохраняются (в отличие от подов), что защищает данные. Удалять их нужно явно.
• Обновления: Стратегии обновения (updateStrategy) могут быть RollingUpdate (последовательное, с контролем готовности) или OnDelete (только при ручном ударовании пода). Это обеспечивает безопасность для stateful-нагрузок.

Итог: Я бы использовал StatefulSet для любого приложения, которое является узлом распределённого кластера, хранит уникальное состояние на диске и для которого критична устойчивая сетевая идентичность. Это фундаментальный выбор архитектуры, обеспечивающий надёжность и предсказуемость работы stateful-сервисов в Kubernetes. Для всего остального — Deployment или, в некоторых случаях, DaemonSet.