Information in this document may be out of date

This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: Performing a Rolling Update

Выполнение плавающего обновления

Выполнение плавающего обновления с помощью kubectl.

Цели

  • Выполнить плавающее обновление с помощью 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=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