Российская платформа контейнеризации «Боцман»

Разговор про импортозамещение в контейнерах обычно упирается в один вопрос: чем закрыть управление кластерами Kubernetes, если часть зарубежных сервисов недоступна, а контур должен оставаться закрытым. Платформа контейнеризации «Боцман» — один из ответов на него: решение для управления несколькими кластерами Kubernetes из единой панели, которое разрабатывает ООО «Платформа Боцман», входящее в «Группу Астра» с 2024 года. Продукт на рынке с 2016 года и внесён в реестр Минцифры.

Продукт на рынке с 2016 года, и продаётся он не лицензией как таковой, а сопровождением: панель для мультикластерной инфраструктуры, каталог готовых приложений, модульная сборка. Дальше — интеграции: российские СУБД, центры сертификации, системы защиты контейнеров. И сертификация ФСТЭК для контуров, где без неё не подпишут.

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

Платформа контейнеризации «Боцман»: что она делает поверх Kubernetes

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

Отдельный слой — наблюдаемость и доступ. Централизованный сбор логов, аудит событий, включая вход через SSO, аутентификация через LDAP и единый вход, гранулярные права по RBAC. В крупной распределённой команде это заметнее, чем любые бенчмарки: инженер заходит с рабочей станции и с планшета, служба ИБ видит, кто и когда менял настройки, а не собирает выписки из пяти систем.

Поставка модульная: базовые компоненты ставятся сразу, остальное подключается по необходимости. В списке доступных модулей — хранилище (Longhorn, Ceph, vSphere CSI), мониторинг на VictoriaMetrics и Grafana, сбор логов через Victoria Logs, оповещения Alertmanager, Ingress-контроллер и Kube-VIP, утилиты вроде Keda, Kyverno и Cert-Manager, резервное копирование Velero. Лишнее отключается, и это не маркетинговая деталь: каждый поднятый модуль потребляет память и расширяет поверхность атаки.

Платформа контейнеризации «Боцман» — российское решение для управления кластерами Kubernetes: развёртывание, обновление, масштабирование и мониторинг контейнерных приложений из общей панели. Разворачивается на своём железе, в облаке и в изолированном контуре. Для задач машинного обучения есть поддержка GPU, а версия SE получила сертификат ФСТЭК.

Чем платформа отличается от «голого» Kubernetes

На одном кластере разница не видна. Собранный руками стек из мониторинга, логирования, хранилища и ролевой модели справляется, и вопрос «зачем платформа» не звучит вовсе. На третьем-четвёртом кластере — в другом ЦОД, в другом облаке — начинается ручная синхронизация версий и охота за инцидентом по логам пяти систем. Здесь платформа и окупается.

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

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

EE или SE: как выбрать редакцию

Критерий	EE (Enterprise Edition)	SE (ФСТЭК-версия)
Для кого	Компании без жёстких нормативных требований	КИИ, ГИС, АСУ ТП, системы с персональными данными
Подтверждающие документы	Реестр Минцифры, запись № 21339 от 08.02.2024	Сертификат ФСТЭК № 5009 от 09.12.2025
Акцент	Гибкость, производительность, максимум интеграций	Соответствие требованиям регулятора
Стоимость	По запросу	По запросу

Функции в редакциях совпадают, разница только в документах. Если в контуре есть ГИС, объект КИИ или обработка персональных данных, сертификат придётся предъявлять проверяющим, и разговор сразу идёт про SE. Внутренней платформе разработки такие документы не нужны: там ограничения сертифицированной сборки только мешают.

До подписания имеет смысл спросить, как в сертифицированной версии выходят обновления безопасности и насколько они отстают от обычной сборки. Ответ предсказуем: при 4-м классе защиты состав проверенных версий фиксирован, поэтому скорость закрытия уязвимости задаёт процедура, а не желание команды. На презентациях об этом не говорят. А именно от этого зависит, что произойдёт при критичной уязвимости в базовом образе.

Где разворачивают и с какими системами это уже проверено

Сценарии развёртывания не ограничены одним типом площадки: физические серверы, гипервизоры, облака вроде VK Cloud и Yandex Cloud, а также изолированные сегменты без выхода во внешнюю сеть. Продуктивный контур при этом обычно остаётся в своём ЦОД, а тестовый уезжает в облако. Управлять обоими хочется из одной панели — на этом гибридность и держится.

Внутри экосистемы «Группы Астра» связки предсказуемы: Astra Linux как ОС, Tantor Postgres как СУБД, GitFlic для разработки, Astra Automation для ИТ-операций, Termidesk для доступа. Меньше проверок на совместимость на старте.

За пределами экосистемы проверки тоже проведены, и это важнее длины списка. С Directum RX и «Контур.Налоговым мониторингом» стыковка подтверждена сертификатами, причём последний поставляется готовым контейнером и разворачивается за несколько часов вместо ручной настройки серверов. Для аутентификации — Blitz Identity Provider и «Центр управления пользователями» от АТ Консалтинг. Отдельная линия — безопасность: SafeTech CA выпускает корпоративные сертификаты и включает mTLS, R-Vision VM берёт на себя управление уязвимостями, Luntry и PT Container Security закрывают защиту контейнеров.

Сколько стоит и сколько занимает внедрение

Цены на сайте нет: у обеих редакций стоит «по запросу», а метрику лицензирования — узлы, ядра или кластеры — обсуждают уже на проекте.

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

Приоритет инцидента	Реакция поддержки	Обходное решение
Критичный	до 15 минут	до 8 часов
Срочный	до 60 минут	следующий день
Обычный	до 60 минут	два рабочих дня
Консультация	до 60 минут	не применяется

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

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

Что обычно идёт не так при переезде в контейнеры

Ошибки на проектах повторяются, и почти все они не про продукт, а про порядок работ.

• Ожидание, что платформа контейнеризует приложения сама. Обнаруживается на этапе планирования миграции, когда выясняется, что половина сервисов хранит состояние на локальном диске.
• Неправильно выбранная редакция. Если сертифицированный контур требуется по требованиям, а проект стартовал на EE, придётся менять версию и повторно проходить приёмку.
• Модули «на всякий случай». Чем больше компонентов включено, тем сложнее обновления и шире поверхность атаки; модульность существует ровно для того, чтобы её использовали.
• Хранилище оставлено «на потом». Без распределённого хранилища состояние подов теряется при перезапуске узла, а выбор между Longhorn, Ceph и CSI-драйвером СХД лучше делать до нагрузки, а не после.
• Доступ и аудит настраивают после инцидента. В сертифицированных контурах ролевая модель, SSO и журналирование событий — часть проверки, а не косметика.
• Команда не знает Kubernetes. Панель снижает порог входа, но не отменяет понимания подов, сетевых политик и лимитов ресурсов — без этого эксплуатация упирается в первые же нестандартные ситуации.

Когда платформа контейнеризации не нужна

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

Не решит такая платформа и другой задачи: там, где нужны виртуальные машины, а не контейнеры, вопрос закрывается средствами виртуализации, и подмена одного другим оборачивается переписыванием приложений без выгоды. Не подойдёт она и в роли managed-сервиса «поставил и забыл»: эксплуатация кластеров, обновления и разбор инцидентов остаются на стороне заказчика, а поддержка вендора решает проблемы платформы, а не приложений.

На что смотреть перед пилотом

Перед демонстрацией стоит ответить на несколько вопросов — они экономят больше времени, чем любое сравнение по функциям.

• Есть ли в контуре требования ФСТЭК, признаки КИИ или ГИС — от этого зависит редакция.
• Сколько кластеров предстоит обслуживать и где они находятся, включая изолированные сегменты.
• Какие СХД и хранилища уже используются и совместимы ли они с модулями платформы.
• Как организованы аутентификация и права: LDAP, SSO, требования службы ИБ к аудиту.
• Есть ли GPU-нагрузки и планируется ли деление ускорителей между командами.
• Кто будет эксплуатировать: достаточно ли компетенций или нужны курсы и сертификация персонала.

С чего начинать пилот, если решение уже выбрано

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

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

Технически площадка покажет, что умеет. Исход определят готовность приложений к контейнерам и порядок в контуре: если с этим плохо, платформа добавит ещё один слой, который придётся сопровождать.

Подробнее о платформе контейнеризации.