Tсли мы разворачиваем deployment, сохраняется ли для него какое-либо состояние

Разбор вопроса о состоянии в Kubernetes Deployment

Короткий ответ: Нет, сам объект Deployment в Kubernetes не хранит прикладное состояние приложения (application state), но хранит свое внутреннее состояние конфигурации и статуса, управляя при этом через PodTemplate абстрактными наборами подов (ReplicaSets), которые уже могут ссылаться на постоянные хранилища данных.

Давайте разберем эту концепцию детально, так как вопрос касается фундаментального понимания архитектуры Kubernetes.

1. Что НЕ хранит Deployment (Прикладное состояние)

Deployment — это контроллер, обеспечивающий декларативное обновление для подов и ReplicaSets. Его основная цель — управление желаемым состоянием (desired state) для вашего приложения: сколько реплик (replicas) должно работать, какой образ контейнера (image) использовать, какие переменные окружения задать.

Прикладные данные, такие как пользовательские сессии, записи в базах данных, файлы, загруженные пользователями, или кэш в памяти, НЕ хранятся внутри объекта Deployment. Если Pod, управляемый Deployment, будет пересоздан (что происходит при обновлении, откате или сбое), все данные в его файловой системе (если не используется том) будут утеряны.

Вот пример манифеста Deployment. В нем нет ссылок на постоянное хранилище, значит, состояние не сохраняется:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stateless-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-container
        image: nginx:latest
        env:
        - name: APP_ENV
          value: "production"
        # Все данные, которые контейнер запишет в свою ФС, будут потеряны при перезапуске пода.

2. Что Внутренне хранит Deployment (Состояние контроллера)

Сам объект Deployment в etcd кластера Kubernetes хранит свою конфигурацию и статус. Это можно увидеть с помощью kubectl describe:

• Желаемая спецификация (spec): replicas, selector, template, стратегия обновления (rollingUpdate).
• Текущий статус (status):

    *   `availableReplicas` - сколько подов готово.
    *   `readyReplicas`
    *   `updatedReplicas` - сколько подов обновлено до текущей версии.
    *   `revisionHistoryLimit` - сколько старых ReplicaSets хранить для возможного отката.

Это мета-состояние для оркестрации, а не данные вашего приложения.

3. Как Обеспечить Сохранение Прикладного Состояния с Deployment

Чтобы приложение, управляемое Deployment, сохраняло данные, необходимо явно добавить в PodTemplate объекты PersistentVolume (PV) и PersistentVolumeClaim (PVC). Тогда тома (volumes) будут подключены к файловой системе контейнера, и данные переживут перезапуск пода.

Пример Deployment с сохранением состояния:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: stateful-webapp
spec:
  replicas: 1 # Для stateful-нагрузок часто используют 1 реплику или StatefulSet
  selector:
    matchLabels:
      app: web-with-data
  template:
    metadata:
      labels:
        app: web-with-data
    spec:
      containers:
      - name: app
        image: myapp:latest
        volumeMounts:
        - name: app-storage
          mountPath: /var/www/data # Данные в этой папке будут сохранены.
      volumes:
      - name: app-storage
        persistentVolumeClaim:
          claimName: my-app-pvc # Ключевой элемент - ссылка на PVC
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

4. Deployment vs StatefulSet для Stateful-приложений

Хотя Deployment можно использовать с томами, для сложных stateful-приложений (базы данных, очереди сообщений) чаще выбирают StatefulSet, потому что он предоставляет:

• Стабильные сетевые идентификаторы (имена подов: pod-0, pod-1).
• Стабильные, уникальные тома хранилища для каждой реплики.
• Упорядоченный и предсказуемый деплой и обновление.

Выбор в DevOps-практике:

• Используйте Deployment для stateless-сервисов: веб-фронтенды, API-гейтвеи, микросервисы без локальных данных, рабочие процессы (workers).
• Рассматривайте StatefulSet для stateful-сервисов: инстансы баз данных (MySQL, PostgreSQL, MongoDB), Kafka, RabbitMQ, Elasticsearch — там, где важны уникальность и постоянство идентификаторов и томов.

Итог

При развертывании Deployment:

1. Сохраняется его внутреннее состояние оркестратора (версии, количество подов, статус).
2. Не сохраняется прикладное состояние данных вашего приложения по умолчанию.
3. Сохранить данные приложения можно, добавив в PodTemplate тома на основе PersistentVolumeClaim, но для этого необходимо тщательно продумать архитектуру (доступ к данным из нескольких реплик, бэкапы).
4. Для сложных случаев с требованием стабильных сетевых идентификаторов и уникальных томов предпочтительнее использовать StatefulSet.

Понимание этого различия — ключ к проектированию отказоустойчивых и масштабируемых приложений в Kubernetes.