Как происходит обновление приложения: выкатывание новой версии, перевод трафика и гашение старой версии

Что проверяют

Понимаете ли вы, что выкатка это не «залить новый JAR и перезапустить», а управляемая смена версий без потери запросов. Следом почти всегда спрашивают, как откатиться и что делать с базой, если новая версия поменяла схему.

Как отвечать

Разложите процесс на три шага и к каждому назовите механизм:

• выкатка: собираете образ и поднимаете новые экземпляры рядом со старыми. В Kubernetes стратегия по умолчанию RollingUpdate: поды меняются порциями, размер порции задают maxSurge и maxUnavailable (по умолчанию по 25%);
• перевод трафика: новый под получает запросы только после того, как прошёл readinessProbe. В Spring Boot для этого есть группы Actuator /actuator/health/readiness и /actuator/health/liveness. Для осторожных релизов берут blue-green (две полные среды, переключение на балансировщике одним движением) или canary: сначала 5-10% трафика через веса в HTTPRoute Gateway API, Istio или Argo Rollouts, дальше по метрикам;
• гашение старой версии: под получает SIGTERM, перестаёт брать новые запросы и дорабатывает текущие. В Spring Boot за это отвечает graceful shutdown (server.shutdown=graceful) и spring.lifecycle.timeout-per-shutdown-phase, который должен укладываться в terminationGracePeriodSeconds пода (по умолчанию 30 секунд).

Отдельно скажите про базу: миграции Flyway или Liquibase делаются обратно совместимыми по схеме expand/contract. Сначала добавляете колонку, обе версии приложения работают, и только в следующем релизе удаляете старое. Иначе откат упрётся в схему, которую уже не вернуть.

Где спотыкаются

Забывают, что удаление пода из балансировки асинхронно. Без короткой паузы в preStop под уже получил SIGTERM, а трафик на него ещё идёт, и клиенты ловят 502.

Путают liveness и readiness. Проверка базы в liveness приводит к тому, что при падении базы Kubernetes перезапускает все поды разом.

Говорят «откатимся, если что», не имея критерия. Сильнее ответ, где откат запускается по конкретным метрикам: доля 5xx, латентность p99, всплеск ошибок в логах.