Как происходит откат (rollback) деплоя в Kubernetes при логических ошибках в приложении?

Откат — это штатная операция. В Kubernetes она реализуется через механизм rollout для ресурсов типа Deployment.

Стандартная процедура отката:

1. Обнаружение проблемы: Система мониторинга (Prometheus) или алертинг (Alertmanager) сигнализируют о росте 5xx ошибок или падении бизнес-метрик после деплоя. Либо падают smoke-тесты в пайплайне.
2. Быстрый откат одной командой: Выполняем команду, которая возвращает Pod'ы к предыдущей ревизии образа.

   kubectl rollout undo deployment/my-frontend-app -n production

   Kubernetes начинает создавать Pod'ы со старым образом, соблюдая стратегию обновления (по умолчанию Rolling Update).

3. Контроль и анализ: Следим за статусом отката и восстановлением метрик.

   kubectl rollout status deployment/my-frontend-app -n production

Важные детали из практики:

• История ревизий: Kubernetes хранит историю изменений Deployment'а. Глубину истории можно настроить через spec.revisionHistoryLimit. Это позволяет откатиться не только на один шаг назад.
• Что именно откатывается: Команда rollout undo откатывает только образ контейнера (image) и ресурсы (resources), которые были частью предыдущей спецификации Pod'а. Изменения в ConfigMap или Secret, на которые ссылается Pod, требуют отдельного обновления или отката.
• Стратегия для Stateful приложений: Для StatefulSet или баз данных откат через rollout undo часто неприменим. Там используется более сложная процедура: восстановление из снепшота и переключение трафика на старую реплику. Поэтому для критичных компонентов мы используем Canary-деплой или feature-флаги, чтобы быстро отключить проблемную функциональность без отката всего сервиса.