Rolling update: постепенная замена экземпляров

Прямой ответ

Rolling update постепенно заменяет экземпляры, поэтому обновление выполняется без простоя, а сбой ограничивается частью экземпляров.

# Kubernetes Deployment: rolling update
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Постепенная замена позволяет проверить готовность нового экземпляра перед продолжением, поэтому сбой ограничивается частью экземпляров. О blue‑green стратегии — в статье про blue‑green deploy.

Шаг замены, проверка готовности и откат

Постепенная замена экземпляров позволяет проверить готовность нового экземпляра перед продолжением обновления.

Шаг замены. Число экземпляров, заменяемых одновременно, ограничивается, поэтому сбой затрагивает только часть экземпляров.

Проверка готовности. Новый экземпляр проверяется на готовность перед продолжением, поэтому сбой обнаруживается до замены всех экземпляров.

Откат при сбое. Возврат к старой версии выполняется, поэтому сбой не затрагивает все экземпляры.

Практическое следствие: замена всех экземпляров одновременно приводит к простою, поэтому обновление выполняется с простоем.

Отдельный аспект — сравнение с blue‑green. Blue‑green использует два окружения и мгновенное переключение, но требует двойных ресурсов. Rolling update использует обычные ресурсы, но откат занимает больше времени.

Три признака некорректного rolling update.

Замена всех экземпляров одновременно. Обновление выполняется с простоем, поэтому пользователи испытывают деградацию.

Отсутствие проверки готовности. Сбой не обнаруживается до замены всех экземпляров, поэтому сбой затрагивает всех.

Отсутствие отката. Возврат к старой версии не настроен, поэтому сбой не устраняется быстро.

О canary стратегии — в статье про canary deploy; об откате релиза — в статье про rollback deploy.

Постепенная замена и проверка готовности

Постепенная замена экземпляров позволяет проверить готовность нового экземпляра перед продолжением обновления.

Ограничение шага. Число экземпляров, заменяемых одновременно, ограничивается, поэтому сбой затрагивает только часть экземпляров.

Проверка готовности. Новый экземпляр проверяется на готовность перед продолжением, поэтому сбой обнаруживается до замены всех.

Сравнение с blue-green. Blue-green использует два окружения и мгновенное переключение, но требует двойных ресурсов. Rolling update использует обычные ресурсы, но откат занимает больше времени.

Практическое следствие: замена всех экземпляров одновременно приводит к простою, поэтому обновление выполняется с простоем.

Практика: настройка rolling update

1. Ограничивайте шаг замены. Число экземпляров, заменяемых одновременно, ограничивается, поэтому сбой затрагивает только часть.

2. Проверяйте готовность нового экземпляра. Проверка готовности выполняется перед продолжением, поэтому сбой обнаруживается до замены всех.

3. Настройте откат при сбое. Возврат к старой версии выполняется, поэтому сбой не затрагивает все экземпляры.

4. Фиксируйте замену в логе. Запись замены позволяет определить, когда и какой экземпляр был заменён.

5. Разделяйте версии по признакам. Признаки позволяют определить, какая версия обрабатывает запрос.

6. Проверяйте метрики после замены. Метрики нового экземпляра проверяются после замены, поэтому деградация обнаруживается.

7. Ограничивайте время обновления. Время обновления ограничивается, поэтому сбой не затягивается.

Рекомендации:

1. Не заменяйте все экземпляры одновременно. Обновление выполняется с простоем, поэтому пользователи испытывают деградацию.
2. Учитывайте шаг замены при мониторинге. Метрики нового экземпляра проверяются после замены, поэтому деградация обнаруживается.
3. Сопоставляйте откат с шагом замены. Возврат к старой версии выполняется, поэтому сбой не затрагивает все экземпляры.
4. Фиксируйте замену в ошибке. Признак в записи ошибки позволяет определить, какой экземпляр был заменён.
5. Пересматриваем шаг замены при изменении нагрузки. Рост числа экземпляров требует изменения шага замены.

Практический сценарий: обновление выполнилось с простоем

Контекст: обновление выполнилось с простоем, поэтому пользователи испытали деградацию.

1. Диагностика. Проверка показала, что все экземпляры заменялись одновременно. Отсутствие постепенной замены привело к простою, поэтому пользователи испытали деградацию.
2. Причина. Шаг замены не был ограничен, поэтому все экземпляры заменялись одновременно.
3. Действия. (а) Ограничили шаг замены, чтобы число экземпляров, заменяемых одновременно, было ограничено; (б) настроили проверку готовности нового экземпляра, чтобы сбой обнаруживался до замены всех; (в) настроили откат при сбое, чтобы возврат к старой версии выполнялся; (г) настроили фиксацию замены в логе для диагностики; (д) проверили метрики после замены, чтобы деградация обнаруживалась.
4. Результат. Обновление выполняется без простоя, поэтому пользователи не испытывают деградацию.

Вывод: замена всех экземпляров одновременно приводит к простою, поэтому пользователи испытывают деградацию. Постепенная замена с ограничением шага обеспечивает обновление без простоя.

Практический сценарий: обновление выполнилось с простоем

Контекст: обновление выполнилось с простоем, поэтому пользователи испытали деградацию.

1. Диагностика. Проверка показала, что все экземпляры заменялись одновременно. Отсутствие постепенной замены привело к простою, поэтому пользователи испытали деградацию.
2. Причина. Шаг замены не был ограничен, поэтому все экземпляры заменялись одновременно.
3. Действия. (а) Ограничили шаг замены, чтобы число экземпляров, заменяемых одновременно, было ограничено; (б) настроили проверку готовности нового экземпляра, чтобы сбой обнаруживался до замены всех; (в) настроили откат при сбое, чтобы возврат к старой версии выполнялся; (г) настроили фиксацию замены в логе для диагностики; (д) проверили метрики после замены, чтобы деградация обнаруживалась.
4. Результат. Обновление выполняется без простоя, поэтому пользователи не испытывают деградацию.

Вывод: замена всех экземпляров одновременно приводит к простою, поэтому пользователи испытывают деградацию. Постепенная замена с ограничением шага обеспечивает обновление без простоя.

FAQ

Что такое rolling update? Стратегия развёртывания, при которой экземпляры постепенно заменяются. Обновление выполняется без простоя, поэтому пользователи не испытывают деградацию.

Как ограничивается шаг замены? Через настройку числа экземпляров, заменяемых одновременно. Ограничение шага обеспечивает, что сбой затрагивает только часть экземпляров.

Как проверяется готовность нового экземпляра? Проверка готовности выполняется перед продолжением обновления. Сбой обнаруживается до замены всех экземпляров, поэтому сбой не затрагивает всех.

Чем rolling update отличается от blue-green? Rolling update использует обычные ресурсы и постепенную замену, blue-green использует два окружения и мгновенное переключение. Rolling update не требует двойных ресурсов, но откат занимает больше времени.

Источники: Kubernetes Deployment, Kubernetes pod lifecycle, Prometheus naming — ссылки в шапке.