Сценарий: во время rolling update старые реплики удаляются до готовности новых. Как параметры maxSurge и maxUnavailable управляют этим поведением?
maxSurge задаёт, сколько дополнительных реплик можно временно создать сверх желаемого числа, а maxUnavailable — сколько реплик допустимо одновременно вывести из строя относительно желаемого числа. Контроллер использует эти ограничения, чтобы выбрать баланс между скоростью обновления и сохранением доступной ёмкости.
Rolling update появился как способ обновлять сервис без полной остановки: новые экземпляры запускаются постепенно, а старые удаляются по мере готовности новых. Такой подход решает проблему длительного простоя, характерного для схемы «остановить всё — развернуть новую версию — запустить всё заново».
В оркестраторах одного факта запуска контейнера недостаточно: новая версия может ещё загружать данные, прогревать кэш или устанавливать соединения с зависимостями. Поэтому обновление должно учитывать не только число созданных экземпляров, но и их фактическую готовность.
Пусть Deployment должен поддерживать десять реплик. Если сначала удалить старые экземпляры, доступная ёмкость временно уменьшится. При высокой нагрузке это приведёт к очередям, росту задержек или отказам.
Если же сначала создать много новых экземпляров, кластеру может не хватить CPU, памяти, IP-адресов или квот облачного сервиса. Тогда обновление застрянет, хотя старые реплики ещё работают. Неверно выбранные ограничения также могут увеличить стоимость или оставить одновременно слишком много версий приложения.
maxSurge ограничивает превышение количества реплик над желаемым числом во время обновления. При десяти желаемых репликах и maxSurge: 2 контроллер может временно довести общее число реплик до двенадцати, чтобы сначала запустить новую версию.
maxUnavailable ограничивает количество недоступных реплик относительно желаемого числа. При десяти репликах и maxUnavailable: 1 контроллер не должен допустить состояние, в котором доступны менее девяти реплик из-за процесса обновления.
Параметры могут задаваться абсолютным числом или процентом. Процент округляется с учётом правил оркестратора, поэтому при небольших количествах реплик фактическое значение нужно проверять отдельно.
Упрощённый пример настройки выглядит так:
При такой политике контроллер обычно создаёт часть новых реплик, ждёт их готовности, затем удаляет часть старых. Точный порядок действий зависит от текущего состояния, сигналов готовности и доступных ресурсов, поэтому эти параметры не являются строгим сценарием каждой отдельной операции.
maxSurge: 0 запрещает временное превышение желаемого числа реплик. Это экономит ресурсы, но требует сначала освободить место удалением старых экземпляров и может снизить доступную ёмкость. maxUnavailable: 0 требует сохранять все желаемые реплики доступными, но без положительного значения maxSurge обновление может не иметь возможности продвинуться.
Важно отличать готовность от факта запуска процесса. Новая реплика считается пригодной для обслуживания только после успешной проверки готовности. Если проверка настроена неправильно или новая версия не может стать готовой, старые реплики могут сохраняться дольше, а обновление — остановиться.
Большое значение maxSurge ускоряет обновление, но увеличивает пиковое потребление ресурсов и потенциальную нагрузку на зависимости. Большое значение maxUnavailable ускоряет замену реплик и снижает требования к свободным ресурсам, но уменьшает запас производительности во время выката. Выбор зависит от критичности доступности, времени запуска экземпляра, ёмкости кластера и способности приложения переживать сокращение реплик.
Эти параметры не обеспечивают корректность самой новой версии. Они управляют ёмкостью и темпом замены, но не заменяют проверки готовности, контроль совместимости схемы данных, ограничение нагрузки и процедуру отката.
Сервис имеет двадцать реплик, каждая новая реплика запускается около двух минут, а кластер обычно использует почти всю память. При настройке с большим maxSurge обновление быстро создаёт дополнительные экземпляры, но планировщик не может разместить их из-за нехватки памяти. В результате новые реплики остаются в ожидании, а старые продолжают работать; выкатывание затягивается.
Рассматривались два варианта. Увеличить maxSurge означало бы ускорить обновление при наличии свободных ресурсов, но в данном кластере это повышало риск дефицита памяти. Увеличить maxUnavailable позволило бы раньше удалять старые реплики, однако при пиковом трафике могло не хватить обслуживающей ёмкости.
Выбрали небольшой maxSurge и ограниченный maxUnavailable, оставив запас доступных реплик. Дополнительно проверили, что сигнал готовности появляется только после завершения прогрева. Обновление стало медленнее, зато перестало упираться в нехватку памяти и сохраняло требуемую производительность для пользователей.
1. Что произойдёт, если одновременно задать maxSurge: 0 и maxUnavailable: 0?
Такое сочетание не оставляет контроллеру допустимого действия: нельзя создать реплику сверх желаемого количества и нельзя уменьшить число доступных реплик. Для rolling update это фактически блокирующая политика. Обычно требуется разрешить хотя бы небольшой surge или временную недоступность.
2. Почему корректные значения maxSurge и maxUnavailable не гарантируют отсутствие отказов?
Они ограничивают количество реплик, но не учитывают автоматически пропускную способность каждой версии, состояние внешних зависимостей и корректность маршрутизации. Например, десять доступных реплик новой версии могут обрабатывать меньше запросов, чем десять старых, или быть готовы формально, но ещё не прогреты. Поэтому нужны корректные проверки готовности, наблюдаемость, контроль нагрузки и при необходимости постепенная стратегия с дополнительными защитными условиями.
3. Чем rolling update отличается от гарантии обратной совместимости приложения?
Во время обновления некоторое время одновременно работают старая и новая версии. Они могут использовать одну базу данных, очередь или API, поэтому их форматы сообщений и изменения схемы должны быть совместимыми на переходном этапе. Параметры maxSurge и maxUnavailable не решают конфликт версий: безопасная миграция обычно требует обратносъвместимых изменений, поэтапного перехода клиентов и отдельного плана отката.