Deckhouse Kubernetes Platform 1.50+: переводим кластер разработки и смотрим, что внутри

Примерно год назад мы смотрели на российский рынок дистрибутивов Kubernetes с умеренным скептицизмом: РЕД ОС 7.3 давала kubeadm-кластер, но это был всё же голый upstream, обёрнутый в RHEL-совместимую ОС. Deckhouse от Флант стоял в стороне - продукт с историей, за которым чувствовались годы внутреннего использования в самом Фланте, но с точки зрения зрелости пакета для внешнего потребителя вопросов оставалось много. Релизная серия 1.50+ показалась нам достаточно взрослой, чтобы перестать читать changelog и начать руками.

Под эксперимент выбрали кластер разработки одного из клиентов - не продакшн, но и не стенд: реальные CI-пайплайны, разработчики, которые замечают даже кратковременные лаги kubectl. Хороший полигон.

Что такое Deckhouse и чем он отличается от kubeadm

Важно понимать: Deckhouse - это не просто upstream Kubernetes с парой патчей. Это opiniated-дистрибутив, который берёт на себя весь жизненный цикл кластера: bootstrapping, networking (Cilium или Flannel на выбор, по умолчанию Cilium), мониторинг, ingress, cert-manager, storage - всё это идёт как встроенные модули, управляемые через CRD. Включаешь модуль - он появляется. Выключаешь - убирается. Идея красивая, на практике непривычная после лет работы с kubeadm и helm install по отдельности.

С переходом на containerd и отказом от dockershim в upstream мы уже жили - Deckhouse в этом смысле не удивил, containerd там базовый CRI из коробки. Но подход к сети и к observability оказался другим.

Встроенный мониторинг: Prometheus без боли?

Это, пожалуй, самое заметное отличие от голого кластера. Deckhouse включает модуль monitoring-kubernetes, который разворачивает Prometheus, Grafana и набор дашбордов - причём конфигурация ServiceMonitor и PrometheusRule идёт через операторные CRD, которые Deckhouse уже умеет читать. Не надо отдельно ставить kube-prometheus-stack и выяснять, почему ваш чарт конфликтует с чужим ServiceAccount.

На практике мы получили работающий мониторинг узлов, подов, etcd и ingress-трафика примерно за двадцать минут после установки кластера. Это честно хорошо. Оговорка: дашборды заточены под структуру, которую Deckhouse сам же и создаёт. Если у клиента уже был кастомный Prometheus с многолетней историей - интеграция потребует осмысления, не просто «подключить».

Алертинг настраивается через модуль prometheus и внешние каналы (почта, Slack, Telegram). Настройка через CRD CustomAlertmanagerReceiver - непривычно, но логично.

Обновления без простоев: механика

Это второй пункт, ради которого стоило смотреть на Deckhouse в контексте продуктивных кластеров. Обновления версии Kubernetes и самого Deckhouse управляются через объект NodeGroup и ClusterConfiguration. Ключевой параметр - update.windows: указываешь временные окна, и контроллер сам выбирает момент для rolling update узлов, соблюдая maxUnavailable.

Мы попробовали обновление minor-версии Deckhouse на dev-кластере. Узлы уходили на обновление по одному, рабочая нагрузка мигрировала без видимых прерываний. Сразу честно скажем: на кластере с тремя воркерами это выглядит хорошо, как поведёт себя механика на двадцати - вопрос открытый, проверим на следующем этапе.

Один нюанс: Deckhouse использует собственный канал выпуска (release channel - Alpha, Beta, Early Access, Stable, Rock Solid). Это отдельная версия сверху над версией Kubernetes. Разобраться с тем, что за чем следует, занимает время - документация есть, но требует вдумчивого чтения.

Что удивило в процессе

Несколько наблюдений, которые не попадают в категорию «плюс» или «минус», но важны для принятия решения:

• Установщик (dhctl) работает с bare metal и облаком через единый интерфейс. Для клиентов, у которых часть стендов в железе, часть в Яндекс.Облаке, это интересно. Попробовали только bare metal - вопросов не возникло.
• Все модули версионируются вместе с платформой. Нет ситуации «ingress-nginx 1.7, cert-manager 1.12, и разберитесь сами». Зато и обновить отдельный модуль вне релизного цикла нельзя - нужно ждать новой версии Deckhouse.
• Кастомизация через patches и extender есть, но требует понимания внутренней архитектуры. Если хочется что-то выкрутить вне стандартных параметров CRD - придётся изучать, как модули устроены внутри. Это не тривиально.
• Сообщество и документация на русском - для команд, которые работают с отечественными заказчиками, это реально удобно. Не нужно переводить тикеты.

Предварительный итог

Мы не готовы рекомендовать Deckhouse как замену upstream Kubernetes для всех подряд - слишком разные контексты. Но для клиентов, которым нужен отечественный продукт в реестре Минцифры, с понятным жизненным циклом поддержки и без желания собирать стек мониторинга с нуля, разговор стал предметным. Лето 2023-го - это ещё не момент, когда можно сказать «берём в продакшн без оговорок». Но это уже не экзотика, за которой нужно следить издалека.

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