Deckhouse 1.72 и ROSA с Kubernetes 1.35: обновляем production-кластер и сравниваем manual steps

В апреле мы разбирали Kubernetes 1.35 на тестовом стенде - тогда Deckhouse только выкатил кандидат, и в stable-канале 1.35 ещё не было. Теперь вышел Deckhouse 1.72 с поддержкой 1.35 в stable, ROSA тоже объявила поддержку через свой update-канал. Мы прошли обновление на двух production-кластерах клиентов - один на Deckhouse, второй на ROSA - и посмотрели, насколько отличается опыт.

Что несёт Kubernetes 1.35 коротко

Если вы читали апрельский разбор, напомним ключевые моменты. In-place pod resizing перешёл в graduated: API финальный, feature gate включён по умолчанию, изменение CPU requests применяется без рестарта контейнера. Scheduler получил стабилизированный QueueingHint API и исправленный PreScore - плагины теперь работают на полном списке feasible-нод, а не на выборке. Для большинства кластеров второе проходит незаметно, но для нагрузок с кастомными scheduler-плагинами или активным VPA - заметно.

Важный момент из апрельского тестирования, который подтвердился в production: in-place resize для уменьшения memory requests по-прежнему уходит в Deferred у части нод. Не баг, поведение задокументировано, но нужно закладывать в операционные процедуры.

Deckhouse 1.72: что добавилось поверх 1.35

Deckhouse 1.72 - это не просто «bumped version Kubernetes». Вместе с 1.35 в релиз вошло несколько изменений платформы.

node-manager получил поддержку in-place resize в NodeGroup-политиках. Теперь можно задать стратегию resize на уровне NodeGroup: updateMode: InPlaceOrRecreate для подов, которые допускают in-place, и updateMode: Recreate для тех, которые нет. Раньше это нужно было настраивать в VPA-объектах индивидуально. Выглядит незначительно, но для большого кластера с несколькими типами нагрузок - ощутимое упрощение.

Модуль vertical-pod-autoscaler обновлён и теперь по умолчанию выставляет updateMode: InPlaceOrRecreate для новых VPA-объектов. Если у вас уже есть VPA-объекты без явного updateMode - при обновлении до 1.72 они получат этот режим. На кластере клиента это привело к одному небольшому сюрпризу: несколько подов с VPA начали получать in-place resize вместо eviction, и операционная команда клиента удивилась, увидев новый статус в kubectl get pods. Не проблема, но стоит предупреждать заранее.

Сетевой модуль cni-Cilium обновлён до версии с поддержкой scheduler-events от QueueingHint. Это связано с изменениями в scheduler из 1.35: Cilium теперь корректно сигнализирует scheduler, когда сетевой ресурс освободился, вместо того чтобы ждать следующего цикла. На практике это уменьшает задержку между освобождением пода и началом нового scheduling.

Сам процесс обновления на Deckhouse

Обновление кластера с Deckhouse 1.71 до 1.72 заняло около двух часов на кластере из 14 нод. Плановое обслуживание мы закладывали на четыре часа - осталось время.

Deckhouse обновляется через DeckhouseRelease объект в канале stable. Появился новый release - мы прочитали release notes, убедились, что нет несовместимостей с нашими кастомными ресурсами, подтвердили обновление. Дальше Deckhouse сам катит ноды в порядке, который мы задали в NodeGroup: сначала одна control-plane нода, потом остальные по одной с проверкой ready-состояния.

Manual steps для этого обновления:

• Проверить VPA-объекты перед обновлением: если updateMode явно не задан, он будет изменён на InPlaceOrRecreate. Мы прошлись по всем VPA и явно выставили режим там, где хотели сохранить прежнее поведение (eviction).
• Проверить кастомные scheduler-плагины, если есть. У нас их нет, но у одного из клиентов был DeploymentTopologyPolicy от стороннего оператора - проверили совместимость с изменённым PreScore.
• Предупредить операционную команду об изменении видимого поведения VPA-подов.

По сути три пункта. Для managed-кластеров с Deckhouse это стандартный ритуал перед каждым крупным обновлением.

ROSA: то же самое, но иначе

На втором кластере с ROSA процесс обновления до 1.35 выглядит по-другому структурно, хотя итог тот же.

ROSA использует канальную модель: stable, testing, candidate. Kubernetes 1.35 появился в testing раньше, в stable вышел несколько дней назад. Обновление применяется через rosectl cluster update --version 1.35 или через веб-консоль. Платформа сама управляет rolling update нод, но детальность контроля меньше: нельзя задать порядок обновления нод так же гибко, как в Deckhouse через NodeGroup-стратегии.

Manual steps для ROSA оказалось больше:

• VPA в ROSA не обновляется автоматически вместе с кластером. Нужно отдельно обновить VPA Operator через OperatorHub или helm-чарт. В Deckhouse это часть платформы и версионируется вместе.
• Feature gate InPlacePodVerticalScaling в ROSA включён, но настройка updateMode для VPA по умолчанию не меняется - нужно делать вручную, если хочешь перейти на in-place.
• Scheduler-плагины в ROSA работают через стандартный механизм Kubernetes, без дополнительной абстракции. После обновления до 1.35 убедились, что QueueingHint в кастомных плагинах реализован корректно - у одного плагина обнаружился пропущенный метод, который раньше не мешал, а теперь вызывает предупреждения.
• Проверить OperatorHub-операторы на совместимость с 1.35 API - это обязательный шаг, который в Deckhouse частично закрывается модулем compatibility-check.

Время обновления ROSA-кластера вышло примерно таким же - около двух часов на 12 нодах. Но подготовка заняла больше: чеклист был длиннее, часть шагов требовала явных команд вместо декларативной конфигурации.

Итог сравнения

Оба дистрибутива дали отечественный managed Kubernetes в production. Graduated in-place resize работает на обоих. По опыту этого обновления разница в ощущениях такая: Deckhouse автоматизирует больше нюансов платформы - VPA, CNI, совместимость - и требует меньше явных ручных шагов. ROSA даёт чуть больше прозрачности через стандартные Kubernetes-примитивы, но и чуть больше ответственности за согласованность компонентов.

Для команд, у которых операционные процедуры уже выстроены под один из дистрибутивов, это не повод переходить. Но для новых проектов разница в объёме manual steps - аргумент, который стоит учитывать.

In-place resize в production пока работает только для CPU: memory случай с Deferred встретился и здесь, на containerd 1.7 с cgroup v2. Будем держать это в виду при следующих VPA-политиках.