Understudy: нулевой простой для singleton-подов в Kubernetes

Две реплики — это арендная плата каждый час каждого дня за событие, которое длится минуты в месяц. Кроме того, при каждом дрейне вдвое сокращается запас по ёмкости, а для нагрузок, которые по своей природе являются одноэкземплярными (контроллеры с выбором лидера, планировщики, потребители очередей с фиксированным назначением), вторая реплика — это холостые расходы, ничего не дающие.

Ставка Understudy уже: ваша нагрузка может терпеть два пода в течение нескольких минут. Это то же самое свойство, которое уже требует rolling-обновление с maxSurge: 1, — так что если сегодня вы деплоите без простоев, вы соответствуете требованиям. Второй под существует только в момент, когда происходит нарушение.

Измерено на EKS с Karpenter на спот-узлах arm64, одна реплика за балансировщиком нагрузки приложения (application load balancer), без свободной ёмкости, так что каждая замена ждала нового EC2-инстанса. Зонд доступности работал примерно с частотой три запроса в секунду.

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

Understudy работает на уровне admission-контроля, поэтому API-сервер должен иметь доступ к сервису вебхука на порту 443. Это стандарт почти везде, а admission API, которое он использует, стабильно начиная с Kubernetes 1.16, однако встречаются исключения: приватная плоскость управления (control plane) с жёстко ограниченными группами безопасности или сетевая политика, не пропускающая трафик плоскости управления, заблокируют этот путь. Чарт требует Kubernetes 1.34 или новее.

Вебхук зарегистрирован с failurePolicy: Ignore намеренно, потому что вебхук, который недоступен, не должен блокировать все вытеснения в кластере. Это следствие важно сформулировать прямо: недоступный вебхук тихо деградирует до отсутствия защиты, а не до ошибки. Проверьте это один раз после установки, вытеснив защищённый под и ожидая отказа:

Рабочая установка отвечает TooManyRequests и запускает surge. Тишина означает, что API-сервер так и не достучался до вебхука.

Или из локальной копии репозитория:

Обновляетесь с более ранней версии? Смотрите UPGRADING.md[UPGRADING.md].

Затем защитите нагрузку, создав рядом с ней ресурс Understudy. Команда kubectl get understudies покажет цель, режим, фазу и то, как долго что-либо было заблокировано.

Стандартная установка занимает один Deployment с одной репликой. Вебхук обслуживается из того же пода. Нет ни DaemonSet, ни агентов на каждом узле. Дрейны, нарушения Karpenter, уменьшение масштаба autoscaler и обновления узлов — всё это обнаруживается только через API-сервер подом оператора, и на кластерах с Karpenter это включает прерывания спот-инстансов, поскольку Karpenter реагирует на очередь прерываний, добавляя узлу taint, который оператор и видит.

На кластерах, где каждый узел несёт taint, оператору нужны соответствующий toleration и nodeSelector — так же, как и любому другому контроллеру, запускаемому там.

holdMode определяет, удерживается ли вытеснение вообще. Surge это не затрагивает: подменный под поднимается при каждом сигнале об обречённости во всех трёх режимах, потому что поднять его заранее ничего не стоит, а проиграть гонку — дорого.

Если вы работаете на спот-инстансах без сентинеля, установите readinessDeadlineSeconds меньше окна уведомления платформы, иначе оператор может удержать вытеснение против дедлайна, которого не видит.

Кратко: отвечать на вытеснение у входа кодом HTTP 429, поднимать surge, когда узел объявляется обречённым, разрешать повторную попытку, как только замена проходит свои readiness-гейты, и масштабировать обратно, удаляя нужный под. PodDisruptionBudget не создаётся. Полное объяснение с диаграммами и обоснованием каждого решения — в docs/how-it-works.md[docs/how-it-works.md].

Сигналы поступают в оператор через четыре адаптера; ядро не содержит кода, специфичного для провайдера:

Настройте алерт на understudy_oldest_blocked_eviction_seconds. Он нужен для того, чтобы удержанное вытеснение всегда было видимым и ограниченным.

Если surge не может продвинуться вперёд, удержание снимается, а не стопорит дрейн навсегда. Вебхук работает в режиме fail-open: если все реплики оператора недоступны, Kubernetes разрешает вытеснения в обычном режиме по истечении таймаута вебхука. Чтобы немедленно отключить удержания:

Оператор отказывается управлять собой, пропускает цели, которым не может помочь, и отступает, пока идёт rollout.

Для продакшена используйте replicaCount: 2 и размещайте реплики на разных узлах. Каждая реплика следит за сигналами узлов и обслуживает вебхук, даже несмотря на то что reconciliation защищён лидер-локом. Если узел, на котором находится единственный под оператора, дренируется, его собственное вытеснение разрешается и защита подов, стоящих дальше в очереди этого дрейна, может исчезнуть.

Understudy реагирует на нарушения; он никогда их не инициирует. Поскольку никакого бюджета для предварительной проверки нарушителем нет, консолидация, дрифт и истечение срока могут выбрать узел как обычно. Нарушитель начинает работу, повторяет попытки admission-удержания, пока поднимается подменный под, и продолжает, как только тот готов.

Запросы, находящиеся в полёте, не сохраняются. Understudy гарантирует готовую замену, но не запросы, уже направленные к уходящему поду. Добавьте поду preStop-хук, который длится дольше, чем задержка дерегистрации балансировщика нагрузки; ни один механизм surge сделать это за вас не может.

Принудительный дедлайн — это гонка с платформой. AWS даёт около двух минут, и быстро стартующая нагрузка может её выиграть, даже если сначала нужно подготовить новый узел. GCP и Azure дают около тридцати секунд — выиграть с холодного старта невозможно, поэтому там ценность — это упорядоченное освобождение и ранняя замена, а не нулевой простой.

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

Apache 2.0