Как работает обновление без простоя в Kubernetes и как откатиться?

Deployment по умолчанию использует стратегию RollingUpdate: создаётся новый ReplicaSet, поды заменяются частями по параметрам maxSurge (сколько можно создать сверх нормы) и maxUnavailable (сколько можно вывести). Трафик переключается по готовности: пока новый под не прошёл readiness, он не получает запросов, а старый не выводится. Откат — kubectl rollout undo, потому что предыдущий ReplicaSet сохраняется. Для отсутствия ошибок при выкате нужны корректная readiness-проба, обработка SIGTERM с дренированием соединений и обратная совместимость миграций базы, иначе «выкат без простоя» приводит к пятисотым во время релиза.