Deckhouse Kubernetes Platform: разворачиваем CE и смотрим, что внутри

Red Hat в 2022 перестал продавать OpenShift в России. Для части наших клиентов это была не абстрактная новость, а вполне конкретная проблема: несколько контрактов держались на OpenShift 4.x, и вопрос замены встал без красивых альтернатив. Ванильный kubeadm - это не замена платформе с встроенным мониторингом, авторизацией и нормальным Ingress. Нужно что-то ближе к «батарейки в комплекте».

Флант давно ведёт Kubernetes в продакшне, и их Deckhouse Kubernetes Platform появилась именно как ответ на запрос «дайте k8s как продукт, а не набор YAML». Community Edition открыт, Enterprise Edition с поддержкой. Нас интересовал CE - посмотреть, насколько close to production без Enterprise-лицензии.

Как разворачивали

Стенд: три виртуальных машины на Proxmox, Ubuntu 22.04, 4 vCPU / 8 GB RAM на каждой. Один control plane, два worker. Установщик Deckhouse - это Docker-образ, который запускается на мастере и дальше всё делает сам через dhctl install. Конфигурация описывается в YAML-манифесте, куда передаёшь параметры сети, тип CRI, доступ к узлам.

Нюанс первый: dhctl тянет образы из registry.deckhouse.io. В закрытом контуре это сразу вопрос - нужно зеркало или прокси к реестру. В открытой сети всё прошло без проблем, но для боевого закрытого стенда придётся готовить Nexus или аналог заранее.

Нюанс второй: инсталлятор довольно разговорчивый - выводит прогресс по каждому компоненту. Занял около 20 минут на нашем стенде, и всё это время понятно что происходит. По сравнению с kubeadm + ручной доустановкой стека мониторинга - небо и земля.

Что получаем out-of-box

Это главное, что отличает Deckhouse от голого kubeadm. После установки работает:

• Мониторинг. Встроенный стек на базе Prometheus + Grafana с преднастроенными дашбордами по узлам, подам, потреблению ресурсов. Причём это не «поставили helm chart Prometheus», а интегрированный компонент - метрики Kubernetes API, etcd, kubelet уже собираются, алерты уже есть.
• Ingress. nginx-ingress-controller развёрнут и настроен. Объект IngressClass создан, SSL-терминация работает. У нас тестовый стенд без внешних сертификатов, но конфигурация cert-manager присутствует.
• Авторизация. Dex + OIDC из коробки. Можно подключить внешний провайдер - LDAP, GitHub, Gitlab. Для корпоративной среды это критично: у OpenShift был HTPasswd + LDAP connector, у Deckhouse то же самое, только через Dex.
• Dashboard. Веб-интерфейс по умолчанию - не Kubernetes Dashboard в чистом виде, у Deckhouse есть свой, более информативный. Если привыкли к OKD (OpenShift Community) консоли - здесь схоже по логике, хотя и не так навороченно.

Честно говоря, мы ожидали больше «сырости». Первый сюрприз случился когда Prometheus поднялся сам и уже показывал CPU по нодам - без единой дополнительной команды.

Сравнение с ванильным kubeadm

На kubeadm мы поднимаем кластеры давно, последний большой апгрейд под Kubernetes 1.26 прошли в декабре. Разница по трудозатратам на первичный запуск серьёзная.

После kubeadm чтобы получить сопоставимый результат нужно: поставить Prometheus Operator + kube-state-metrics + node-exporter, настроить Grafana с дашбордами, поставить nginx-ingress или другой контроллер, настроить cert-manager, поставить Dex или keycloak для OIDC, настроить RBAC под группы. Это реалистично занимает 2-3 дня работы инженера, и потом это всё надо поддерживать по отдельности.

В Deckhouse всё это - модули, которые включаются/выключаются в конфиге. Обновляются тоже вместе с платформой.

Обратная сторона: вы не полностью контролируете что именно стоит. Если у вас жёсткие требования «только такой nginx и только такой Prometheus», будет сложнее. Для стандартных корпоративных сценариев это не проблема.

Что не понравилось

Документация на русском - хорошо, но местами с пробелами. Ряд модулей описан кратко, приходилось смотреть исходники или реальные CRD чтобы понять все параметры.

Модульная система - нужно привыкнуть. Вместо прямого helm install или kubectl apply здесь ModuleConfig - собственный CRD Deckhouse. Привычного инженера это поначалу дезориентирует.

Минимальные требования на железо. Наш стенд 4/8 уже был на грани - с мониторинговым стеком control plane потреблял почти 3 GB RAM. Для прода с нормальным числом подов закладывайте 16 GB на мастер без вопросов.

Где стоим сейчас

Это был тестовый стенд, не продакшн. По итогам решение пока такое: Deckhouse CE идёт в шорт-лист как замена OpenShift для клиентов, которым нужна платформа с мониторингом и авторизацией, а не голый kube. Для производственного развёртывания нужно ещё разобрать обновление платформы на живом кластере и сценарии восстановления etcd - это следующий этап.

Параллельно смотрим на РЕД ОС + kubeadm, но там другой профиль: подходит, когда важен реестр Минцифры, а не готовый стек компонентов. Разные ответы на разные вопросы.

Если ведёте инфраструктуру на k8s или как раз думаете чем закрыть уход OpenShift - managed-сопровождение включает и выбор платформы, и дальнейшую эксплуатацию.