Что создается в Deployment YAML?

Что создаётся при применении Deployment YAML в Kubernetes?

Применение Deployment YAML-файла в Kubernetes приводит к созданию одного основного объекта — Deployment, который, в свою очередь, автоматически управляет другими ключевыми объектами для обеспечения развёртывания и жизненного цикла приложений. Это не единичный артефакт, а целый каскад контролируемых ресурсов. Давайте детально разберём, что именно создаётся и как это работает.

1. Основной объект: Deployment

Сам Deployment — это объект API Kubernetes, который декларативно описывает желаемое состояние вашего приложения: какой образ контейнера использовать, сколько реплик (копий) Pod должно работать, как обновлять приложение и т.д. Он является контроллером в паттерне "контроллер-петля обратной связи".

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.21
        ports:
        - containerPort: 80

2. Производные объекты, управляемые Deployment

Deployment не управляет Pod'ами напрямую. Вместо этого он создаёт и контролирует два других объекта:

а) ReplicaSet

При первом создании Deployment немедленно генерирует ReplicaSet. Задача ReplicaSet — гарантировать, что в кластере постоянно работает заданное количество идентичных Pod (реплик). Если Pod падает, ReplicaSet создаёт новый. Deployment же управляет этими ReplicaSet'ами, особенно в процессах обновления.

• Связь: Один Deployment может управлять несколькими ReplicaSet'ами (например, текущий и предыдущий во время rolling update).
• Пример имени ReplicaSet: my-app-deployment-5d9b64f8d7 (генерируется автоматически из имени Deployment и хэша шаблона Pod).

б) Pods

Это основные исполняемые единицы в Kubernetes. ReplicaSet, созданный Deployment, на основе шаблона Pod (spec.template в YAML) создаёт и поддерживает указанное количество Pod'ов. Каждый Pod — это один или несколько контейнеров, которые разделяют сеть и хранилище и развёртываются на одном узле (ноде).

3. Косвенно создаваемые или задействуемые сущности

Deployment также взаимодействует с другими ресурсами кластера, хотя и не создаёт их напрямую в своём YAML:

• Сервис (Service): Хотя Service определяется отдельным YAML-манифестом, он напрямую нацеливается на Pod'ы, управляемые Deployment, через их Labels (в примере выше это app: my-app). Service обеспечивает стабильную сетевую точку доступа к группе Pod'ов.
• ConfigMaps и Secrets: Deployment-манифест может ссылаться на них для передачи конфигурации и чувствительных данных в Pod'ы (через volumes или переменные среды).
• PersistentVolumeClaims: Для stateful-приложений в шаблоне Pod могут быть объявлены PVC, которые запрашивают постоянное хранилище.

Ключевые процессы, инициируемые Deployment

Применяя Deployment, вы запускаете мощные механизмы оркестрации:

1. Обеспечение желаемого состояния: Контроллер Deployment постоянно сверяет фактическое состояние (сколько Pod'ов работает) с желаемым (replicas: 3). При расхождении он даёт команду ReplicaSet на корректировку.
2. Стратегии обновления: При изменении образа контейнера или другого поля в шаблоне Pod Deployment создаёт новый ReplicaSet и начинает постепенно создавать в нём Pod'ы, одновременно удаляя Pod'ы из старого ReplicaSet. Это реализует стратегию rolling update (по умолчанию) с нулевым временем простоя.
3. Откат (Rollback): Поскольку Deployment хранит историю ReplicaSet'ов, вы можете легко откатиться к предыдущей стабильной версии (kubectl rollout undo deployment/my-app-deployment).

Жизненный цикл и итоговая архитектура

Таким образом, один файл deployment.yaml разворачивает в кластере целую управляемую иерархию:

Deployment (управляет обновлениями и историей)
    │
    └── ReplicaSet-v1 (гарантирует количество реплик)
          │
          ├── Pod-1 (контейнеры приложения)
          ├── Pod-2
          └── Pod-3

Итог: В Deployment YAML создаётся не статический набор объектов, а динамическая система с управлением состоянием. Основной продукт — это сам объект Deployment, который, выступая как контроллер верхнего уровня, автоматически создаёт и управляет ReplicaSet'ами, которые, в свою очередь, создают и поддерживают в рабочем состоянии конечные Pod'ы с вашим приложением. Это абстракция, которая инкапсулирует complex-логику развёртывания, масштабирования и самовосстановления, позволяя разработчику декларативно описать лишь желаемый итог.