В больших инфраструктурах 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 | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|
v7.4.0 | v2.10 | v2.7.2 | v1.72 |
Краткий обзор платформ
В сравнении участвовали четыре российских решения – Nova Container Platform (Orion soft), «Штурвал» («Лаборатория Числитель»), «Боцман» («Группа Астра»), Deckhouse Kubernetes Platform («Флант»). Все они решают одну и ту же базовую задачу, но разными способами и с разными предпосылками.
Таблица 1. Сравнение характеристик Kubernetes-платформ
Характеристика | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|---|
Версия K8s | 1.31.9 | 1.32.3 | 1.28.4 1.29.3 1.30.7 | 1.30–1.32 |
Управляющий кластер | да, с использованием Nova Cluster Manager | да | да | да, при использовании кластера с Deckhouse Commander |
Air-gapped установка | да | да | да | да |
Поддержка HA кластеров | да | да | да | да |
Поддержка Non-HA кластеров | да | да | да, начиная с версии 3.0 | да |
Тип etcd | stacked | stacked / external | stacked / external | stacked |
Импорт существующего кластера K8s | нет | не заявлен | не заявлен | не основной сценарий |
Управление через Web UI | да | да | да | да |
Управление через CLI | да | да | да | да |
Node pool / Node group | да | да | да | да |
Cordon / Uncordon | да | да | да | да |
Drain узлов | да | да | да | да |
CNI | Cilium / Calico | Cilium / Multus | Cilium | Cilium / Flannel |
NetworkPolicy | да | да | да | да |
Ingress controller | NGINX | NGINX | NGINX | NGINX |
LoadBalancer | нет | kube-vip | kube-vip | в облаках: LB от облачного провайдера или MetalLB |
Service Mesh | Istio | нет | Istio / Cillium Service Mesh | Istio |
CSI | LocalPV zVirt/oVirt | OpenEBS Rawfile LocalPV | LocalPV | LocalPV |
Volume snapshots | да | заявлены | да | модуль |
Encryption at rest | да | да | да | да |
Backup etcd | etcdctl | по инструкции | автоматический | встроен |
Backup ресурсов | Velero | Velero | Velero | да |
RBAC | да | да | да | да |
Admission control | Neuvector | Kyverno | Kyverno | Gatekeeper |
Image scanning | Neuvector | Trivy | Neuvector | Trivy |
Image signing | нет | Cosign | Cosign) | Cosign |
Метрики | Prometheus | VictoriaMetrics | Prometheus / VictoriaMetrics | Prometheus / Deckhouse Prom++ |
Логи | OpenSearch | VictoriaLogs | Loki / VictoriaMetrics Logs | log-shipper + Loki |
Трейсинг | Jaeger | нет | Jaeger | Jaeger |
GitOps | FluxCD | Argo CD | Fleet | Argo CD |
CI pipelines | нет | нет | с помощью GitFlic | С помощью Deckhouse Code |
Встроенный registry | Gitea | нет | с помощью GitFlic | да, на базе payload-registry и registry |
Различия между решениями начинаются с архитектуры и проявляются на уровне компонентов. Есть как заданные по умолчанию возможности, так и те, которые требуют дополнительной настройки. Посмотрим, как эти параметры реализованы в каждой платформе, в одном и том же формате, чтобы их можно было сопоставлять между собой. Начнём с первого этапа жизненного цикла кластера – установки и обновления.
Архитектура и базовая комплектация
Архитектура Kubernetes-платформы задает границы того, как с ней работать. Архитектурная модель показывает, есть ли у решения отдельный управляющий кластер, поддерживается ли мультикластерная схема или управление ограничено одним кластером. Это напрямую влияет на установку, обновления и масштабирование.
1. Базовая архитектура
Таблица 2. Архитектурная модель Kubernetes-платформ
Параметр | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|---|
Управляющий кластер | да, с использованием Nova Cluster Manager | да | да | да, при использовании кластера с Deckhouse Commander |
Мультикластерная модель | поддерживается | поддерживается | поддерживается | поддерживается |
Организация управления несколькими кластерами | да, с использованием Nova Cluster Manager | через управляющий кластер | через управляющий кластер | да, при использовании кластера с Deckhouse Commander |
Платформы с централизованной моделью управления, такие как «Штурвал» и «Боцман», ориентированы на сценарии с управлением несколькими 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-платформ
Компонент | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|---|
CNI | Cilium | Cilium | Cilium | Cilium |
Дополнительные CNI | Calico | Multus | Multus | Flannel |
Ingress controller | NGINX | NGINX | NGINX | NGINX |
Service Mesh | Istio | нет | Cilium Cluster Mesh / Istio | Istio |
GitOps | FluxCD | Argo CD | Fleet | Argo CD |
Мониторинг | Prometheus, Grafana | VictoriaMetrics, Grafana | Prometheus / VictoriaMetrics, Grafana | Prometheus / Deckhouse Kubernetes Platform Prom++, Grafana, Upmeter |
Логи | OpenSearch | Vector, VictoriaLogs | Loki / Victoria Logs | log-shipper + Loki |
Admission control | Neuvector | Kyverno | Kyverno | OPA Gatekeeper |
Image scanning | Neuvector | Trivy | Neuvector | Trivy |
CSI | LocalPV zVirt/oVirt | OpenEBS Rawfile LocalPV | LocalPV | LocalPV |
Основное различие Kubernetes-платформ по базовой комплектации заключается в том, кто принимает решения о стеке: платформа или команда.
Nova Container Platform и Deckhouse Kubernetes Platform сразу задают фиксированный набор ключевых компонентов: сеть, ingress, GitOps, мониторинг и безопасность. После установки кластер работает в конкретном стеке, а любые изменения требуют ручной донастройки. Плюс такого подхода в том, что на старте почти не нужно принимать архитектурные решения и проще получить воспроизводимую конфигурацию. Минус же состоит в том, что платформы жестко ограничивают выбор инструментов. Если в команде уже есть устоявшийся стек или особые требования, его интеграция потребует обходных решений или отказа от части возможностей платформы.
У «Штурвала» и «Боцмана» базовые компоненты заданы, но часть функциональности, например GitOps, безопасность или резервное копирование, подключается отдельно или настраивается модульно.
С практической точки зрения выбор сводится к компромиссу между скоростью старта и гибкостью. Для всех платформ предусмотрен набор как базовых, так и факультативных функций. Сама платформа выбор не ограничивает, однако чем больше решений принимает платформа – тем проще начать эксплуатацию, но при этом сужается спектр возможностей в выборе стека. Если больше решений остаётся за командой, это, с одной стороны, повышает гибкость, а с другой – увеличивает нагрузку на DevOps и сопровождение.
Установка и обновления
Здесь нас в первую очередь интересует типовой процесс: сколько шагов требуется для установки, где участвует человек, какие ограничения накладывает выбранная модель.
Таблица 4. Параметры установки и обновления Kubernetes-платформ
Параметр | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|---|
Инструмент установки | CLI: nova-ctl | CLI: stc | CLI: bootsmanctl | CLI: dhctl GUI: WebUI установщик / Deckhouse Kubernetes Platform Commander |
Способ установки | контейнер с SSH-доступом к узлам | управляющий кластер, затем пользовательские кластеры | установка управляющего кластера через CLI и последующие установки пользовательских кластеров через CLI/UI | установка компонентов в Kubernetes-кластер |
Управляющий кластер | да, с использованием Nova Cluster Manager | да | да | да, при использовании кластера с Deckhouse Commander |
Поддержка HA | да | да | да | да |
Non-HA кластеры | да | да | да, начиная с версии 3.0 | да |
Тип etcd | stacked | stacked / external | stacked / external | stacked |
Air-gapped установка | да | да | да | да |
Обновление платформы | да | да | да | да |
Обновление Kubernetes | да | да | да | да |
Способ обновления | через nova-ctl | CLI и Web UI | CLI и Web UI | механизм обновлений Deckhouse |
Автоматизация обновлений | не заявлена | не заявлена | не заявлена | да |
Откат обновлений | не заявлен | не заявлен | не заявлен | да |
В «Штурвал» и «Боцман» сначала устанавливается управляющий кластер. Через него создаются и обновляются Kubernetes-кластеры в заданной последовательности. Это добавляет отдельный этап установки, но позволяет централизованно управлять жизненным циклом нескольких кластеров.
В Nova Container Platform и Deckhouse Kubernetes Platform управляющий кластер опционален. Установка и обновление могу выполняться внутри каждого Kubernetes-кластера и опционально через внешний слой управления.
При выборе платформы важно заранее продумать организацию процессов. Платформы с управляющим кластером подходят, когда обновления и изменения должны проходить по единому сценарию, под централизованным контролем. Это часто встречается в крупных компаниях, инфраструктурных провайдерах, финтехе, госсекторе и корпоративных средах с жёсткими требованиями к контролю и воспроизводимости.
Управление кластерами и узлами
Различия в управлении кластерами и узлами между Kubernetes-платформами напрямую определяют, кто и как выполняет повседневные операции.
Управление кластерами
Таблица 5. Параметры управления кластерами Kubernetes-платформ
Параметр | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|---|
Создание Kubernetes-кластера | да, с использованием Nova Cluster Manager | да | да |
|
Управление одним кластером | да | да | да | да |
Управление несколькими кластерами | да, с использованием Nova Cluster Manager | да | да | да, при использовании кластера с Deckhouse Commander |
Импорт существующего кластера | не заявлен | не заявлен | не заявлен | не является основным сценарием |
Обновление Kubernetes-кластера | да | да | да | да |
Управление версиями Kubernetes | не заявлено | да | да | да |
Управление через Web UI | да | да | да | да |
Управление через CLI | да | да | да | да |
Управление узлами
В этом подблоке фиксируем, какие операции с узлами Kubernetes-кластера поддерживаются средствами платформы. Рассматриваем только управление узлами, без операций на уровне кластера.
Таблица 6. Параметры управления узлами Kubernetes-платформ
Параметр | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
Добавление узлов | да | да | да | да |
Удаление узлов | да | да | да | да |
Управление через Web UI | да | да | да | да |
Управление через CLI | да | да | да | да |
Cordon и Uncordon | да | да | да | да |
Drain узлов | да | да | да | да |
Node pool или node group | да | да | да | да |
Автоматическое восстановление узлов | не заявлено | да | да | да |
Автоматическое масштабирование узлов | не заявлено | да | да | да |
Nova Container Platform и Deckhouse Kubernetes Platform ориентированы на работу с отдельным кластером. Управление узлами происходит внутри каждого кластера, без внешнего уровня координации. Такой подход выбирают команды, которые хотят минимизировать количество управляющих сущностей в инфраструктуре и обслуживать кластеры независимо.
«Штурвал» и «Боцман» ориентированы на централизованное управление кластерами и узлами через управляющий слой. Создание кластеров, добавление и обслуживание узлов, а также масштабирование выполняются из одной точки. Этот вариант подходит компаниям, где требуется снижать вариативность конфигураций и объём ручных действий.
Отдельно стоит отметить, что «Штурвал», «Боцман» и Deckhouse Kubernetes Platform предоставляют механизмы автоматизации работы с узлами, включая восстановление и масштабирование.
В остальном вывод совпадает с предыдущим разделом, но проявляется уже на уровне повседневной эксплуатации.
Сеть и ingress
Таблица 7. Сетевой стек Kubernetes-платформ
Параметр | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|---|
CNI | Cilium | Cilium | Cilium | Cilium |
Дополнительные CNI | Calico | – | – | Flannel |
Поддержка NetworkPolicy | да | да | да | да |
Ingress controller | NGINX | NGINX | NGINX | NGINX |
Gateway API | – | – | – | – |
LoadBalancer | отсутствует | kube-vip | kube-vip, Termidesk Connect | в облаках: LB от облачного провайдера или MetalLB |
Service Mesh | Istio | не заявлено | Cilium ClusterMesh, Istio | Istio |
Поддержка mTLS | да | да | да | да |
Nova Container Platform, «Штурвал», «Боцман» и Deckhouse Kubernetes Platform используют Cilium как базовый CNI и NGINX в качестве ingress-контроллера. Сетевой стек в этих платформах относительно прямолинейный и опирается на хорошо знакомые компоненты. При этом:
в Nova Container Platform отсутствует встроенный LoadBalancer, требуется его обеспечивать на уровне инфраструктуры;
в «Штурвале» и «Боцмане» эту задачу решает kube-vip.
Такой вариант удобен для команд, которые хотят простой и предсказуемый сетевой стек и готовы решать часть сетевых задач вне платформы.
Хранилище и резервное копирование
Различия в хранилище и резервном копировании между Kubernetes-платформами определяют, кто отвечает за надёжность данных и DR-сценарии.
Таблица 8. Параметры хранения данных и резервного копирования Kubernetes-платформ
Параметр | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|---|
CSI | LocalPV zVirt/oVirt | OpenEBS Rawfile LocalPV | LocalPV | LocalPV |
Volume snapshots | да | да | да | да |
Encryption at rest | да | да | да | да |
Backup etcd | встроен | встроен | встроен | встроен |
Backup Kubernetes-ресурсов и volumes | Velero | Velero | Velero | да |
CSI здесь можно разделить на три группы:
локальное хранение;
программно-определяемое хранение;
внешнее хранение:
предоставляемое облаками/системами виртуализации;
внешние системы хранения (аппаратные и программно-определяемые).
Локальное хранение подразумевает, что данные хранятся на узле кластера и не обеспечивают отказоустойчивость, масштабирование и репликацию данных. Такое хранение способны обеспечивать все платформы.
Программно-определяемое хранение уже покрывает продвинутые функции: обеспечивает отказоустойчивость, масштабирование и репликацию данных, а также позволяет строить гиперковергентные K8s-кластеры. В Nova Container Platform и «Боцмане» для этого есть Longhorn, в Deckhouse Kubernetes Platform - DRBD.
Внешнее хранилище используется для облака, системы виртуализации, внешней СХД в инфраструктуре, где задачу обеспечения отказоустойчивости, и масштабирования и репликации данных берет на себя внешний провайдер или система. Все представленные платформы позволяют использовать внешние хранилища.
Безопасность и политики доступа
Отличия в механизмах безопасности между Kubernetes-платформами определяют, какую часть контроля над политиками и supply chain берёт на себя платформа, а какой блок работы остается на стороне команды.
Таблица 9. Параметры безопасности и политики доступа Kubernetes-платформ
Параметр | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
Аутентификация и доступ | OIDC, LDAP, AD + Kubernetes RBAC | OIDC, LDAP, AD + Kubernetes RBAC | OIDC, LDAP, AD + Kubernetes RBAC | OIDC, LDAP, AD + Kubernetes RBAC |
Каталог ролей | да | да | да | да |
Admission control | Neuvector | Kyverno | Kyverno | OPA Gatekeeper |
Проверка контейнерных образов | Neuvector | Trivy | Neuvector | Trivy |
Подпись образов | Cosign | Cosign | Cosign | Cosign |
Pod Security Standards | не заявлены | да | да | да |
PKI, управление сертификатами | Cert Manager | Cert Manager | Cert Manager | Cert Manager |
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 | VictoriaMetrics | Prometheus / VictoriaMetrics | Prometheus / Deckhouse Prom++ |
Визуализация | Grafana | Grafana | Grafana | Grafana |
Преднастроенные дашборды | да | да | да | да |
Алертинг | да | да | да | да |
Логи | OpenSearch | Vector, VictoriaLogs | Loki / Victoria Logs | log-shipper + Loki |
Трассировка | Jaeger | не заявлена | Jaeger | Jaeger |
Аудит событий | поддерживается в UI | поддерживается в UI | поддерживается в UI | поддерживается в UI |
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 | FluxCD | Argo CD | С помощью Fleet + GitFlic | Argo CD |
CI pipelines | не встроены | не встроены | С помощью GitFlic | с помощью Deckhouse Code |
Container registry | Gitea Registry | не встроен | С помощью GitFlic | да, на базе payload-registry и registry |
Nova Container Platform, «Штурвал», «Боцман» и Deckhouse Kubernetes Platform фактически ограничиваются GitOps. Платформа предоставляет или поддерживает конкретный инструмент управления декларативными конфигурациями, но не вмешивается в CI-процессы. Сборка, тестирование и доставка образов остаются за внешними системами. Это подходит командам, у которых CI/CD уже выстроен и стандартизирован, и от платформы требуется только надёжное применение изменений в кластере.
Ни одна из платформ не декларирует CI-модель. Они сознательно ограничиваются уровнем GitOps и оставляют delivery-пайплайны вне своей зоны ответственности.
Мультитенантность
Различия в мультитенантности между Kubernetes-платформами определяют, для кого предназначена платформа как среда эксплуатации: для одной команды или для множества независимых команд и сервисов.
Таблица 12. Параметры мультитенантности Kubernetes-платформ
Параметр | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
|---|---|---|---|---|
Отдельная сущность tenant / project | нет | tenant | project | project |
Иерархия сущностей мультитенантности | namespaces | tenant → namespace | project → namespace | project |
Квоты ресурсов | стандартные механизмы Kubernetes | поддерживаются | поддерживаются | поддерживаются |
Изоляция сетевых политик | через CNI | поддерживается | поддерживаются | поддерживаются |
Управление пользователями и ролями через UI | да | да | да | да |
Nova Container Platform ориентирована на одиночные команды и отдельные кластеры. Изоляция строится на стандартных механизмах Kubernetes через namespaces и RBAC. Такой вариант подходит, когда кластер обслуживает одну команду или несколько тесно связанных сервисов, а арендаторам не требуется отдельный уровень управления.
В «Штурвал», «Боцман» и Deckhouse Kubernetes Platform есть отдельная сущность tenant или project, через которую настраиваются доступы, квоты и изоляция. Это позволяет использовать один кластер как общую платформу для нескольких команд или подразделений.
Все платформы ориентированы на сценарии, где мультитенантность тесно связана с централизованным управлением и политиками. Это вариант подходит для внутренних платформ, где важно единообразие и контроль.
Сводная матрица различий Kubernetes-платформ
Мы собрали ключевые архитектурные и операционные различия, которые напрямую влияют на модель эксплуатации. Каждая строка отражает отдельную ось выбора: как организовано управление, где проходит граница ответственности между платформой и командой, какие решения платформа принимает за пользователя, а какие оставляет на его стороне.
Матрицу удобнее читать по колонкам. Каждая из них описывает характер платформы и класс задач, под который изначально рассчитана.
Таблица 13. Сводная матрица различий Kubernetes-платформ
Возможность | Nova Container Platform | «Штурвал» | «Боцман» | Deckhouse Kubernetes Platform |
Архитектурная модель управления | локальная / централизованная | централизованная | централизованная | локальная / централизованная |
Управляющий кластер | да, с использованием Nova Cluster Manager | да | да | да, при использовании кластера с Deckhouse Kubernetes Platform Commander |
Мультикластер | да | да | да | да |
Подход к формированию стека компонентов | фиксированный | фиксированный | частично фиксированный | модульный, управляемый платформой |
Работа с хранилищем | встроенное / внешнее | встроенное / внешнее | встроенное / внешнее | встроенное / внешнее |
Резервное копирование | да | да | да | да |
DR | на базе Multicluster и DR CSI | на базе Multicluster и DR CSI | на базе Multicluster и DR CSI | на базе Multicluster и DR CSI |
Политики безопасности | да | да | да | да |
Роль платформы в delivery | GitOps | GitOps | GitOps + SDLC + SSDLC | GitOps |
Мультитенантность как базовая модель | Нет | да | да | да |
Вывод
Выбор Kubernetes-платформы – это выбор не технологии, а операционной модели, с которой команде предстоит жить несколько лет. Поэтому мы старались дать максимально объективную картину, чтобы было проще понять, какая из платформ ближе к вашим процессам и ограничениям.
Различия между решениями лежат не столько в наборе компонентов, сколько в том, как эти компоненты собраны и какую модель эксплуатации задают. Именно это определяет, в каких сценариях и кейсах платформа берёт ответственность на себя, а какие оставляет команде, и как со временем это будет ощущаться при эксплуатации.
