Последовательность развертывания GKE с использованием пользовательских этапов
GKE от Google Cloud теперь позволяет точно задавать порядок, в котором обновляются кластеры, используя последовательность развертывания с пользовательскими этапами, которая следует вашей бизнес-логике, а не стандартному региональному расписанию.
Обновление кластеров Kubernetes в десятках или сотнях сред — это сложная задача, требующая мастерства жонглера. Регулярно выходят патчи безопасности, но при этом необходимо поддерживать бесперебойную работу производственных сервисов. Старая модель регионального обновления могла привести к тому, что новая версия управляющего уровня (control plane) попадала в продуктивный кластер еще до того, как среда стейджинга завершала проверку, подвергая весь парк кластеров риску использования непроверенных изменений.
Недостатки старой модели
При региональном развертывании все кластеры в регионе рассматриваются как единая группа. Когда открывается окно обновления, управляющий уровень и узлы обновляются параллельно, независимо от того, на каком этапе конвейера выпуска находится кластер. Команды, полагающиеся на строгий процесс «сначала canary, затем production», сталкиваются с «нарушенным порядком» обновлений, что может вызвать регрессии, которые трудно отследить. Цена ошибки — это не только простой, но и инженерное время, затраченное на отладку проблемы, которую можно было обнаружить раньше.
Что добавляет последовательность развертывания GKE
Новая функция вводит объект RolloutSequence, который определяет серию этапов. Каждый этап представляет собой логическую часть вашего парка кластеров, идентифицируемую с помощью селекторов меток (label selectors). Система следует детерминированному пути:
- Сначала обновление управляющего уровня. GKE переводит центральный компонент управления на целевую версию до того, как коснется каких-либо узлов.
- Запуск таймера выдержки (soak timer). После того как управляющий уровень достиг целевой версии, запускается настраиваемая задержка, дающая вам окно для проведения проверок работоспособности.
- Параллельное обновление узлов. Пока идет отсчет таймера выдержки, GKE обновляет узлы, позволяя кластеру быстро перейти на новую версию.
- Следующий этап начинается только после завершения предыдущего. Когда все узлы и управляющий уровень на текущем этапе завершат обновление и таймер выдержки истечет, GKE переходит к следующему этапу.
Разбивая парк кластеров на более мелкие группы с метками, вы можете сначала обновить несколько canary-кластеров, убедиться, что правила мониторинга и маршрутизации трафика работают ожидаемым образом, а затем развернуть ту же версию на остальной части production-среды.
Правила, обеспечивающие корректность последовательности
- Этап «для всех» (catch-all): Финальный этап не содержит селектора меток, что гарантирует обновление любого кластера, который не подошел под условия предыдущих этапов.
- Разрешение конфликтов: Если метки кластера соответствуют более чем одному этапу, GKE помещает его в первый подходящий этап, предотвращая случайные двойные обновления.
Рычаги управления в реальном времени
Во время активного развертывания вы сохраняете контроль:
- Pause (Пауза) останавливает любые дальнейшие обновления, позволяя вам исследовать сбой на этапе canary, не вызывая каскадного распространения проблемы.
- Force-complete (Принудительное завершение) сокращает оставшееся время выдержки, если ваши скрипты проверки сообщают об успешном завершении раньше срока, ускоряя развертывание.
- Cancel (Отмена) прерывает всю последовательность, если в недавно выпущенной версии обнаружен критический баг, позволяя вам откатиться или дождаться исправления (hotfix).
Кому это выгодно и каковы компромиссы
Что изучить далее
Итог
Последовательность развертывания с пользовательскими этапами дает операторам GKE возможность обновлять кластеры в том порядке, в котором того требует бизнес, а не в том, который диктует платформа. Разделяя обновление управляющего уровня и узлов, добавляя настраиваемый период выдержки и предоставляя действия pause/force-complete/cancel, эта функция снижает риски обновления, сохраняя при этом скорость, необходимую cloud-native командам. Для всех, кто борется с хаосом при обновлении Kubernetes во всем парке кластеров, новая модель последовательности является конкретным шагом к более безопасной автоматизации, ориентированной на бизнес.