Deckhouse Kubernetes Platform и upstream 1.28: переводим клиента с kubeadm на отечественный дистрибутив

Deckhouse Kubernetes Platform добралась до upstream-версии 1.28 - и это повод не просто написать про обновление changelog, а рассказать про миграцию, которую мы только что завершили у одного из клиентов. Потому что переход с vanilla kubeadm на Deckhouse - это не просто смена дистрибутива, это другой подход к жизненному циклу кластера целиком.

Контекст: почему решились на перевод

Клиент - промышленное предприятие, объект КИИ, кластер на bare metal. Несколько лет жили на kubeadm: сами ставили, сами обновляли, сами собирали стек мониторинга из prometheus-operator, grafana и alertmanager. Работало - но каждое обновление версии Kubernetes требовало внимания, а стек мониторинга за это время оброс кастомными дашбордами и нестандартными конфигами, которые при обновлении prometheus-operator нужно было проверять руками.

Параллельно возникло требование от заказчика: производить только сертифицированное и реестровое ПО, что в части ОС означало Astra Linux. Astra Linux 1.8 вышла в январе, и поддержка этого дистрибутива в Deckhouse к этому времени уже была не экспериментальной, а штатной. Это и стало финальным аргументом.

Что изменилось в Deckhouse с 1.28

Обновление до upstream 1.28 принесло несколько вещей, которые для нас практически значимы:

Sidecar containers как отдельный тип - нативная поддержка init-контейнеров с restartPolicy: Always введена в 1.28 как alpha. Для нескольких наших рабочих нагрузок, где sidecar-паттерн использовался через обходные конструкции, это честное упрощение.

NodeVolumeLimits по-умолчанию включён - раньше надо было следить за лимитами томов на узел самостоятельно; теперь планировщик учитывает их нативно.

Улучшения в сборе метрик kubelet - тут важно понимать, что в контексте Deckhouse это не просто upstream-фича, а изменение, которое напрямую влияет на то, что показывают встроенные дашборды. Мы сразу увидели более детальную картину по ресурсам узлов - без каких-либо доработок с нашей стороны.

Специфика Deckhouse как дистрибутива: upstream-версия и версия самой платформы - разные числа. 1.28 в данном случае относится к Kubernetes API; сама Deckhouse KP идёт своей версионной линейкой поверх. Это иногда сбивает с толку, особенно когда объясняешь клиенту «на какой версии вы стоите».

Как проходила миграция

Перевод с kubeadm на Deckhouse - это не in-place upgrade, это развёртывание нового кластера и перенос нагрузки. Мы выбрали именно такой путь: поднять новый кластер Deckhouse рядом, перенести рабочие нагрузки пространство за пространством, потом переключить ingress и убрать старый кластер.

На этапе планирования больше всего времени ушло на инвентаризацию того, что накопилось на kubeadm-кластере. Несколько наблюдений:

Кастомный prometheus-стек оказался больше проблемой, чем преимуществом. Когда Deckhouse разворачивает мониторинг сам - получаешь правильно настроенный стек, дашборды, alerting-правила для системных компонентов. Наш кастомный Grafana с кастомными дашбордами потребовал аккуратного экспорта, часть дашбордов пришлось переработать под структуру метрик, которую предоставляет Deckhouse. Это был единственный момент, где мы потратили ощутимо больше времени, чем рассчитывали.

Политики безопасности пришли из коробки. Deckhouse включает модуль pod security, который уже на старте даёт разумные baseline-политики. На kubeadm мы отдельно настраивали PodSecurityPolicy (который, напомним, deprecated ещё с 1.21), а потом мигрировали на Pod Security Admission. В Deckhouse это уже решено - разбираешься только с тем, что специфично для твоей нагрузки.

Astra Linux из коробки работает. Установщик dhctl отработал на Astra Linux 1.8 без дополнительных патчей и плясок с зависимостями. Это честно хорошо - ещё год назад вопрос поддержки Astra в контейнерных платформах требовал отдельного изучения.

Что ускорило ввод в эксплуатацию

Если отвечать честно на вопрос «что дал Deckhouse по сравнению с kubeadm» - ускорение произошло не за счёт магии, а за счёт того, что ряд вещей больше не надо собирать и поддерживать руками.

Мониторинг инфраструктуры кластера работает сразу. Не надо устанавливать kube-prometheus-stack, не надо разбираться с конфликтами версий helm-чартов, не надо объяснять клиенту, почему алерт на disk pressure пришёл не в ту группу в Telegram. Это готово. Для ввода объекта в эксплуатацию в сжатые сроки - это реально важно.

Механика обновлений через release channels снижает операционную нагрузку. На kubeadm каждое обновление - это отдельная процедура с документацией, тестовым стендом и согласованным окном. Deckhouse с окнами обновления (update.windows) даёт другой уровень контроля: задаёшь, когда кластер может обновляться, и контроллер занимается rolling upgrade самостоятельно.

Managed-сопровождение таких объектов стало проще именно потому, что Deckhouse забирает часть операционных задач на уровень платформы. Это не значит, что вопросов нет - они есть, особенно в части кастомизации нестандартных требований. Но базовый уровень надёжности достигается быстрее.

Где пока открытые вопросы

Deckhouse - opiniated платформа, и это иногда создаёт трение. Модульный подход удобен, пока ты укладываешься в то, что предусмотрено. Когда нужно что-то нестандартное - начинаются вопросы к тому, как именно устроен конкретный модуль изнутри.

На текущем объекте мы столкнулись с одним таким местом: специфический способ балансировки трафика между сервисами, который на kubeadm решался кастомным DaemonSet. В Deckhouse это потребовало изучения того, как ingress-контроллер конфигурируется через CRD - решение нашлось, но не за пять минут.

Кластер работает первые недели - делать выводы об эксплуатационной зрелости рано. Смотрим на поведение при обновлениях, на мониторинг в условиях реальной нагрузки, на то, как команда клиента осваивает новую механику. Пока - хорошо.