Deployment в Kubernetes — это ключевой компонент, широко используемый для управления контейнеризированными приложениями. Это одновременно API-объект и декларативный способ управления, масштабирования и обновления контейнеризированных приложений. Deployment описывает желаемое состояние кластера Kubernetes и состояние запускаемых приложений — например, количество реплик, образ контейнера и прочие конфигурации, в то время как Kubernetes стремится поддерживать это состояние, автоматически занимаясь процессами обновления и масштабирования. В этой статье мы более подробно рассмотрим объект Deployment, а также с его помощью развернем тестовое приложение в кластере Kubernetes.
cloud
Предварительные требования
Для практической части нам понадобится кластер Kubernetes. Арендовать готовый кластер можно с помощью сервиса Kubernetes в облаке. Для работы с сервисами достаточно одной master-ноды и одной worker-ноды. Минимальная конфигурация — одноядерный процессор, 2 ГБ оперативной памяти и 30 ГБ места на диске NVMe.
После заказа кластера он будет готов к использованию в течение нескольких минут. kubeconfig
для подключения к кластеру будет сгенерирован и доступен в разделе «Дашборд».
Описание объекта Deployment
В основе Deployment лежит управление набором идентичных подов (pods). Поды в Kubernetes — это минимальная единица («строительный блок»), в которой могут быть запущены один или несколько контейнеров. Контроллер Deployment, входящий в состав управляющей плоскости Kubernetes, гарантирует, что фактическое состояние соответствует желаемому, указанному в манифесте формата YAML. Также Deployment используется с другими функциями Kubernetes, такими как сервисы, Ingress и горизонтальное автомасштабирование подов.
По сути, Deployment — это мост между контейнеризированными приложениями и динамической, распределенной природой кластера Kubernetes, что делает его краеугольным камнем для надежного и масштабируемого развертывания ПО.
Основные задачи Deployment
Deployment используется не только для развертывания готовых приложений в кластере Kubernetes, но и для:
- Декларативного обновления: пользователь задает желаемое состояние, а Kubernetes сам решает, как его достичь.
- Репликации подов: обеспечивает работу заданного количества реплик подов для высокой доступности и балансировки нагрузки.
- Самовосстановления: контроллер деплойментов автоматически заменяет поды, которые вышли из строя, перезапускает упавшие и перераспределяет их на другие узлы кластера.
- Автоматическое масштабирование: позволяет изменять число реплик вручную или автоматически при использовании механизма Horizontal Pod Autoscaler (HPA).
- Обновления и откаты: производит обновления приложений (например, меняет образ контейнера или конфигурационные файлы) с минимальным временем простоя и возможностью отката при проблемах, что важно при использовании в рабочих средах.
Как работает Deployment
Kubernetes Deployment функционирует за счет взаимодействия компонентов и четко определенного жизненного цикла, используя управляющую плоскость кластера Kubernetes для управления подами и поддержания желаемого состояния. Рассмотрим ключевые компоненты и жизненный цикл более подробно.
Основные компоненты
- API-объект Deployment:
Определяется в манифесте YAML или JSON, где задается желаемое состояние: образы контейнеров, количество реплик, метки и другие настройки. Хранится в API-сервере Kubernetes и управляется контроллером Deployment. - ReplicaSet:
Deployment создает и управляет объектом ReplicaSet, который гарантирует работу заданного числа реплик подов. ReplicaSet — промежуточный слой, отвечающий за создание, удаление и масштабирование подов. При каждом обновлении Deployment (например, новый образ) создается новый ReplicaSet. - Поды:
Минимальная единица программного обеспечения в Kubernetes. Поды содержат один или несколько контейнеров, которые разделяют сеть и ресурсы хранения. Deployment определяет шаблон подов, который включает конфигурацию контейнеров, порты, тома и другие параметры. - Контроллер Manager:
Часть управляющей плоскости Kubernetes. Контроллер Deployment отслеживает состояние кластера, сравнивает фактическое состояние (запущенные поды) с желаемым и принимает корректирующие меры. Обрабатывает сбои подов, а также процессы масштабирования и обновления. - Метки и селекторы:
Метки (labels
) — это пары ключ-значение, прикрепленные к подам (например,app: nginx
). Deployment использует селектор для определения, какими подами он управляет, обеспечивая точный контроль. - Сервисы:
Хотя сервисы не являются частью Deployment, они часто используются для обеспечения постоянного доступа к подам через балансировку нагрузки.
Жизненный цикл
Жизненный цикл Deployment включает несколько этапов. Рассмотрим каждый этап более подробно:
-
Создание:
Пользователь создает манифест Deployment при помощи командыkubectl apply -f <имя-файла>
.
Далее API-сервер Kubernetes сохраняет спецификацию, а контроллер Deployment создает ReplicaSet. Сервис kubelet запускает поды а информацию берет из компонента kube-scheduler. -
Синхронизация состояния:
Контроллер постоянно отслеживает кластер через API-сервер. Если под падает (например, из-за сбоя узла), контроллер создает новый, чтобы соответствовать желаемому количеству реплик. -
Обновление:
При изменении манифеста (например, смена образа контейнера) Deployment создает новый объект типа ReplicaSet. Старые поды постепенно заменяются новыми в соответствии со стратегией обновления. -
Самовосстановление:
Если нода выходит из строя, поды переносятся на другие доступные ноды кластера. Контроллер следит за здоровьем подов, перезапускает или заменяет их при необходимости. -
Возврат:
Если обновление приводит к сбоям, можно откатиться к предыдущей версии с помощью командыkubectl rollout undo
. Kubernetes хранит историю объектов ReplicaSet, что позволяет быстро восстановить стабильное состояние.
Как можно заметить, каждый этап жизненного цикла автоматизирует управление приложениями, делая Deployment мощным инструментом для надежного и гибкого развертывания приложений и сервисов в кластере Kubernetes.
Стратегии обновления
Kubernetes Deployment поддерживает обновления приложений с минимальным временем простоя. Стратегии обновления определяют, как старые поды заменяются новыми. Рассмотрим их подробнее:
1. Rolling Update (Плавное обновление)
Описание: Используется по умолчанию. Kubernetes постепенно заменяет старые поды новыми, при этом поддерживая доступность приложения.
Как работает: Создается новый объект типа ReplicaSet с обновленным шаблоном подов (например, новый образ). Новые поды запускаются, а старые удаляются по одному, пока не будет достигнуто желаемое состояние. Параметры maxSurge
(максимум дополнительных подов) и maxUnavailable
(максимум недоступных подов) контролируют процесс.
Пример настроек:
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
Достоинства: Нет простоев, плавный переход.
Недостатки: Медленнее, чем другие стратегии, и требует достаточно количества ресурсов.
2. Recreate
Описание: Удаляет все старые поды, затем запускает новые.
Как работает: Kubernetes останавливает все поды из старого ReplicaSet. После этого создает новые поды на основе обновленного шаблона.
Пример настроек:
spec:
strategy:
type: Recreate
Достоинства: Простая и быстрая стратегия, подходит для приложений, где допустим простой.
Недостатки: Вызывает время простоя, так как старые поды удаляются до запуска новых.
Выбор стратегии
Rolling Update
подходит для большинства рабочих приложений, где важна непрерывная доступность.Recreate
полезен для приложений, которые не поддерживают одновременную работу старой и новой версии (например, из-за несовместимости схемы базы данных).- Настройки
maxSurge
иmaxUnavailable
вRolling Update
позволяют балансировать между скоростью обновления и доступностью.
Kubernetes также хранит историю обновлений, позволяя откатиться к предыдущей версии с помощью команды:
kubectl rollout undo
Разворачиваем приложение при помощи Deployment
Как и любой другой объект в Kubernetes, Deployment создается с применением YAML- или JSON-манифестов — декларативного подхода Kubernetes. Перейдем к практической части. Ниже приведен пример манифеста типа Deployment, который разворачивает два пода с веб-сервером Nginx. Также в самом манифесте используется блок resources
, в котором заданы лимиты (limits
) и запросы (requests
). В данном примере для запуска двух подов необходимо минимум 256 МБ оперативной памяти и 200 миллиядер процессора. Контейнеры не смогут потреблять более 512 МБ оперативной памяти и 500 миллиядер процессора. Сетевой доступ организован при помощи сервиса типа ClusterIP:
apiVersion: v1
kind: Namespace
metadata:
name: nginx-deployment
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
namespace: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.26.0
ports:
- containerPort: 80
resources:
limits:
cpu: "500m"
memory: "512Mi"
requests:
cpu: "200m"
memory: "256Mi"
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
namespace: nginx-deployment
labels:
app: nginx
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
Сохраним конфигурацию выше в файл с именем nginx-deployment.yaml
.
Далее создадим объект Deployment при помощи команды:
kubectl apply -f nginx-deployment.yaml
Проверим, все ли объекты были успешно созданы. Для этого выполняем команду:
kubectl get all -n nginx-deployment
После выполнения команды kubectl get all -n nginx-deployment
можно увидеть, что все поды запущены и находятся в статусе READY. Также команда вывела все объекты — сервис ClusterIP, Deployment и ReplicaSet.
Проверим сетевое соединение. Поскольку сервис ClusterIP работает только внутри кластера, создадим тестовый под с утилитой curl
в том же пространстве имен (nginx-deployment
), где запущены контейнеры с Nginx.
Команда для создания пода с утилитой curl
:
kubectl run curl-pod --image=curlimages/curl --restart=Never -n nginx-deployment -- /bin/sh -c "sleep 3600"
Далее отправим запрос к поду с Nginx, используя IP-адрес ранее созданного сервиса ClusterIP. В данном случае IP-адрес — 10.97.231.105
. Чтобы узнать IP-адрес сервиса, можно воспользоваться командой kubectl get all -n nginx-deployment
, которую мы использовали ранее. IP-адрес будет указан в столбце с именем CLUSTER-IP.
Выполняем запрос при помощи утилиты curl
:
kubectl exec -it curl-pod -n nginx-deployment -- curl -v 10.97.231.105
Как можно увидеть на скриншоте выше, мы успешно получили ответ от Nginx и, как результат, полностью развернули готовое приложение при помощи объекта Deployment.
Основные команды для работы с Deployment
Для работы с Kubernetes используют утилиту kubectl
, в том числе для управления объектами Deployment. Ниже приведены ключевые команды:
Создание и применение Deployment
Команда:
kubectl apply -f <имя-файла.yaml>
Описание: Создает или обновляет Deployment на основе используемого манифеста YAML.
Проверка статуса Deployment
Команда:
kubectl get deployments
Если объекты были созданы в пространстве имен, отличном от default
, то его необходимо указать при помощи ключа -n
, например — kubectl get deployments -n nginx-deployment
. Для вывода объектов во всех пространствах имен используется ключ --all
— kubectl get deployments --all-namespaces
.
Описание: Выводит список всех объектов типа Deployment, включая количество реплик и их статус.
Просмотр подов включая созданных при помощи Deployment объекта
Команда:
kubectl get pods
Если поды были созданы в пространстве имен, отличном от default
, то его необходимо указать при помощи ключа -n
, например — kubectl get pods -n nginx-deployment
. Для вывода подов во всех пространствах имен используется ключ --all
— kubectl get pods --all-namespaces
.
Описание: Отображает поды, управляемые Deployment, с их статусом.
Масштабирование
Команда:
kubectl scale deployment <имя-deployment> --replicas=количество реплик>
Описание: Изменяет количество реплик.
Обновление
Команда:
kubectl set image deployment/<имя-deployment’а> <имя_контейнера>=<образ_контейнера>
Описание: Обновляет образ контейнера в Deployment.
Статус обновления
Команда:
kubectl rollout status deployment/<имя-deployment’а>
Описание: Показывает прогресс обновления.
Откат
Команда:
kubectl rollout undo deployment/<имя-deployment’а>
Описание: Откатывает Deployment к предыдущей версии.
Просмотр истории
Команда:
kubectl rollout history deployment/<имя-deployment’а>
Описание: Показывает историю обновлений Deployment.
Удаление
Команда:
kubectl delete deployment <имя-deployment’а>
Описание: Удаляет Deployment и связанные поды.
Команды, перечисленные выше, позволяют эффективно управлять объектами Deployment — от создания и масштабирования до обновлений и откатов.
Рекомендуется выполнять масштабирование и обновления через манифесты, а не вручную. Это упростит повторное развертывание и обеспечит идентичность конфигурации, например при миграции или восстановлении кластера.
Подготовили для вас выгодные тарифы на облачные серверы
Заключение
В этой статье мы подробно рассмотрели, что такое объект Kubernetes Deployment — мощный инструмент, упрощающий развертывание, масштабирование и обновление контейнеризированных приложений.
Deployment автоматизирует управление подами при помощи объекта ReplicaSet, обеспечивает самовосстановление и поддерживает различные стратегии обновления, такие как Rolling Update и Recreate.
Желаемое состояние кластера задается в YAML- или JSON-манифестах, а утилита командной строки kubectl
с многочисленными опциями и параметрами позволяет взаимодействовать с кластером и его объектами.