Введение
В предыдущих лабораторных работах вы создали один Pod. Pod — это базовый строительный блок Kubernetes, но вручную управлять подами утомительно. Если Pod завершит работу, его придётся запускать вручную. Если потребуется несколько копий, дополнительные Pod также придётся создавать вручную.
Здесь на помощь приходит Deployment.
Deployment — это контроллер более высокого уровня, который управляет ReplicaSet и подами вместо вас. Вы указываете, сколько реплик должно существовать и какой шаблон Pod нужно использовать, а Kubernetes поддерживает фактическое состояние в соответствии с этим описанием.
Главный переход в этой лабораторной работе — от управления отдельным Pod к управлению повторяемой рабочей нагрузкой. Один Pod ненадёжен, потому что является всего одним экземпляром. Deployment описывает шаблон создания подов и задаёт их целевое количество. Именно этот шаблон обеспечивает масштабирование и самовосстановление.
В этой лабораторной работе вы научитесь:
- Создавать строгого менеджера (Deployment) с конкретной целью — 3 реплики.
- Наблюдать, как менеджер нанимает работников (Pod).
- «Увольнять» работника, чтобы проверить реакцию менеджера (самовосстановление).
- Просить менеджера нанять больше работников (масштабирование).
Создание YAML-файла Deployment
На этом шаге вы составите описание задачи для своего менеджера. Это YAML-файл, в котором указываются образ для запуска и количество нужных копий (реплик).
Обратите внимание на дополнительную структуру по сравнению с обычным манифестом Pod. Deployment содержит selector и template. Selector сообщает Kubernetes, какие Pod относятся к этому Deployment, а template описывает создание новых подов. Эти две части должны оставаться согласованными, иначе Deployment не будет правильно управлять нужными подами.
Сначала убедитесь, что вы находитесь в каталоге проекта:
cd ~/project
Создайте с помощью nano новый файл с именем deployment.yaml:
nano deployment.yaml
Вставьте в файл следующую конфигурацию. Обратите особое внимание на строку replicas: 3 — именно здесь задаётся численность вашей команды.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Чтобы сохранить файл, нажмите Ctrl+X, затем Y, а потом Enter.
Этот файл сообщает Kubernetes: «Создай Deployment с именем nginx-deployment. Всегда поддерживай работу 3 подов с образом nginx:1.14.2. Если нужно найти эти Pod, ищи поды с меткой app: nginx».
Применение конфигурации и наблюдение
Теперь, когда описание задачи готово, наймём менеджера. Примените конфигурацию к кластеру:
При создании Deployment Kubernetes обычно автоматически создаёт ещё один объект — ReplicaSet. Именно ReplicaSet непосредственно отвечает за поддержание нужного количества работающих подов. Пока начинающим не нужно управлять ReplicaSet напрямую, но важно знать о его существовании: часто этот объект отображается в выводе команд.
kubectl apply -f deployment.yaml
Kubernetes подтвердит создание сообщением: deployment.apps/nginx-deployment created.
Deployment (менеджер) сразу начнёт создавать 3 Pod. Чтобы быстро увидеть их, выполните:
kubectl get pods
Вы должны увидеть 3 разных Pod. Имена всех подов начинаются с nginx-deployment-:
NAME READY STATUS RESTARTS AGE
nginx-deployment-66b6c48dd5-8j64w 1/1 Running 0 5s
nginx-deployment-66b6c48dd5-d95l2 1/1 Running 0 5s
nginx-deployment-66b6c48dd5-lzr5w 1/1 Running 0 5s
Также можно проверить состояние самого Deployment:
kubectl get deployments
В выводе должно быть указано READY 3/3. Это подтверждает, что все 3 запрошенные реплики запущены и работают.
Проверка самовосстановления
Одна из самых мощных возможностей Kubernetes — самовосстановление (Self-Healing). Deployment гарантирует, что фактическое количество подов всегда соответствует заданному количеству — 3. Если один Pod исчезнет, Deployment немедленно создаст ему замену.
Это работает потому, что Kubernetes постоянно сопоставляет фактическое состояние с желаемым. Удаление Pod не изменяет желаемое количество реплик, сохранённое в Deployment, поэтому система воспринимает удаление как отклонение и создаёт замену.
Проверим это, вручную удалив один из подов.
Сначала снова выведите список подов:
kubectl get pods
Скопируйте полное имя одного из подов, например nginx-deployment-66b6c48dd5-8j64w.
Теперь удалите этот Pod:
kubectl delete pod <paste-pod-name-here>
Kubernetes сообщит, что Pod удалён. Сразу после этого снова выполните kubectl get pods:
kubectl get pods
Вы увидите следующее:
- Старый Pod находится в процессе завершения или уже исчез.
- Уже появился новый Pod с другим именем и совсем небольшим значением
Age, например 2 секунды.
Deployment заметил, что один работник исчез, и немедленно нанял нового, чтобы сохранить размер команды равным 3. Благодаря этому приложение продолжает работать, даже если отдельный сервер или контейнер выйдет из строя.
Увеличение масштаба
Представьте, что ваш сайт стал популярным. 3 веб-серверов больше недостаточно — теперь нужно 5. Неужели придётся вручную создавать новые файлы или в спешке запускать дополнительные Pod?
Масштабирование Deployment изменяет заданное желаемое количество реплик, а не только текущий набор работающих процессов. Поэтому новый размер сохраняется после одного ручного действия. Контроллеры продолжают считать обновлённое количество реплик истинным, пока вы снова его не измените.
Нет. Достаточно сообщить менеджеру, что количество нужно увеличить.
Изменить количество реплик на лету можно с помощью команды kubectl scale.
Измените количество реплик с 3 до 5:
kubectl scale deployment/nginx-deployment --replicas=5
Теперь проследите за результатом:
kubectl get pods
Теперь вы увидите 5 работающих подов. Два новых Pod были запущены, чтобы выполнить новое требование.
Количество реплик можно также уменьшить. Если трафик снизился, вы можете сэкономить ресурсы, уменьшив это количество:
kubectl scale deployment/nginx-deployment --replicas=2
Снова выполните kubectl get pods. Вы увидите, что Kubernetes завершает работу лишних подов, пока не останутся только 2.
Именно поэтому компании ценят динамическое масштабирование в Kubernetes.
Итоги
В этой лабораторной работе вы познакомились с Deployment — интеллектуальным менеджером, который поддерживает работу приложений.
Вы успешно:
- Создали Deployment с 3 рабочими Pod.
- Проверили, что Deployment автоматически заменяет вышедшие из строя Pod (самовосстановление).
- Увеличивали и уменьшали количество реплик одной командой (масштабирование).
Теперь вы понимаете, почему отдельные Pod редко создают напрямую. Deployment обеспечивает надёжность и гибкость, управляя сложной работой по планированию и перезапуску подов вместо вас.
