Deckhouse 1.68: CNI-изменения, новый Prometheus-оператор и staged rollout в production

Deckhouse 1.68 вышел в конце июля, и на прошлой неделе мы прошли это обновление на нескольких production-кластерах. Ничего не упало, сервисы не прерывались - но несколько моментов потребовали внимания. Рассказываем по делу.

CNI: Cilium получил новые параметры, Flannel сдвинулся

В 1.68 изменилась конфигурация CNI-модуля. Для Cilium появились новые параметры управления bandwidth manager и nodeport acceleration - обе функции основаны на eBPF и раньше требовали ручного вмешательства через valuesFrom или кастомные патчи. Теперь они выведены в стандартный CRD модуля.

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

Для кластеров на Flannel изменился диапазон поддерживаемых версий ядра - минимальная версия поднялась. На RedOS и «Альте» это не проблема: ядра там актуальные. Но если у кого-то в кластере есть ноды на более старых базовых образах - стоит проверить версию ядра до обновления Deckhouse, а не после.

Prometheus-оператор: версия обновилась, CRD поменялись

Это место, где нас слегка тряхнуло - не сильно, но неприятно.

Deckhouse тянет свою версию Prometheus-оператора внутри модуля monitoring-kubernetes. В 1.68 оператор обновился до версии, в которой изменились несколько полей CRD - в частности, в PrometheusRule и PodMonitor. Часть старых аннотаций перешла в deprecated-статус, и оператор начал выводить предупреждения при каждом reconcile таких объектов.

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

kubectl get prometheusrules -A -o json | jq '
  .items[] |
  select(.spec.groups[].rules[]?.alert != null) |
  "\(.metadata.namespace)/\(.metadata.name)"
' | sort -u

Это только список - дальше идёт ручная проверка каждого. Автоматически не мигрировать: структура правил у всех разная, и скрипт «исправления» легко сломает что-то нетривиальное.

Отдельно: если у вас есть Grafana, которая использует Deckhouse-ный Prometheus через ServiceMonitor - проверьте, что metricRelabelings написаны по новой схеме. У нас на одном кластере обнаружилась конфигурация, которую писали ещё год назад и с тех пор не трогали. После обновления оператора она начала выдавать предупреждения, хотя работала.

Staged rollout: логика изменилась тонко, но важно

Staged rollout - механизм Deckhouse для поэтапного обновления нод. Суть: вы задаёте NodeGroup с disruptions: approvalMode: Manual или Automatic, и Deckhouse обновляет ноды по одной, с паузами и проверками. Это то, что позволяет обновлять production без окна обслуживания.

В 1.68 изменилось поведение при approvalMode: Automatic: теперь Deckhouse перед drain ноды дополнительно проверяет, что на других нодах группы нет подов в состоянии Pending дольше определённого порога. Раньше эта проверка была менее строгой - дрейнили следующую ноду, даже если предыдущий батч ещё не полностью стабилизировался.

На практике это означает, что обновление нод-группы на кластерах с нестабильными workloads (где поды часто в Pending из-за ресурсов) стало медленнее - Deckhouse ждёт, пока всё устаканится. Это правильное поведение, но если у вас есть alert на «обновление ноды-группы идёт слишком долго» - порог стоит пересмотреть.

Мы разбирали механику staged rollout при переходе на 1.31 - логика та же, но теперь с дополнительной защитой. На кластерах с Kubernetes 1.33 это работает особенно заметно, потому что планировщик стал чуть умнее в batch-scheduling, и Pending-поды дольше не висят без причины.

Что проверяли перед обновлением

Наш чеклист для Deckhouse-обновлений к этому моменту уже накоплен:

• Версия ядра на нодах. Особенно если есть ноды не из стандартного образа.
• PDB с maxUnavailable: 0. Классика, которая блокирует drain. Находится одной командой, мы её уже описывали.
• Кастомные HelmRelease поверх Deckhouse-ных модулей. Если модуль обновился, а у вас есть override - надо проверить совместимость.
• PrometheusRule и PodMonitor в сторонних namespace. Deckhouse обновляет свои, но если у вас есть объекты мониторинга, созданные вне платформы - их надо проверить руками.

Обновление прошло за стандартное maintenance-окно, реальных простоев не было. Но предварительная подготовка заняла больше времени, чем само обновление - примерно 2:1.

Итог

Deckhouse 1.68 - это обновление из категории «меняется под капотом, но требует внимания к деталям». CNI-изменения для большинства незаметны, staged rollout стал чуть умнее, а вот Prometheus-оператор потребовал ревизии конфигурации мониторинга. Последнее - типичная история с платформенными обновлениями: где-то меняется CRD, и всё что было «и так работает» начинает требовать приведения в порядок.

Если кластеры сопровождаем мы в рамках managed-инфраструктуры - обновление планируем с pre-upgrade checklist, audit prometheus-объектов и тестом на staging перед production.