Обзор Deckhouse Virtualization Platform 1.10: замена VMware и управление ВМ в единой среде

...

Обзор Deckhouse Virtualization Platform 1.10, системы для управления ВМ и контейнерами в одной среде

Deckhouse Virtualization Platform — решение для виртуализации, позволяющее как управлять ВМ через веб-интерфейс, так и полностью автоматизировать их жизненный цикл за счёт открытого API. Отдельные редакции позволяют запускать контейнеры вместе с ВМ в одной среде для запуска гибридных приложений.

Сертификат AM Test Lab

Номер сертификата: 582

Дата выдачи: 31.08.2026

Срок действия: 31.08.2031

Реестр сертифицированных продуктов »

1. Введение
2. Функциональные возможности Deckhouse Virtualization Platform 1.10
3. Архитектура Deckhouse Virtualization Platform 1.10
4. Лицензирование Deckhouse Virtualization Platform 1.10
5. Системные требования Deckhouse Virtualization Platform 1.10
6. Применение Deckhouse Virtualization Platform 1.10
7. Выводы

Введение

К 2026 году замена VMware vSphere и других зарубежных решений перестала быть только вопросом выбора платформы виртуализации. Для многих организаций это стало вопросом соответствия требованиям информационной безопасности (ИБ) и регуляторов. Помимо того, что пользователи больше не получают обновления и новые возможности, такие платформы:

не соответствуют требованиям регуляторов;
не имеют технической поддержки со стороны вендора;
не обеспечивают совместимость с российским оборудованием и программным обеспечением (ПО);
не развиваются с точки зрения безопасности.

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

Для решения задач виртуализации существует множество решений с открытым кодом, в том числе и для управления виртуальными машинами (ВМ) с помощью Kubernetes. Но такой подход имеет свою специфику. В этом случае необходимо собирать конструктор из отдельных компонентов для предоставления ресурсов хранения, сети, мониторинга и безопасности. Например, можно использовать ванильный KubeVirt для запуска ВМ в Kubernetes и оперировать базовыми абстракциями и ресурсами Kubernetes (CRD, PVC, снапшотами и так далее), что усложняет создание ВМ, управление ими и анализ проблем. Компания «Флант» упрощает этот процесс.

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

Их продукт Deckhouse Virtualization Platform (DVP) — безопасная альтернатива с современным подходом к управлению и мощными инструментами безопасности. Он предоставляет все функции, необходимые для работы виртуальных машин: отказоустойчивость, живую миграцию, поддержку различных типов хранилищ, мониторинг и др. Уникальность предложения — возможность запуска ВМ вместе с контейнерами в одной среде, что позволяет использовать единый подход к управлению и развёртыванию гибридных приложений. Распаковка платформы — по ссылке.

DVP зарегистрирована в реестре российского ПО (№ 24689 от 15.11.2024). DVP Certified Security Edition (CSE) имеет сертификат соответствия ФСТЭК России (№ 4860 от 04.10.2024).

Функциональные возможности Deckhouse Virtualization Platform 1.10

При выборе отечественных платформ виртуализации заказчики часто ожидают сохранения функциональности, привычной для таких решений, как VMware vSphere и ему подобных:

высокая доступность ВМ и управляющих компонентов (HA и vCenter HA);
живая миграция ВМ между узлами и хранилищами (vMotion и Storage vMotion);
возможность миграции ВМ между гипервизорами с разными моделями процессоров (EVC);
балансировка нагрузки гипервизоров (vSphere DRS);
возможность перевода гипервизоров в режим обслуживания (Maintenance);
гиперконвергентное хранилище (vSAN);
сетевые возможности (VLAN и виртуальные сети) и балансировка прикладной нагрузки;
возможности мультиарендности и квот на вычислительные ресурсы (IaaS) (отдельное решение, доступное для сервисных провайдеров, — VMware Cloud Director);
мониторинг и журналирование (отдельные решения Aria Operations и Log Insight) и так далее.

Рисунок 1. Схема работы Deckhouse Virtualization Platform 1.10

Виртуализация в Deckhouse обеспечивает функциональность, сопоставимую с их возможностями, при этом предлагает ряд функций, отсутствующих в этих системах:

Единая платформа для ВМ и контейнеров: общие политики размещения, микросегментация и управление через единый API и UI.
Декларативное управление ВМ без внешних инструментов.
DevOps-инструменты и практики для ВМ: IaC, GitOps, Helm, Argo CD для управления жизненным циклом.
Автоматизация типовых задач эксплуатации: образы ВМ, cloud-init, sysprep и Ansible для кастомизации и постконфигурации.
Централизованная наблюдаемость: мониторинг, события и журналы инфраструктуры, ВМ и приложений из одной точки.
Сквозная безопасность: единая модель RBAC, мультитенантность, сетевые политики, аудит изменений.
Учёт ресурсов и биллинг.
ИИ-ассистент для мониторинга, траблшутинга, управления ВМ и контейнерами.

Возможности платформы зависят от редакции. В этом обзоре мы рассмотрим функции DVP Enterprise Edition — редакции, включающей максимальный набор возможностей.

Развёртывание и настройка платформы

Deckhouse Virtualization Platform устанавливается на подготовленные серверы, после чего подключается внешнее аппаратное дисковое хранилище или настраивается программно-определяемое хранилище (Software-Defined Storage, SDS), доступное в составе платформы — в зависимости от архитектуры решения. Далее при необходимости выполняется настройка сетевого взаимодействия, политик безопасности и прав доступа. После завершения базовой настройки платформа может быть интегрирована с другими продуктами для расширения функциональности и реализации дополнительных сценариев эксплуатации.

Графический установщик предназначен для быстрого развёртывания и запускается локально на рабочем месте администратора. Он позволяет развернуть кластер для любых целей (виртуализация, контейнеризация, смешанные нагрузки) и в любом окружении, на физических серверах, ВМ или в облаке. После получения сертификата ФСТЭК России через установщик можно будет разворачивать и сертифицированную редакцию платформы. Сейчас это возможно только для тестирования.

На момент публикации обзора в графическом установщике реализованы следующие функции:

создание и настройка кластера Deckhouse;
поддержка облачных провайдеров (OpenStack, VK Cloud и др.);
автоподстановка данных из облака;
кросс-платформенный установщик;
установка DVP под ключ.

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

Рисунок 2. Разворачивание DVP через графический установщик

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

Графический установщик — это простой инструмент, который помогает пользователю выполнить базовую настройку и избежать ошибок при выборе конфигурации.

Подключение к DVP

Поддерживается интеграция с внешними провайдерами идентификации через OpenID Connect (OIDC). При необходимости доступ может быть дополнительно защищён двухфакторной аутентификацией.

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

Рисунок 3. Раздел «Система» в DVP 1.10

Рисунок 4. Раздел «Проекты» в DVP 1.10

Если проводить грубую аналогию, то платформу компании «Флант» можно воспринимать как связку VMware vSphere и VMware Cloud Director. Первая обеспечивает базовый слой виртуализации, а вторая отвечает за распределение вычислительных ресурсов между отдельными проектами (тенантами).

Ролевая модель доступа

Права доступа в DVP настраиваются с использованием стандартного подхода — управления доступом на основе ролей (Role-Based Access Control, RBAC), позволяющего администраторам чётко определять, кто и какие действия может выполнять в кластере: создавать, читать, изменять ресурсы и т. д.

В DVP предусмотрено два основных типа ролей:

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

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

Инструменты автоматизации

Поддерживается работа не только через веб-интерфейс, но и с применением инструментов автоматизации, применяемых в DevOps-практиках. Пользователи могут использовать инфраструктуру как код (Infrastructure as Code, IaC), встроенные в платформу Helm-чарты, Helm Operator, Argo CD и Ansible, а также самостоятельно добавлять собственные инструменты.

IaC позволяет описывать конфигурацию инфраструктурных объектов в виде YAML-манифестов. В них можно задать параметры ВМ, дисков и образов, сервисов, сертификатов, сетевых политик, Ingress-настроек, пространств имён и других компонентов. После применения манифестов платформа самостоятельно создаёт и настраивает необходимые ресурсы.

Рисунок 5. Пример YAML-манифеста

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

GitOps развивает этот подход, используя Git-репозиторий для хранения шаблонов и конфигураций инфраструктуры. Для этого в платформе используется Deckhouse Code — решение для непрерывной разработки и управления жизненным циклом ПО, где хранятся подготовленные репозитории с описаниями ресурсов и параметрами окружения.

В DVP имеется Helm Operator, который позволяет автоматически разворачивать отдельные виртуальные машины и целые приложения, подготовив Helm Chart. Используя подготовленные шаблоны и значения параметров, можно создавать все необходимые ресурсы ВМ в кластере. Argo CD отслеживает конфигурации ВМ, хранящиеся в Git, применяет их к кластеру и динамически отслеживает изменения конфигурации. Например, при случайном удалении ВМ она будет автоматически пересоздана по заданному шаблону.

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

Для типовых групп ВМ можно задавать правила автоскейлинга. Например, при увеличении нагрузки на фронтенд-серверы платформа автоматически создаёт дополнительные экземпляры ВМ, что позволяет сохранять работоспособность приложения при росте количества пользователей.

Включение и настройка виртуализации

Виртуализация в DVP реализована в виде отдельного модуля. После развёртывания кластера этот модуль необходимо включить и выполнить его первоначальную настройку.

Рисунок 6. Настройка модуля виртуализации

Во вкладке «Конфигурации» размещён пункт «Экспериментальные возможности», куда попадают новые функции. Перед их включением необходимо изучить документацию и ограничения. На момент публикации обзора туда вошла возможность изменения CPU и памяти без перезагрузки. В дальнейшем она будет переведена в основную функциональность платформы. Такой подход позволяет контролируемо внедрять новые возможности: сначала оценить их влияние, собрать обратную связь и только после этого делать их доступными для широкого использования.

Процесс создания виртуальной машины с точки зрения пользователя не отличается от любой другой платформы виртуализации. Веб-интерфейс предлагает знакомые шаги для создания ВМ: конфигурация процессора и памяти, диски, сети, правила размещения и первоначальная кастомизация с помощью cloud-init или sysprep и так далее.

Вся сложность спрятана под капотом. После описания ресурса VirtualMachine платформа сама выполняет все необходимые действия:

Для диска ВМ создаётся PVC; под-импортёр загружает образ из внешнего источника в хранилище.
Для запуска ВМ контроллер создаёт под на базе libvirt и QEMU.
В под пробрасывается доступ к /dev/kvm с узла (аппаратное ускорение). Сетевое подключение организуется через CNI (Cilium) по той же модели, что и для контейнеров.
Virt-launcher запускает ВМ, virt-handler на узле управляет ею и собирает диагностическую информацию.
Состояние синхронизируется с control plane. В статусе ресурса всегда видно текущее состояние машины.

Рисунок 7. Схема работы ВМ в Deckhouse Virtualization Platform

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

Платформа позволяет управлять образами, дисками, виртуальными машинами и другими ресурсами как через веб-интерфейс, так и с помощью командной строки (Command Line Interface, CLI). Для работы из командной строки используется утилита d8. Мы покажем работу DVP на примере веб-интерфейса.

Работа с образами

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

Кластерные. Создаются администратором инфраструктуры, иногда совместно с командой информационной безопасности. Доступны для всех проектов, соответствуют корпоративным требованиям и политикам безопасности.
Проектные. DVP позволяет пользователям создавать собственные образы в рамках проекта. Они будут изолированы и доступны только пользователям соответствующего проекта. Загрузить образы можно разными способами: по ссылке, из образа контейнера, с компьютера, с диска и т. д., а также напрямую из командной строки с использованием утилиты curl.

Рисунок 8. Кластерные образы

Поддерживаются следующие форматы образов с предустановленной системой: qcow2, vmdk, raw, vdi. Файлы образов могут быть сжаты одним из следующих алгоритмов: gz, xz.

Для загрузки образов ВМ и их последующего использования при создании виртуальных дисков используется ресурс VirtualImage, который доступен только в том проекте, где был создан. Для использования образов на уровне всего кластера предназначен отдельный ресурс — ClusterVirtualImage.

После настройки VirtualImage образ автоматически загружается из указанного источника в хранилище DVCR или PVC в зависимости от типа. Как только загрузка завершится, его можно использовать для создания виртуальных дисков.

Диски

Диски ВМ создаются на основе ресурсов PersistentVolume. Для управления ими и выделения дискового пространства в кластере должно быть развёрнуто одно или несколько поддерживаемых хранилищ: локальных или внешних — локальное sds-local-volume, встроенное реплицируемое sds-replicated-volume, Ceph-кластер, сетевая файловая система (Network File System, NFS) и др.

Например, встроенный модуль sds-replicated-volume позволяет создавать гиперконвергентное хранилище на базе физических дисков, установленных в узлах гипервизора, без обязательного подключения к внешним системам хранения данных (СХД). По функциональному назначению такой подход сопоставим с VMware vSAN, но реализован на другом технологическом стеке.

Подключение к внешним СХД реализовано через CSI-драйверы.

Рисунок 9. Конфигурация хранилищ

Сеть

Сетевой уровень Deckhouse Virtualization Platform 1.10 реализован на базе SDN-модуля, построенного с использованием Cilium. В основе решения используются технологии eBPF и драйверы, работающие на уровне ядра Linux, что позволяет обеспечить высокую производительность сетевых операций.

Рисунок 10. Конфигурация SDN

Для организации сетевого взаимодействия поддерживаются:

Виртуальные сети с автоматическим назначением IP-адресов.
Cluster-сети (кластерные сети, VLAN) для подключения виртуальных машин к существующей сетевой инфраструктуре. Они доступны для всех.
Network-классы (проектные сети), обеспечивающие сетевую изоляцию ресурсов отдельных проектов.
Underlay-сети обеспечивают прямое подключение физических сетевых интерфейсов (Physical Functions и Virtual Functions), их прямой проброс в ВМ. Пока эта функция доступна для подов и микросервисов. Для ВМ такая возможность находится в разработке и ожидается до конца 2026 года.
Системные сети для служебного трафика (миграция ВМ, взаимодействие с системой хранения данных и др.).

Для управления сетевым взаимодействием между компонентами используются стандартные сетевые политики Kubernetes, которые разделяются на два основных типа:

Входящий (Ingress) — управление входящими соединениями и определение, какие источники могут обращаться к ресурсу.
Исходящий (Egress) — управление исходящими соединениями и ограничение доступа ресурсов к внешним сервисам.

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

Виртуальные машины

Для создания виртуальной машины достаточно нажать «Создать» и выбрать пункт «Виртуальная машина». На первом этапе необходимо выбрать класс виртуальной машины.

Рисунок 11. Примеры классов ВМ

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

После выбора загрузочного диска или образа указываются основные характеристики ВМ.

Рисунок 12. Создание ВМ в веб-интерфейсе

Следующий этап — настройка сети. По умолчанию виртуальная машина подключается к сети Main — внутренней виртуальной сети платформы, которая автоматически назначает ВМ IP-адреса. Помимо внутренней сети поддерживается подключение к внешним физическим сетям. Для этого необходимо настроить соответствующие сетевые ресурсы, такие как ClusterNetwork и NetworkClass. При использовании физических сетей IP-адреса в текущей реализации назначаются вручную. В сети Main этот процесс полностью автоматизирован. В ближайших планах — довести функциональность управления адресами (IPAM) и до физических сетей.

При необходимости виртуальной машине можно назначить дополнительные сетевые интерфейсы или подключить USB-устройство. Например, это может понадобиться для использования аппаратного лицензионного ключа или USB-токена внутри гостевой операционной системы. В отличие от других платформ виртуализации, здесь реализована технология USB over IP. Благодаря этому USB-устройство не привязывает ВМ к конкретному узлу гипервизора. Виртуальная машина сохраняет возможность живой миграции даже при использовании подключённого USB-устройства.

Для первоначальной настройки ВМ используется cloud-init — стандартный многоплатформенный пакет, который позволяет автоматически настраивать ВМ, применяя конфигурацию, переданную через метаданные. Можно задать имя пользователя, пароль или публичный SSH-ключ. Если базовых параметров недостаточно, доступно редактирование полного cloud-config, что позволяет использовать все возможности cloud-init для автоматизации первоначальной настройки системы. Для ВМ на базе Windows поддерживается sysprep.

Рисунок 13. Редактирование cloud-config

Для управления размещением ВМ используются подходы: простое связывание по лейблам, предпочтительное связывание (Affinity), избежание совместного размещения (AntiAffinity).

Рисунок 14. Размещение ВМ

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

Рисунок 15. Список запущенных виртуальных машин

После создания виртуальной машины её конфигурацию можно просмотреть в виде YAML-файла. Он содержит все основные параметры ВМ: имя, характеристики вычислительных ресурсов и т. д. Фактически этот YAML-файл представляет собой спецификацию ВМ. Его можно сохранить в системе контроля версий, например в Git, а затем использовать для повторного создания идентичных ВМ. То есть переход от ClickOps к DevOps здесь максимально упрощён: не нужно заново настраивать виртуальную машину через интерфейс, достаточно использовать готовую спецификацию.

Рисунок 16. YAML-файл созданной ВМ

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

Рисунок 17. Добавление YAML-файла

Снимки

Снимки позволяют зафиксировать текущее состояние ресурса для последующего восстановления или клонирования. Снимок ВМ включает в себя параметры ВМ и состояние всех её дисков; снимок диска сохраняет только данные выбранного диска.

Рисунок 18. Пример клонирования на основе снимка ВМ

Это является ещё одним отличием от VMware, где снимок ВМ включает состояние дисков, но не сохраняет её конфигурацию.

Миграция

DVP поддерживает живую миграцию, цель которой — перенести ВМ между узлами или хранилищами без потери состояния, предварительно синхронизировав её память.

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

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

Рисунок 19. Пример миграции ВМ через веб-интерфейс

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

Рисунок 20. Процесс миграции

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

Для решения этой проблемы используется механизм, аналогичный VMware EVC (Enhanced vMotion Compatibility), который унифицирует набор инструкций процессора и обеспечивает корректную миграцию виртуальных машин между узлами с разными моделями CPU.

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

Рисунок 21. Использование механизма Discovery

Через классы ВМ можно задавать стандартизированные конфигурации для конечных пользователей. Например, определить допустимые размеры виртуальных машин, ограничить количество виртуальных процессоров или другие параметры ресурсов. Это позволяет перейти к более управляемой модели предоставления инфраструктуры как сервиса (Infrastructure as a Service, IaaS), где пользователям предлагаются заранее определённые варианты конфигураций.

Также можно задавать Core Fraction — параметр, определяющий гарантированную долю процессорного ядра, выделяемую ВМ. С его помощью можно управлять уровнем переподписки ресурсов. Например, значение 20 % означает возможность переподписки примерно 5:1, что подходит для сред разработки и некритичных нагрузок. В то же время значение 100 % обеспечивает соотношение 1:1. Такой режим используется для критически важных нагрузок, где требуется предсказуемая производительность.

Рисунок 22. Выделение ресурсов для ВМ в Deckhouse Virtualization Platform 1.10

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

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

Рисунок 23. Миграция диска

Работа с гибридными приложениями

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

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

В Deckhouse Virtualization Platform 1.10 демонстрационное приложение было развёрнуто примерно за 15 минут. На платформе достаточно один раз описать приложение и всю необходимую конфигурацию в Git:

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

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

Рисунок 24. Архитектура гибридного приложения в DVP

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

Мониторинг и наблюдаемость

Deckhouse Virtualization Platform предоставляет решение для мониторинга на базе Prometheus и Grafana. Модуль автоматически настраивает сбор метрик с узлов, подов и ключевых компонентов кластера (etcd, kube-apiserver, CoreDNS), предлагает предустановленные дашборды для анализа использования CPU, памяти и т. д. Все компоненты работают в отказоустойчивом режиме и адаптированы для облачных и bare metal-инфраструктур.

Рисунок 25. Мониторинг ВМ в DVP 1.10

Рисунок 26. Информация о событиях

Рисунок 27. Диагностика

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

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

Рисунок 28. Дашборд по результатам мониторинга всей инфраструктуры

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

Рисунок 29. Результаты мониторинга отдельного пространства имён (проекта)

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

Возможности Deckhouse Commander

Deckhouse Commander предназначен для централизованного управления кластерами Deckhouse Kubernetes Platform (DKP) и DVP: берёт на себя рутинные операции, ускоряет процессы и обеспечивает прозрачную картину по всем кластерам. Поставляется в составе платных редакций DVP. Включён в реестр отечественного ПО (№ 25598 от 20.12.2024).

Основные возможности:

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

Рисунок 30. Интерфейс Deckhouse Commander

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

Рисунок 31. Вызов терминала

Для сценариев автоматизации и интеграции (CI/CD, self-service-порталы, IDP-платформы) Deckhouse Commander предоставляет внешний API.

Встроенная безопасность

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

Также в DVP реализованы преднастроенные механизмы защиты и безопасности «из коробки».

Средства управления TLS-сертификатами

Они упрощают настройку и сопровождение шифрования трафика для приложений, работающих в кластере. Платформа поддерживает автоматический выпуск TLS-сертификатов. При необходимости учётные данные можно не хранить в конфигурации DVP: доступна возможность создать отдельный Secret и ссылаться на него в ресурсе ClusterIssuer.

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

Мультитенантность — возможность создавать в кластере Kubernetes изолированные окружения (проекты). Проекты похожи на пространства имён (namespaces), но имеют больше возможностей.

Рисунок 32. Раздел «Проекты» в DVP 1.10

Пространства имён (namespaces) используются для логического разделения ресурсов в Kubernetes и не ограничивают сетевое взаимодействие, потребление ресурсов подами и возможности монтирования директорий хоста. Такая ситуация не полностью соответствует современным требованиям к разработке.

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

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

Рисунок 33. Установка администратором квот на ресурсы в Deckhouse Virtualization Platform 1.10

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

Рисунок 34. Пример доступной информации о выбранном проекте на странице «Проекты»

Если пользователю не хватает доступных ресурсов, он должен обратиться к своему администратору через принятый в организации процесс, например через систему заявок или корпоративный мессенджер. Автоматизированный механизм согласования и изменения квот внутри платформы не предусмотрен. Он реализован в рамках Deckhouse Commander.

Сканирование на уязвимости, соответствие требованиям регуляторов

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

известные уязвимости (CVE) в используемых образах;
проверку соответствия требованиям безопасности (compliance), включая стандарты CIS.

Для сканирования используются публичные базы данных уязвимостей, включая БДУ ФСТЭК, обогащённые данные Astra Linux, ALT Linux и РЕД ОС.

Рисунок 35. Обзор безопасности в DVP 1.10

Рисунок 36. Базы данных по уязвимостям

Рисунок 37. Пример отчёта о соответствии приказу ФСТЭК России № 239

Если уязвимость устранена путём обновления образа, сканирование нового образа запускается автоматически. Отчёт по нему обновляется в течение 2–3 минут. При необходимости повторное сканирование можно запустить вручную через веб-интерфейс или CLI.

На момент написания обзора сканирование ВМ на уязвимости не предусмотрено (в планах вендора — IV квартал 2026 года).

Журналирование

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

Рисунок 38. Отправка логов

ИИ-ассистент

Платформа поддерживает работу с любыми OpenAI-совместимыми моделями. Это может быть как внешняя модель, так и собственная большая языковая модель (Large Language Model, LLM), развёрнутая внутри закрытого контура. В последнем случае все данные остаются внутри инфраструктуры и не передаются во внешние сервисы.

Для подключения модели необходимо указать используемую LLM и параметры работы, например количество токенов. После успешной настройки внутри платформы становятся доступны специальные навыки (skills), которые позволяют модели понимать структуру и принципы работы платформы.

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

Рисунок 39. Настройка ИИ-ассистента в DVP

Рисунок 40. ИИ-ассистент в Deckhouse Commander

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

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

Архитектура Deckhouse Virtualization Platform 1.10

Платформа компании «Флант» включает следующие компоненты:

Ядро (Core). Основано на проекте KubeVirt, который команда вендора значительно переработала, чтобы обеспечить полноценную готовность платформы к промышленной эксплуатации. Использует QEMU/KVM и libvirtd для запуска ВМ с аппаратной производительностью и стабильностью.
Deckhouse Virtualization Container Registry (DVCR) — репозиторий для хранения и кэширования образов ВМ.
Virtualization API — контроллер, реализующий API для создания и управления ресурсами ВМ.

Рисунок 41. Архитектура Deckhouse Virtualization Platform 1.10

Лицензирование Deckhouse Virtualization Platform 1.10

Платформа лицензируется по физическим ядрам процессора или физическим узлам кластера с использованием метрик CPU Core или Server.

DVP может лицензироваться как отдельный продукт и использоваться совместно с определёнными редакциями Deckhouse Kubernetes Platform (DKP).

Рисунок 42. Сравнение возможностей виртуализации в разных редакциях DVP и DKP

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

Системные требования Deckhouse Virtualization Platform 1.10

Компоненты платформы необходимо развёртывать на физических серверах (bare metal). Установка на ВМ допустима, но чаще всего такие сценарии используются в демонстрационных целях или для разработки. В этом случае должна быть включена вложенная виртуализация (nested virtualization). Если платформа развёрнута на виртуальных машинах, производительность ВМ внутри вложенной виртуализации будет невысокой.

Требования к аппаратному обеспечению

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

Рекомендуются следующие минимальные ресурсы для инфраструктурных узлов в зависимости от их роли в кластере:

Мастер-узел — 8 CPU, 16 ГБ RAM, 60 ГБ дискового пространства на быстром диске (400+ IOPS);
Frontend-узел — 2 CPU, 4 ГБ RAM, 50 ГБ дискового пространства;
Узел мониторинга (для нагруженных кластеров) — 6 CPU, 12 ГБ RAM, 50/150* ГБ дискового пространства на быстром диске (400+ IOPS).

Системный узел:

4 CPU, 8 ГБ RAM, 50/150* ГБ дискового пространства — если в кластере есть выделенные узлы мониторинга;
8 CPU, 16 ГБ RAM, 60/160* ГБ дискового пространства на быстром диске (400+ IOPS) — если в кластере нет выделенных узлов мониторинга.
Worker-узел — требования аналогичны требованиям к master-узлу, но во многом зависят от характера нагрузки, запускаемой на узле (узлах).

Дополнительно на хостах, где планируется запуск виртуальных машин, должна поддерживаться аппаратная виртуализация CPU.

Возможности масштабирования платформы

DVP поддерживает следующую конфигурацию: до 1000 узлов и до 50 000 ВМ. По масштабу поддерживаемых конфигураций эти показатели сопоставимы с возможностями других решений на рынке, а в отдельных сценариях превышают их. Один из примеров: VMware vSphere 8 позволяет создавать до 2500 серверов и 40 000 ВМ на vCenter.

Интеграции и совместимость

Открытый API позволяет встроить DVP в существующие ИТ-процессы и интегрировать платформу с российскими и зарубежными решениями. Также доступна актуальная матрица совместимости с российскими решениями и оборудованием.

Поддерживаемые операционные системы

Платформа поддерживает МОС ОС 15.4, 15.5, ALT Linux p10, 10.0, 10.1, 10.2, 11, 8 СП (релиз 10), Astra Linux Special Edition 1.7, 1.8, CentOS 9, Debian 11, 12, 13, openSUSE 15.4, 15.5, 15.6, РЕД ОС 7.3, 8.0, Rocky Linux 9, РОСА Сервер 7.9, 12.4, 12.5, 12.6, Ubuntu 20.04, 22.04, 24.04. Точный перечень зависит от редакции DVP.

Доступна поддержка российских ОС как на гипервизоре, так и в качестве гостевых.

Обновление

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

Alpha — включает самые свежие обновления и новые возможности. Это наименее стабильный канал обновлений, ориентированный на кластеры разработки, используемые небольшим числом разработчиков.
Beta — также ориентирован на кластеры разработки. Получает версии, предварительно опробованные на канале Alpha.
Early Access — рекомендуемый вендором канал обновлений, если заказчик хочет оперативно получать обновления, но планирует подождать некоторое время с момента релиза. Подойдёт для кластеров, где идёт активная работа (запускаются, дорабатываются новые приложения и т. д.). Обновления функциональности поступают в этот канал не ранее чем через одну неделю после появления в релизе.
Stable — стабильный канал обновлений для кластеров, в которых закончена активная разработка и преимущественно осуществляется эксплуатация. Обновления функциональности поступают в этот канал не ранее чем через две недели после появления в релизе.
Rock Solid — наиболее стабильный канал обновлений с версиями, которые уже проверены в промышленной эксплуатации и в которых устранены выявленные ошибки. Подойдёт для кластеров, которым необходимо обеспечить повышенный уровень стабильности. Обновления функциональности поступают в этот канал не ранее чем через месяц после появления в релизе.

Для критически важных нагрузок также доступен канал LTS, который включает версии с длительным сроком поддержки.

Рисунок 43. Настройка обновлений в DVP 1.10

Доступно обновление в закрытых окружениях без доступа к интернету. Компоненты Deckhouse Virtualization Platform могут обновляться автоматически либо с ручным подтверждением. Предусмотрена возможность настройки уведомлений об обновлениях.

Применение Deckhouse Virtualization Platform 1.10

Платформа компании «Флант» помогает бизнесу сокращать затраты на эксплуатацию и техническую поддержку. DevOps-команды получают привычные механизмы оркестрации, что позволяет ускорить вывод новых сервисов в эксплуатацию и сократить время вывода продукта на рынок (TTM). Для специалистов по эксплуатации упрощается внедрение современных практик управления инфраструктурой. Команды ИБ получают преднастроенные механизмы защиты и возможность работы в закрытом контуре.

Главные сценарии использования DVP:

Миграция с VMware — ручная и автоматизированная «из коробки», оркестрируемая миграция с использованием партнёрских решений.
Плавная трансформация приложений — постепенный переход от ВМ к микросервисам в рамках единой платформы.
Запуск гибридных приложений — единая Cloud Native-платформа для работы ВМ и контейнеров, которая поддерживает современные приложения и унаследованные системы, а также обеспечивает единые механизмы мониторинга, безопасности, управления сетями, хранилищами и ролевой моделью доступа независимо от среды выполнения.
Kubernetes как сервис — самообслуживание для развёртывания кластеров DKP по корпоративным шаблонам и политикам.
Фундамент частного облака — IaaS для ВМ и контейнеров «из коробки» с возможностью развития до PaaS/XaaS с использованием модулей Deckhouse (маркетплейс, Managed Services).

Сценарии могут комбинироваться.

Как ускорили разработку благодаря Deckhouse Virtualization Platform

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

У вендора использовались разные подходы для создания сред разработки. Отсутствовал единый стандарт подготовки и сборки окружений. Затраты на использование публичных облаков составляли от 1,5 до 3 млн рублей в месяц. Возникали сложности с учётом потребляемых ресурсов и биллингом, а также с организацией контроля доступа к средам разработки. В компании работало 40 команд. Вендору необходимо было решить следующие задачи:

снизить операционные затраты (OPEX) и зафиксировать стоимость владения инфраструктурой;
предоставить среду разработки, соответствующую стандартам ИБ;
обеспечить возможность быстрого создания окружений без найма новых инженеров.

В ходе проектирования было принято решение выбрать частное облако на базе Deckhouse Virtualization Platform и Deckhouse Commander. Размер инфраструктуры: 20 гипервизоров, более 1000 ВМ и более 100 кластеров DKP. Разработчиков сгруппировали с помощью функции мультитенантности: получилось более 50 выделенных проектов (тенантов). С помощью Deckhouse Commander обеспечили автоматизацию: централизовали управление, ускорили процессы и получили прозрачную картину состояния всех кластеров.

По итогам внедрения получили следующие результаты:

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

Ожидаемая окупаемость проекта составляет один год, несмотря на рост цен.

Миграция с VMware vSphere с последующим переходом на микросервисную архитектуру

К вендору обратилось образовательное учреждение со следующей ситуацией: использовались унаследованная платформа виртуализации VMware vSphere для работы приложений на ВМ и микросервисные приложения в Docker. Необходимо было выполнить миграцию на российскую платформу виртуализации с последующим переходом на микросервисную архитектуру.

Компания «Флант» постепенно перенесла ВМ на DVP. Платформа объединила виртуальные машины и контейнеризированные приложения в одной среде с единым управлением через веб-интерфейс. Благодаря преднастроенным механизмам защиты «из коробки» необходимый уровень безопасности обеспечивался по умолчанию.

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

Миграция с OpenStack на cloud-native виртуализацию

Крупный банк столкнулся со сложностями при сопровождении и обновлении платформы на базе OpenStack. Необходимо было создать фундамент для частного облака и унифицировать подход к управлению ВМ и контейнерами. В качестве единой платформы управления была выбрана DVP. Она позволила стандартизировать подход к управлению инфраструктурой за счёт единого API, централизованного мониторинга и общих политик безопасности.

Процессы обновления платформы стали более предсказуемыми. Появилась возможность получать техническую поддержку. Была реализована сквозная наблюдаемость для инфраструктуры и приложений. Автоматизация упростилась за счёт использования DevOps-практик.

Выводы

Deckhouse Virtualization Platform 1.10 — отечественная платформа для построения единой среды управления виртуальными машинами и контейнеризированными приложениями. Подходит для построения современной гибридной инфраструктуры, включая сценарии работы в изолированных средах.

DVP объединяет управление вычислительными ресурсами, автоматизацию развёртывания, механизмы безопасности, интеграцию с внешними решениями и другие функции. По базовым возможностям она сопоставима с решениями класса VMware, но при этом выходит за рамки традиционной модели управления виртуальными машинами за счёт поддержки контейнеризации, а также современных DevOps-практик, IaC и GitOps.

Достоинства:

Единая платформа для безопасной разработки, доставки и эксплуатации виртуальных машин и контейнеризированных приложений, а также миграции на микросервисную архитектуру.
Возможность развёртывания платформы в закрытом окружении.
Управление через веб-интерфейс или API.
Поддержка IaC и ClickOps без внешних инструментов.
Знакомый механизм оркестрации: управление ВМ как Kubernetes-объектами.
Ролевая модель доступа.
Мультитенантность.
SDN и SDS «из коробки».
Сканирование контейнерных образов на уязвимости (CVE), проверка их соответствия требованиям безопасности (compliance), включая стандарты CIS.
Встроенный аудит и регистрация событий в области безопасности.
Сквозной ИИ-ассистент.
Открытый API для интеграции с внешними решениями.
Масштабирование до 1000 серверов и 50 000 виртуальных машин.
Живая миграция.

Недостатки:

Развёртывание и настройка платформы через графический установщик пока возможны с дополнительной ручной конфигурацией после развёртывания кластера.
Не реализовано встроенное сканирование ВМ на уязвимости. Для этого необходимо использовать партнёрские решения.
Отсутствует механизм подачи пользователями заявок на изменение квот проекта.

Реестр сертифицированных продуктов »