В больших инфраструктурах Kubernetes не живёт сам по себе: вокруг него выстраивается экосистема со своими дефолтами, ограничениями и точками отказа. В нее входят CNI, ingress-контроллеры, системы мониторинга, бэкапов, политики безопасности, GitOps и десятки других компонентов.

Поэтому у вас всегда есть выбор. Взять ванильный Kubernetes и вручную прикрутить к нему нужные инструменты или использовать готовое решение от вендора. Формально и там, и там в основе лежит одно и то же кубовое API, но на практике различия начинаются уже на этапе установки.

Инженеры практики контейнеризации К2Тех изучили особенности эксплуатации четырех российских платформ: «Штурвал», Nova Container Platform, «Боцман», Deckhouse Kubernetes Platform. Результаты сравнения разложили по полочкам в таблицах – их вы найдете в статье.

Как мы сравнивали платформы

В статье использованы результаты практического тестирования платформ. Мы сознательно не сравнивали маркетинговые заявления и не рассматривали все возможные конфигурации, а фокусировались на типовых сценариях эксплуатации.

Методология

За основу мы взяли типовой жизненный цикл production-кластера. Для каждой из четырех платформ рассматривали одинаковый набор факторов:

• установка и обновление,

• управление кластерами и узлами,

• сеть и ingress (ресурс, который определяет правила маршрутизации внешнего трафика для кластера),

• хранение данных и резервное копирование,

• безопасность и политики доступа,

• наблюдаемость,

• CI/CD и GitOps,

• операции второго этапа и удобство администрирования.

Все решения оценивались в сопоставимых сценариях. Нас интересовало не просто наличие фичи, а встроена ли она в платформу, включена ли по умолчанию, как настраивается и насколько удобна в повседневной работе.

За точку отсчёта взяли стандартный Kubernetes без дополнительных надстроек. Это позволило отделить особенности конкретного решения от возможностей платформы «из коробки».

Мы не искали «лучшую» Kubernetes-платформу, а показали реальные отличия между решениями.

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

Краткий обзор платформ

В сравнении участвовали четыре российских решения – Nova Container Platform (Orion soft), «Штурвал» («Лаборатория Числитель»), «Боцман» («Группа Астра»), Deckhouse Kubernetes Platform («Флант»). Все они решают одну и ту же базовую задачу, но разными способами и с разными предпосылками.

Таблица 1. Сравнение характеристик Kubernetes-платформ

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

Архитектура и базовая комплектация

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

1. Базовая архитектура

Таблица 2. Архитектурная модель Kubernetes-платформ

Платформы с централизованной моделью управления, такие как «Штурвал» и «Боцман», ориентированы на сценарии с управлением несколькими Kubernetes-кластерами из единого контура. Такая архитектура подходит для инфраструктур с несколькими окружениями, регионами или площадками, где важны единые политики и единый процесс управления.

Однако подходы внутри этой группы различаются. «Штурвал» использует выделенный управляющий Kubernetes-кластер, тогда как «Боцман» опирается на управляющий инфраструктурный кластер и не выделяет отдельный Kubernetes-кластер как самостоятельную сущность.

В Nova Container Platform и Deckhouse Kubernetes Platform управление Kubernetes-кластерами вынесено в отдельный управляющий K8s-кластер. В Deckhouse Kubernetes Platform централизованное управление реализовано за счет отдельного компонента Deckhouse Commander, который входит в состав некоторых редакций DKP или может быть лицензирован как отдельный самостоятельный продукт. У Nova Container Platform с версии 7.4 появился Cluster Manager для аналогичного функционала.

Таким образом, архитектурные различия определяют не качество платформы, а тип задач, под которые она предназначена.

2. Что входит в поставку по умолчанию

Зафиксируем, какие компоненты входят в стандартную поставку Kubernetes-платформы, а какие – требуют отдельного подключения.

Таблица 3. Стандартные компоненты Kubernetes-платформ

Основное различие Kubernetes-платформ по базовой комплектации заключается в том, кто принимает решения о стеке: платформа или команда.

Nova Container Platform и Deckhouse Kubernetes Platform сразу задают фиксированный набор ключевых компонентов: сеть, ingress, GitOps, мониторинг и безопасность. После установки кластер работает в конкретном стеке, а любые изменения требуют ручной донастройки. Плюс такого подхода в том, что на старте почти не нужно принимать архитектурные решения и проще получить воспроизводимую конфигурацию. Минус же состоит в том, что платформы жестко ограничивают выбор инструментов. Если в команде уже есть устоявшийся стек или особые требования, его интеграция потребует обходных решений или отказа от части возможностей платформы.

У «Штурвала» и «Боцмана» базовые компоненты заданы, но часть функциональности, например GitOps, безопасность или резервное копирование, подключается отдельно или настраивается модульно. 

С практической точки зрения выбор сводится к компромиссу между скоростью старта и гибкостью. Для всех платформ предусмотрен набор как базовых, так и факультативных функций. Сама платформа выбор не ограничивает, однако чем больше решений принимает платформа – тем проще начать эксплуатацию, но при этом сужается спектр возможностей в выборе стека. Если больше решений остаётся за командой, это, с одной стороны, повышает гибкость, а с другой – увеличивает нагрузку на DevOps и сопровождение.

Установка и обновления

Здесь нас в первую очередь интересует типовой процесс: сколько шагов требуется для установки, где участвует человек, какие ограничения накладывает выбранная модель.

Таблица 4. Параметры установки и обновления Kubernetes-платформ

В «Штурвал» и «Боцман» сначала устанавливается управляющий кластер. Через него создаются и обновляются Kubernetes-кластеры в заданной последовательности. Это добавляет отдельный этап установки, но позволяет централизованно управлять жизненным циклом нескольких кластеров.

В Nova Container Platform и Deckhouse Kubernetes Platform управляющий кластер опционален. Установка и обновление могу выполняться внутри каждого Kubernetes-кластера и опционально через внешний слой управления.

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

Управление кластерами и узлами

Различия в управлении кластерами и узлами между Kubernetes-платформами напрямую определяют, кто и как выполняет повседневные операции.

Управление кластерами

Таблица 5. Параметры управления кластерами Kubernetes-платформ

Управление узлами

В этом подблоке фиксируем, какие операции с узлами Kubernetes-кластера поддерживаются средствами платформы. Рассматриваем только управление узлами, без операций на уровне кластера.

Таблица 6. Параметры управления узлами Kubernetes-платформ

Nova Container Platform и Deckhouse Kubernetes Platform ориентированы на работу с отдельным кластером. Управление узлами происходит внутри каждого кластера, без внешнего уровня координации. Такой подход выбирают команды, которые хотят минимизировать количество управляющих сущностей в инфраструктуре и обслуживать кластеры независимо.

«Штурвал» и «Боцман» ориентированы на централизованное управление кластерами и узлами через управляющий слой. Создание кластеров, добавление и обслуживание узлов, а также масштабирование выполняются из одной точки. Этот вариант подходит компаниям, где требуется снижать вариативность конфигураций и объём ручных действий.

Отдельно стоит отметить, что «Штурвал», «Боцман» и Deckhouse Kubernetes Platform предоставляют механизмы автоматизации работы с узлами, включая восстановление и масштабирование.

В остальном вывод совпадает с предыдущим разделом, но проявляется уже на уровне повседневной эксплуатации.

Сеть и ingress

Таблица 7. Сетевой стек Kubernetes-платформ

Nova Container Platform, «Штурвал», «Боцман» и Deckhouse Kubernetes Platform используют Cilium как базовый CNI и NGINX в качестве ingress-контроллера. Сетевой стек в этих платформах относительно прямолинейный и опирается на хорошо знакомые компоненты. При этом:

• в Nova Container Platform отсутствует встроенный LoadBalancer, требуется его обеспечивать на уровне инфраструктуры;

• в «Штурвале» и «Боцмане» эту задачу решает kube-vip.

Такой вариант удобен для команд, которые хотят простой и предсказуемый сетевой стек и готовы решать часть сетевых задач вне платформы.

Хранилище и резервное копирование

Различия в хранилище и резервном копировании между Kubernetes-платформами определяют, кто отвечает за надёжность данных и DR-сценарии.

Таблица 8. Параметры хранения данных и резервного копирования Kubernetes-платформ

CSI здесь можно разделить на три группы:

• локальное хранение;

• программно-определяемое хранение;

• внешнее хранение:

  • предоставляемое облаками/системами виртуализации;

  • внешние системы хранения (аппаратные и программно-определяемые).

Локальное хранение подразумевает, что данные хранятся на узле кластера и не обеспечивают отказоустойчивость, масштабирование и репликацию данных. Такое хранение способны обеспечивать все платформы.

Программно-определяемое хранение уже покрывает продвинутые функции: обеспечивает отказоустойчивость, масштабирование и репликацию данных, а также позволяет строить гиперковергентные K8s-кластеры. В Nova Container Platform и «Боцмане» для этого есть Longhorn, в Deckhouse Kubernetes Platform - DRBD.

Внешнее хранилище используется для облака, системы виртуализации, внешней СХД в инфраструктуре, где задачу обеспечения отказоустойчивости,  и масштабирования и репликации данных берет на себя внешний провайдер или система. Все представленные платформы позволяют использовать внешние хранилища.

Безопасность и политики доступа

Отличия в механизмах безопасности между Kubernetes-платформами определяют, какую часть контроля над политиками и supply chain берёт на себя платформа, а какой блок работы остается на стороне команды.

Таблица 9. Параметры безопасности и политики доступа Kubernetes-платформ

Nova Container Platform ориентирована на базовый контур безопасности через RBAC и Neuvector. Контроль образов и admission реализованы, но платформа почти не вмешивается в процессы разработки и доставки. Такой вариант подходит для сценариев, где безопасность контейнеров важна, но команда предпочитает выстраивать политики и правила самостоятельно.

«Штурвал» и Deckhouse Kubernetes Platform изначально делают упор на подход, определяемый политиками/правилами. В обоих решениях есть admission control, поддержка подписей образов и Pod Security Standards. Это удобно в средах, где безопасность формализована в виде правил и проверок, а нарушения должны автоматически отсекаться в момент запуска.

«Боцман» занимает промежуточную позицию. Механизмы политик и подписей доступны, но не являются обязательной частью установки. Такой подход выбирают команды, которым нужен контроль, но без жёсткого навязывания политик со стороны платформы.

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

Наблюдаемость

Различия в наблюдаемости между Kubernetes-платформами показывают, насколько платформа стремится закрыть полный цикл наблюдения сама и сколько решений остаётся на стороне команды.

Таблица 10. Параметры наблюдаемости Kubernetes-платформ

Nova Container Platform и Deckhouse Kubernetes Platform поставляются с классическим стеком Prometheus + Grafana и поддержкой трассировки через Istio. Это обеспечивает предсказуемый и хорошо знакомый многим набор инструментов, который легко интегрируется в существующие процессы мониторинга. Такой вариант удобен, если в компании уже есть опыт работы с Prometheus-экосистемой, и не требуется переучивать команды.

«Штурвал» делает ставку на VictoriaMetrics как основное хранилище метрик и используют связку Vector плюс внешние системы логирования. Это лучше подходит для сред с большим объёмом метрик и логов, где важна эффективность хранения и масштабируемость. При этом трассировка либо отсутствует по умолчанию, либо требует отдельного включения, и этот контур нужно продумывать заранее.

«Боцман» занимает промежуточную позицию. Он допускает использование разных систем метрик и логов и поддерживает трассировку через Istio. Это позволяет подстроиться под существующий стек, но требует, чтобы команды самостоятельно определяли, какие инструменты использовать и как связать их между собой.

CI/CD и GitOps

Посмотрим какие платформы ограничиваются GitOps-моделью, а какие пытаются закрыть весь delivery-контур.

Таблица 11. Параметры CI/CD и GitOps Kubernetes-платформ

Nova Container Platform, «Штурвал», «Боцман» и Deckhouse Kubernetes Platform фактически ограничиваются GitOps. Платформа предоставляет или поддерживает конкретный инструмент управления декларативными конфигурациями, но не вмешивается в CI-процессы. Сборка, тестирование и доставка образов остаются за внешними системами. Это подходит командам, у которых CI/CD уже выстроен и стандартизирован, и от платформы требуется только надёжное применение изменений в кластере.

Ни одна из платформ не декларирует CI-модель. Они сознательно ограничиваются уровнем GitOps и оставляют delivery-пайплайны вне своей зоны ответственности.

Мультитенантность

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

Таблица 12. Параметры мультитенантности Kubernetes-платформ

Nova Container Platform ориентирована на одиночные команды и отдельные кластеры. Изоляция строится на стандартных механизмах Kubernetes через namespaces и RBAC. Такой вариант подходит, когда кластер обслуживает одну команду или несколько тесно связанных сервисов, а арендаторам не требуется отдельный уровень управления.

В «Штурвал», «Боцман» и Deckhouse Kubernetes Platform есть отдельная сущность tenant или project, через которую настраиваются доступы, квоты и изоляция. Это позволяет использовать один кластер как общую платформу для нескольких команд или подразделений.

Все платформы ориентированы на сценарии, где мультитенантность тесно связана с централизованным управлением и политиками. Это вариант подходит для внутренних платформ, где важно единообразие и контроль.

Сводная матрица различий Kubernetes-платформ

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

Матрицу удобнее читать по колонкам. Каждая из них описывает характер платформы и класс задач, под который изначально рассчитана.

Таблица 13. Сводная матрица различий Kubernetes-платформ

Вывод

Выбор Kubernetes-платформы – это выбор не технологии, а операционной модели, с которой команде предстоит жить несколько лет. Поэтому мы старались дать максимально объективную картину, чтобы было проще понять, какая из платформ ближе к вашим процессам и ограничениям.

Различия между решениями лежат не столько в наборе компонентов, сколько в том, как эти компоненты собраны и какую модель эксплуатации задают. Именно это определяет, в каких сценариях и кейсах платформа берёт ответственность на себя, а какие оставляет команде, и как со временем это будет ощущаться при эксплуатации.