Как безопасно откатить неудачный Deployment и что при этом происходит с ReplicaSet?

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

Команда kubectl rollout undo deployment/<name> возвращает Deployment к предыдущей (или указанной через --to-revision) ревизии: Kubernetes масштабирует вверх старый ReplicaSet, соответствующий этой ревизии, и масштабирует вниз текущий, повторяя логику rolling update в обратную сторону.

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

каждая ревизия Deployment хранится как отдельный ReplicaSet (до тех пор, пока не превышен revisionHistoryLimit), и rollout undo просто переключает "активный" ReplicaSet на тот, что соответствует нужной ревизии, не требуя пересборки образа или повторного применения старого манифеста вручную.

Пример кода

Команды и выводКопировать

kubectl rollout history deployment/web
kubectl rollout undo deployment/web --to-revision=3
kubectl rollout status deployment/web

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

• Практика. перед откатом полезно посмотреть kubectl rollout history deployment/<name> и при необходимости kubectl rollout history deployment/<name> --revision=N для просмотра деталей конкретной версии. Откат — это быстрый способ вернуть известное рабочее состояние, пока команда разбирается с причиной проблемы в новой версии.

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

• Риски. полагаться на откат как на единственную меру безопасности без мониторинга и readiness probe — если проблемная версия уже успела полностью заменить старую и нанести ущерб (например, испортить данные), откат кода не отменяет последствий; не устанавливать revisionHistoryLimit, из-за чего в кластере годами копится множество неиспользуемых ReplicaSet.