Прочитайте команды и объясните, что они делают с точки зрения отката неудачного релиза

Короткий ответ

`kubectl rollout history` показывает список предыдущих ревизий Deployment, а `kubectl rollout undo` откатывает Deployment к предыдущей (или указанной) ревизии, пересоздавая поды со старой версией образа.

Как это работает подробнее

Kubernetes Deployment хранит историю ревизий (ограниченную параметром `revisionHistoryLimit`). Каждая ревизия соответствует версии шаблона пода (образ, переменные окружения и т.д.). Команда `undo` запускает тот же механизм rolling update, но «в обратную сторону» — постепенно заменяет поды новой проблемной версии на поды из указанной ревизии.

Пример кода

example.shКопировать

kubectl rollout history deployment/myapp
# REVISION  CHANGE-CAUSE
# 3         image updated to myapp:v1.4.0
# 4         image updated to myapp:v1.5.0  (текущая, проблемная)
kubectl rollout undo deployment/myapp --to-revision=3
# deployment.apps/myapp rolled back

Что использовать на практике

• На практике. откат через `kubectl rollout undo` быстрый и не требует пересборки образа, потому что использует уже существующий образ из реестра. Перед откатом полезно посмотреть `kubectl rollout history deployment/myapp` с `--revision=N`, чтобы убедиться, что откатываемся именно туда, куда нужно.
• Пример. Ожидаемое поведение: поды с `myapp:v1.5.0` постепенно заменяются на поды с `myapp:v1.4.0`; проверяется командой `kubectl get pods -l app=myapp` и `kubectl rollout status deployment/myapp`.

Подводные камни

• Частые ошибки. думают, что `rollout undo` восстанавливает также состояние базы данных или внешние ресурсы — это не так, откатывается только описание пода/контейнера; забывают, что если миграция схемы БД была несовместима со старой версией кода, одного отката Deployment недостаточно.