Цели
- Выполнить плавающее обновление с помощью kubectl
Обновление приложения
Пользователи надеются, что приложения будут работать круглосуточно, а разработчики в свою очередь хотят развёртывать новые версии приложений по несколько раз в день. В Kubernetes это возможно благодаря механизму плавающих обновлений (rolling updates). Плавающие обновления позволяют обновить деплойменты без простоев, шаг за шагом заменяя старые поды на новые. Новые поды будут запущены на узлах, имеющих достаточно ресурсов.
В предыдущем модуле мы промасштабировали приложение до нескольких экземпляров. Это необходимо сделать, чтобы иметь возможность обновлять приложение, не влияя на его доступность. По умолчанию максимальное количество подов, которое может быть недоступно во время обновления, и максимальное количество новых подов, которое можно создать, равны 1. Эти две опции могут быть определены в абсолютном значении (числа) или относительном соотношении (проценты). В Kubernetes обновления версионируются, поэтому любое обновление деплоймента можно откатить до предыдущей (стабильной) версии.
Краткое содержание:
- Обновление приложения
Плавающие обновления последовательно заменяют экземпляры подов на новые, тем самым позволяя обновить деплойменты без простоев
Обзор плавающих обновлений
Подобно масштабированию приложения, если деплоймент доступен извне, при обновлении сервис будет балансировать трафик только между доступными подами. Доступный под — это экземпляр, который может быть запущен для пользователей приложения.
С помощью плавающих обновлений можно:
- переводить приложение из одного окружения в другое (через обновления образа контейнера);
- откатываться к предыдущим версиям;
- осуществлять непрерывную интеграцию и непрерывную доставку приложений без простоев.
Если деплоймент был открыт наружу, в процессе обновления сервис будет балансировать трафик только на доступные поды.
В инструкциях ниже мы обновим приложение до новой версии и потом откатим его обратно.
Обновление версии приложения
Чтобы получить список деплойментов, выполните подкоманду get deployments:
kubectl get deployments
Для списка подов — подкоманду get pods:
kubectl get pods
Чтобы увидеть версию текущего образа в приложении, воспользуйтесь подкомандой describe pods и посмотрите на поле Image:
kubectl describe pods
Чтобы обновить версию образа приложения до v2, воспользуемся подкомандой set image, для которой укажем имя деплоймента и новую версию нужного образа:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=docker.io/jocatalin/kubernetes-bootcamp:v2
Эта команда перевела деплоймент на использование другого образа для приложения и инициировала плавающее обновление. Статус новых и старых подов (т. е. тех, которые будут остановлены) можно проверить с помощью подкоманды get pods:
kubectl get pods
Шаг 2: валидация обновления
Во-первых, убедимся, что приложение работает. Доступный извне IP-адрес и порт узнаем с помощью команды describe service:
kubectl describe services/kubernetes-bootcamp
Объявим переменную окружения NODE_PORT со значением порта нашего узла:
export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"
Далее обратимся через curl к проброшенному IP и порту:
curl http://"$(minikube ip):$NODE_PORT"
Каждый раз при вызове этой команды curl вам будет попадаться другой под. Обратите внимание, что все поды теперь работают с последней версией приложения (v2).
Проверить статус обновления можно также с помощью подкоманды rollout status:
kubectl rollout status deployments/kubernetes-bootcamp
Увидеть текущую версию образа приложения можно подкомандой describe pods:
kubectl describe pods
В поле Image у этого вывода убедитесь, что запущена последняя версия образа (v2).
Откат обновления
Выполним ещё одно обновление и попробуем развернуть образ, тегированный как v10:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10
Вызовем get deployments, чтобы увидеть статус деплоймента:
kubectl get deployments
Обратите внимание, что вывод показывает недостаток желаемого количества доступных подов. Обратимся к подкоманде get pods, чтобы вывести полный список подов:
kubectl get pods
Здесь обратите внимание, что некоторые поды перешли в статус ImagePullBackOff.
Чтобы получить больше информации о проблеме, выполните подкоманду describe pods:
kubectl describe pods
В разделе Events вывода по проблемным подам можно увидеть, что новая версия образа (v10) не существует в репозитории.
Чтобы откатить деплоймент к последней работающей версии, воспользуйтесь подкомандой rollout undo:
kubectl rollout undo deployments/kubernetes-bootcamp
Команда rollout undo откатывает деплоймент к предыдущему известному состоянию (к образу v2). Обновления версионируются, поэтому можно откатиться к любому предыдущему известному состоянию деплоймента.
С помощью подкоманды get pods выведем список подов еще раз:
kubectl get pods
Четыре пода работают. Проверить, какие версии образа развёрнуты в этих подах, можно подкомандой describe pods:
kubectl describe pods
Деплоймент снова использует стабильную версию приложения (v2). Откат произошёл успешно.
Не забудьте очистить содержимое вашего локального кластера:
kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp