Урок 7: Плавающие обновления и откат (rollback)
У нас уже есть Deployment, который поддерживает работу нескольких копий (Pods) приложения. Но что происходит, когда нужно выпустить новую версию — скажем, заменить image с nginx:1.27 на nginx:1.28? Наивный способ — снести всё и собрать заново, но тогда сервис пропадает на несколько секунд, и это чув
Это как менять колёса на едущей машине, не останавливая её, — ты меняешь по одному колесу за раз, так что машина продолжает ехать. А если новое колесо кривое, ты просто ставишь старое обратно.
- Плавающее обновление
- Способ обновить Deployment без простоя: Kubernetes постепенно заменяет старые Pods новыми, по несколько за раз, так что всегда остаётся достаточно живых копий для обслуживания запросов.
- Откат
- Возврат Deployment к предыдущей рабочей ревизии, когда новая версия оказывается сломанной. Команда kubectl rollout undo делает это за один шаг.
- Статус rollout
- Отслеживание хода обновления в реальном времени: сколько Pods уже обновлено из общего числа, пока сообщение не подтвердит, что rollout успешно завершён.
- maxUnavailable
- Сколько Pods могут быть недоступны одновременно во время плавающего обновления. Низкое значение сохраняет больше живых копий в каждый момент, но замедляет обновление.
- maxSurge
- Сколько дополнительных Pods сверх целевого числа можно временно создать во время обновления, чтобы новые копии были готовы до удаления старых.
- Ревизия
- Сохранённая версия Deployment. Каждое обновление создаёт новую ревизию, и Kubernetes запоминает предыдущие, чтобы к ним можно было вернуться.
