Если вы хотите использовать развертывание для развертывания версии для подмножества пользователей или подмножества серверов, вы можете следовать канареечному шаблону, описанному в разделе «Управление ресурсами», и создать несколько развертываний, по одному для каждой версии.
Так называемый Canary Release означает, что процесс обновления приостанавливается сразу после создания первого нового Pod, а основной частью остается старая версия. Затем тщательно отсейте небольшое количество пользовательских запросов на основе пользовательских характеристик и направьте их в новую версию приложения, а затем продолжайте наблюдать, оправдываются ли ожидания. Убедитесь, что нет проблем, прежде чем продолжить выполнение оставшейся части непрерывного обновления, в противном случае немедленно выполните откат.
Последовательные обновления для развертываний
Развертывание поддерживает настраиваемое управление циклическим ритмом в процессе обновления, например «приостановить» или «продолжить» операцию обновления. Более сложное управление процессом также может быть достигнуто с помощью атрибутов maxSurgeи .maxUnavailable
Развертывание будет .spec.strategy.type==RollingUpdateобновлять модули в режиме последовательного обновления. Вы можете указать maxUnavailableи maxSurgeконтролировать процесс непрерывного обновления.
максимально недоступный
.spec.strategy.rollingUpdate.maxUnavailable— это необязательное поле, в котором указывается максимальное количество подов, недоступных в процессе обновления. Это значение может быть абсолютным числом (например, 5) или процентом от желаемых подов (например, 10%). Процентные значения преобразуются в абсолютные числа, а десятичная часть удаляется. Если .spec.strategy.rollingUpdate.maxSurgeравно 0, это значение не может быть 0. Значение по умолчанию — 25%.
Например, если для этого значения установлено значение 30 %, последовательное обновление сразу же начнет сокращать старый ReplicaSet до 70 % от ожидаемого количества модулей Pod. После того, как новые модули будут готовы, вы можете продолжить масштабирование старого набора реплик, а затем увеличить масштаб нового набора реплик, убедившись, что общее количество модулей, доступных в любой момент обновления, составляет не менее 70 % от желаемого количества модулей.
максимальное пиковое значение
.spec.strategy.rollingUpdate.maxSurge— это необязательное поле, в котором указывается количество модулей, которые могут быть созданы сверх желаемого количества модулей. Это значение может быть абсолютным числом (например, 5) или процентом от желаемых подов (например, 10%). Если MaxUnavailableравно 0, это значение не может быть 0. Процентные значения преобразуются в абсолютные числа путем округления в большую сторону. Значение по умолчанию для этого поля — 25%.
Например, если это значение равно 30 %, новый ReplicaSet будет расширен сразу после запуска последовательного обновления, при этом общее количество старых и новых подов не должно превышать 130 % от общего количества требуемых подов. После того, как старые поды будут уничтожены, новый ReplicaSet можно будет дополнительно масштабировать, гарантируя, что общее количество запущенных подов в любой момент обновления не превысит 130 % от желаемого общего количества подов.
прогресс крайний срок секунд
.spec.progressDeadlineSecondsявляется необязательным полем, в котором указывается количество секунд, в течение которых система ожидает выполнения развертывания, прежде чем сообщить об ошибке выполнения развертывания. Такие отчеты будут отражаться в статусе ресурса как type: Progressing, status: False, reason: ProgressDeadlineExceeded. Контроллер развертывания будет продолжать повторять развертывание в течение 600 миллисекунд по умолчанию. В будущем, когда будет реализован автоматический откат, контроллер развертывания будет откатывать развертывание, как только обнаружит такое состояние.
Если указано, значение этого поля должно быть больше, чем .spec.minReadySecondsзначение .
Фактическая операция
Обычно скользящее обновление развертывания удаляет модуль v1 и создает модуль v2, потому что развертывание maxSurgeи maxUnavailableатрибут по умолчанию равны 1. В канареечном выпуске необходимо сначала создать, а затем удалить, а общее количество доступных модулей не меньше. чем ожидаемое значение. Количество создаваемых здесь реплик Pod зависит от его грузоподъемности . Установите maxUnavailableна 0:
$ kubectl patch deployments my-app-deployment \
-p '{"spec": {"strategy": {"rollingUpdate": {"maxSurge": 1, "maxUnavailable": 0}}}}'
Запускает процесс обновления контроллера развертывания, приостанавливая обновление сразу после изменения версии образа соответствующего контейнера . Здесь вы можете установить maxReadySecondsатрибут (сколько ждать готовности нового объекта Pod после его создания), чтобы зарезервировать время работы для паузы обновления, либо выполнить две команды в Shell одновременно:
$ kubectl set image deployments my-app-deployment myapp=path/to/image:new \
&& kubectl rollout pause deployments my-app-deployment
Проверьте статус развертывания.После создания новой версии ресурса Pod скользящее обновление приостанавливается :
$ kubectl rollout status deployments my-app-deployment
Затем с помощью ресурсов Service или Ingress и соответствующих параметров политики маршрутизации небольшая часть пользовательского трафика направляется в новый Pod для проверки выпуска. Через некоторое время подтвердите, что проблем нет, а затем возобновите непрерывное обновление:
$ kubectl rollout resume deoloyments my-app-deployment
Если «канарейка» терпит бедствие, пора возобновить скользящее обновление и немедленно откатиться :
$ kubectl rollout resume deoloyments my-app-deployment \
&& kubectl rollout undo deoloyments my-app-deployment
После завершения отката проверьте, был ли объект контроллера ReplicaSet, управляемый развертыванием, восстановлен до указанной исторической версии, чтобы убедиться, что откат прошел нормально. Вы можете вернуться к определенной исторической версии, указав серийный номер исторической версии после kubectl rollout undoпараметра .--to-revision=N
$ kubectl rollout history deployments my-app-deployment
$ kubectl rollout undo deployments my-app-deployment --to-revision=3
Дополнительные атрибуты см. на официальном веб-сайте:
адрес веб-страницы развертывания K8S deployemnt canary.