Kubernetes — создание и управление Deployment

Deployment в Kubernetes представляет собой набор одинаковых Pod’ов. Deployment запускает несколько копий приложения и автоматически заменяет любые упавшие экземпляры. Это гарантирует, что один или несколько экземпляров приложения всегда запущены. За управлением Deployment отвечает контроллер Deployment в Kubernetes. Deployment использует шаблон Pod (Pod template), который содержит спецификацию для создаваемых Pod’ов.

Kubernetes Deployment — ресурс, который предоставляет декларативные обновления для приложений.

Для полной спецификации Deployment смотрите документацию Kubernetes API.

Во этом материале вы научитесь создавать Deployment в Kubernetes и выполнять основные операции с ним.

Требования

• Kubernetes-кластер с как минимум одним рабочим узлом.
• Установленный kubectl, настроенный на ваш кластер.

Важно: если у вас нет кластера, используйте инструкции по созданию кластера (например, на AWS/Ubuntu) или локальные варианты типа kind/minikube для тестов.

Что сделаем

• Создадим Deployment из YAML-манифеста.
• Проверим создание ReplicaSet и Pod.
• Убедимся, что Pod автоматически восстанавливается после удаления.
• Попробуем удалить ReplicaSet и Deployment, чтобы увидеть поведение контроллера.

Создание Deployment

Создайте файл с манифестом Deployment, например:

vim my-deployment.yaml

Вставьте в файл следующий YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: httpd-frontend
  name: httpd-frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd-frontend
  template:
    metadata:
      labels:
        app: httpd-frontend
    spec:
      containers:
      - image: httpd:2.4-alpine
        name: httpd

В этом примере:

• Создаётся Deployment с именем httpd-frontend (поле metadata.name).
• Deployment создаёт 1 реплику Pod (поле replicas).
• Шаблон Pod помечен меткой app: httpd-frontend (template.metadata.labels).
• В шаблоне указано, что Pod запускает контейнер httpd с образом httpd:2.4-alpine.

Примените манифест командой:

kubectl create -f my-deployment.yaml

Или, если вы хотите иметь возможность безопасно изменять манифесты, используйте:

kubectl apply -f my-deployment.yaml

Проверка состояния Deployment, ReplicaSet и Pod

Получить список Deployment и отфильтровать по имени:

kubectl get deployment | grep httpd-frontend

ReplicaSet, созданный Deployment’ом:

kubectl get replicaset | grep httpd-frontend

Pod’ы, созданные ReplicaSet:

kubectl get pods | grep httpd-frontend

Чтобы увидеть больше колонок и полезной информации, используйте «-o wide»:

kubectl get pods -o wide | grep httpd-frontend

Для детального описания конкретного Pod:

kubectl describe pod 

Например:

kubectl describe pod httpd-frontend-74fd6fd8cd-8nj2s

Тест: автоматическое воссоздание Pod

Удалим существующий Pod и проверим, создаст ли ReplicaSet новый экземпляр:

Сначала получим имя Pod:

kubectl get pods | grep httpd-frontend

Затем удалим Pod:

kubectl delete pod httpd-frontend-74fd6fd8cd-8nj2s

И снова проверим список Pod’ов:

kubectl get pods | grep httpd-frontend

Вы увидите, что контроллер ReplicaSet/Deployment автоматически создаёт новый Pod, чтобы поддержать заданное число реплик.

Тест: удаление ReplicaSet

Даже если вы вручную удалите ReplicaSet, контроллер Deployment восстановит его (и связанные Pod’ы), так как Deployment является владельцем ReplicaSet.

Проверим текущие ReplicaSet’ы:

kubectl get replicaset | grep httpd-frontend

Удаляем ReplicaSet (замените имя на фактическое):

kubectl delete replicaset httpd-frontend-74fd6fd8cd

Проверяем снова:

kubectl get replicaset | grep httpd-frontend

Это демонстрирует, что владельцем ReplicaSet является Deployment, и Deployment следит за репликами.

Удаление Deployment

Если вам больше не нужен развернутый сервис, удалите Deployment — это удалит управляемые ReplicaSet и Pod’ы.

kubectl get deployment | grep httpd-frontend

kubectl delete deployment httpd-frontend

kubectl get deployment | grep httpd-frontend

После удаления Deployment контроллер перестаёт восстанавливать ReplicaSet и Pod’ы; если вы удалите Pod или ReplicaSet позже, они не будут воссозданы.

Альтернативные подходы и лучшие практики

• kubectl apply vs kubectl create: apply удобен для итеративных изменений манифеста.
• Helm / Kustomize: для управления конфигурацией на уровне релизов и окружений.
• Operators: для сложных stateful-приложений используйте оператор или StatefulSet.
• Разделяйте конфигурацию и секреты: используйте ConfigMap и Secret вместо хардкодинга.
• Указывайте стратегии обновления (rollingUpdate) и readinessProbes/livenessProbes в манифесте.

Важно: для stateful приложений Deployment может не подходить — используйте StatefulSet, чтобы сохранить идентичность и хранилище.

Когда Deployment не работает как ожидается

• Несоответствие selector и template.labels приведёт к тому, что ReplicaSet не сможет подобрать Pod’ы.
• Неправильно заданные образ или команда контейнера — Pod будет в CrashLoopBackOff.
• Если Deployment управляет Pod, который требует стабильного хранилища или уникального идентификатора, поведение будет неверным — используйте StatefulSet.
• Некоторые поля манифеста являются неизменяемыми после создания; для их изменения может понадобиться пересоздание ресурса.

Мини‑методология для создания Deployment (быстрая схема)

1. Подготовьте Docker-образ и протестируйте локально.
2. Напишите манифест Deployment: metadata, replicas, selector, template, контейнеры.
3. Примените манифест: kubectl apply -f my-deployment.yaml.
4. Проверьте kubectl get deployment/replicaset/pods и kubectl describe pod.
5. Настройте readiness/liveness probes и политику обновлений.
6. Интегрируйте в CI/CD и обеспечьте откат (rollback) через kubectl rollout undo.

Ролевые чек‑листы

• Разработчик:
  • Убедиться, что приложение запускается локально в контейнере.
  • Обновить образ и теги перед деплоем.
• DevOps / SRE:
  • Проверить RBAC и права на создание Deployment.
  • Настроить мониторинг, readiness/liveness, ресурсы (CPU/Memory).
• QA:
  • Протестировать поведение при рестарте Pod и при обновлении образа.

Критерии приёмки

• Deployment присутствует и в статусе AVAILABLE.
• ReplicaSet создан и его desiredReplicas = readyReplicas.
• Под(ы) в статусе Running и готов(ы) (Ready).
• После удаления Pod контроллер восстанавливает количество реплик.
• После удаления Deployment ReplicaSet и Pod не восстанавливаются.

Глоссарий (1‑строчные определения)

• Deployment: контролируемый ресурс для декларативного управления набором Pod’ов.
• ReplicaSet: объект, который поддерживает заданное число реплик Pod’ов.
• Pod template: часть манифеста Deployment, описывающая, какие Pod’ы нужно создавать.

Итог

В статье показано, как создать простой Deployment в Kubernetes, посмотреть связанные ReplicaSet и Pod’ы, протестировать автоматическое восстановление при удалении Pod и поведение при удалении ReplicaSet и Deployment. Для production-релизов дополнительно настройте probes, политики обновления и интеграцию в CI/CD.

Важно: выбирайте StatefulSet для приложений, требующих устойчивого хранилища или стабильных идентификаторов Pod’ов.