Развернули KubeVirt, подняли первую виртуальную машину — и она даже работает. А дальше выясняется, что виртуальным машинам нужно от кластера не то же, что контейнерам. Чтобы машина переезжала между узлами без остановки, том под её диск должен быть доступен на запись с нескольких узлов сразу, а её адрес и MAC — пережить переезд. Дальше выяснится ещё многое: где хранить образы, как отслеживать состояние и реагировать на сбои, что дать людям, которые администрируют виртуальные машины, но не пишут манифесты. «Ванильный» KubeVirt — это ядро запуска ВМ в Kubernetes, всё остальное вы собираете и потом сопровождаете сами.
Одной из технологий, которые легли в основу нашей платформы, был именно KubeVirt. В 2025 году мы писали, что Deckhouse Virtualization Platform (DVP) готова к использованию в продакшене: в нашем решении виртуальные машины управляются средствами Kubernetes наравне с контейнерами. Мы собрали вокруг KubeVirt всё необходимое: UI, мониторинг, сетевые решения, ролевую модель, хранилища и многое другое.
Мы прошли этот путь и сложили результат в продукт. Сильной команде он не связывает руки: те же манифесты, тот же GitOps, все ручки на месте — а согласование версий и разбор CVE теперь наша забота. А команде, которая не готова держать у себя эксперта по CNI и по CSI одновременно, он даёт классическую виртуализацию через веб-интерфейс. В статье — о том, что для этого пришлось сделать.
Сразу оговоримся: KubeVirt — хороший проект, и доказывать обратное мы не собираемся. Готовой платформой он и не задумывался. Это ядро запуска ВМ в Kubernetes, которое намеренно оставляет выбор хранилища, сети, интерфейса и мониторинга за вами. Инструмент для сильных команд. Вы инженер, который держит Kubernetes в проде, знает свой CNI, умеет готовить СХД с RWX-томами и живёт с собственным процессом обновлений? Соберите на KubeVirt ровно то, что нужно именно вам, и оно будет работать.
Вопрос в цене сборки и, главное, в цене её сопровождения. Обновления KubeVirt, CDI, CNI и CSI нужно согласовывать между собой, за CVE в каждом компоненте необходимо следить самому, а знание о том, как всё это склеено, обычно живёт в голове одного-двух инженеров. Уйдёт такой инженер, и платформа превращается в чёрный ящик, который страшно трогать.
Содержание:
Архитектура и философия
Технологическим ядром DVP служит наш форк KubeVirt, но пользователь с ним не работает — и не может: объекты внутренних API-групп скрыты, менять их вправе только контроллеры платформы. Мы намеренно пошли на это ограничение: отвечать за поведение машины можно, только если её низкоуровневую конфигурацию никто не правит в обход. Взамен снаружи свой API: ресурсы названы и устроены так, как о них думает администратор виртуальных машин.
Мы собираем все компоненты платформы из исходников, например бинарники qemu и libvirt со всеми их зависимостями, и полностью контролируем процесс сборки и поставки. Это значит, что мы отвечаем за каждый артефакт в релизе. В «ванильном» KubeVirt компоненты собираются сообществом, и конечный пользователь сам отвечает за выбор и проверку артефактов.
Мы предоставляем пользователям готовую к использованию конфигурацию без необходимости самостоятельно подбирать и настраивать инфраструктурные компоненты.
Вот что нужно закрыть, чтобы вывести KubeVirt в продакшен. За каждым пунктом стоит не только первичная настройка. Дальше идут обновления, отладка и поддержка всей связки:
CNI с сохранением адресов при живой миграции: выбрать, развернуть, проверить на своих сценариях.
СХД и CSI-драйвер с RWX-томами и снимками (snapshots): подобрать, погонять на отказах, следить за совместимостью версий.
CDI для импорта образов: развернуть и придумать, где и по каким правилам хранить сами образы.
Мониторинг и алертинг: метрики есть, дашборды и пороги пишете вы.
RBAC: спроектировать роли под свои команды с нуля.
Графический интерфейс: выбрать сторонний и взять на сопровождение.
Согласованные обновления всего перечисленного между собой.
Каждая задача решаема, по отдельности ни одна не страшная. Вопрос в сумме: сколько недель команды они съедят вместе и сколько человек потом смогут в этой связке разобраться.
Например, настроить и выбрать CNI (Container Network Interface) для поддержки живой миграции, найти и сконфигурировать СХД и драйвер CSI (Container Storage Interface), установить и настроить CDI (Containerized Data Importer) для работы с образами, подключить мониторинг и алертинг. Подробнее об этих задачах читайте в нашем переводе статьи «KubeVirt: глубокое погружение для администраторов VMware vSphere».
У DVP и DKP одна кодовая база, поэтому виртуализация по умолчанию интегрирована со всеми компонентами платформы. Всё перечисленное ниже в «ванильном» KubeVirt нужно выбирать и настраивать самостоятельно:
Единая сеть для подов и ВМ. Виртуальные машины и контейнеры работают в одном сетевом пространстве на базе программно-определяемых сетей и CNI Cilium. Это упрощает запуск приложений, где часть компонентов работает в ВМ, а часть — в контейнерах, и позволяет применять единые политики сетевого доступа.
Гибкое хранилище. Стандартный интерфейс CSI позволяет подключать поддерживаемые системы хранения без изменения самой платформы. Администратор может выбирать StorageClass под разные требования к производительности, отказоустойчивости и типу нагрузки. Поддержка снимков упрощает создание точек восстановления перед обновлениями, тестированием или изменением конфигурации.
Разграничение доступа. Доступ к виртуальным машинам, дискам, образам и операциям управления назначается пользователям и группам с необходимой гранулярностью. Это позволяет разделить полномочия между администраторами платформы, владельцами проектов, разработчиками и операторами, а ещё снижает риск несанкционированного изменения критичных ресурсов.
Встроенная наблюдаемость. Метрики, дашборды и алерты позволяют отслеживать состояние ВМ, узлов кластера, операций миграции, виртуальных дисков, снимков и хранилища образов DVCR (Deckhouse Virtualization Container Registry — реестр контейнеров виртуализации Deckhouse). Например, администратор заранее получит предупреждение о нехватке места в хранилище образов или о проблеме с миграцией перед выводом узла в обслуживание.
Графический интерфейс. Веб-интерфейс позволяет создавать и изменять ВМ, подключать диски и образы, выполнять клонирование, миграцию и восстановление без работы с Kubernetes-манифестами. Это снижает порог входа для администраторов, которые привыкли работать с классическими платформами виртуализации.
За KubeVirt стоят большое сообщество и крупные вендоры, проект быстро развивается. Разница не в количестве рук, а в том, к кому идти с проблемой. У DVP есть команда, отвечающая за всю связку целиком: виртуализацию, сеть, хранилище, интерфейс, безопасность, наблюдаемость. Какую версию компонента взять, куда бэкпортить фикс, что делать с уязвимостью — всё это решаем мы, как и отвечаем за результат по SLA. При сборке из апстрима эти решения принимаете вы сами.
API
Мы разработали информативный API с понятными ресурсами: виртуальные машины, диски, образы. Compute и storage для подов и ВМ чётко разделены, а для рутинных операций есть удобные механизмы, поэтому инженерам не нужно глубоко разбираться во внутреннем устройстве платформы, чтобы сделать свою работу. API KubeVirt в этом плане гораздо более низкоуровневый: ресурсы менее абстрагированы, для эффективной работы с ним требуется понимание внутренней реализации системы.
Декларативное управление и автоматизация
Наш API позволяет полноценно управлять жизненными циклом ВМ и связанных с ними ресурсов декларативно. Создание, изменение, удаление и масштабирование ВМ описываются в манифестах, тем же способом и теми же инструментами, которыми вы уже управляете приложениями. Отдельный слой описания инфраструктуры для виртуальных машин не нужен. Всё необходимое уже есть в платформе.
К виртуальным машинам можно применять те же подходы, что и к контейнерам: хранить спецификацию в Git, развёртывать с помощью Helm-чартов, управлять жизненным циклом с помощью Argo CD. При этом есть и инструменты, специфичные для ВМ: cloud-init и sysprep для первичной кастомизации, Ansible для конфигурации через плейбуки.
Основные ресурсы API
Давайте пробежимся по основным ресурсам API Deckhouse Virtualization Platform и сравним с KubeVirt. Вот далеко не полный список:
Ресурс DVP | Что делает | Как в KubeVirt |
| Образы уровня кластера и проекта. Хранятся во встроенном хранилище, который поставляется вместе с DVP | Отдельной сущности образа нет. Работа с образами ведётся через стандартные ресурсы Kubernetes: |
| Управляет дисками независимо от ВМ. Под капотом — PVC с автоматически подобранными оптимальными параметрами |
|
| Централизованно задаёт политику, валидирует и управляет размещением ВМ |
|
| Декларативные операции управления (Start, Stop, Restart, Migrate, Evict, Clone, Restore) | Разовые операции (Restart, Migrate, Evict, Clone, Restore) выполняются командами |
| Управление IP-адресами автоматизировано | KubeVirt полностью зависит от функционала используемого CNI |
ВМ больше чем ресурс Kubernetes
Виртуальные машины в нашей платформе — это полноценные ресурсы Kubernetes. К ним применимы все возможности, доступные для подов, с дополнительной поддержкой живой миграции. В DVP используется Cilium — CNI-плагин Kubernetes, который обеспечивает сетевое взаимодействие и применение сетевых политик к ВМ и контейнерам. В KubeVirt для корректной миграции с сохранением сетевых адресов нужен CNI, например на основе Open Virtual Network (OVN). С другими сетевыми плагинами миграция работает, но с ограничениями.
Диагностика
Ещё одно важное отличие — в диагностике. В DVP причина проблемы видна в статусе ресурса. Например, для ВМ не нужно спускаться ниже — там будет сказано, что не нашлось свободного IP-адреса, что диск ещё не готов, что под с машиной не стартовал или что узел перестал отвечать. В KubeVirt, чтобы понять, что сломалось, нужно последовательно проверять VirtualMachine, VirtualMachineInstance, Pod и другие ресурсы.
Графический интерфейс
Посмотрим правде в глаза: API, декларативность и DevOps-подходы не всегда являются главным приоритетом при выборе платформы виртуализации. Очень часто нужен привычный интерфейс, где можно быстро «накликать» ВМ, не открывая редактор манифестов.
В апстриме UI не входит в поставку, но выбор есть: kubevirt-manager, плагин KubeVirt для Headlamp, консоль OpenShift Virtualization. Каждый закрывает свою часть сценариев, но каждый нужно выбрать, развернуть, подружить со своей аутентификацией и RBAC, обновлять синхронно с KubeVirt и отвечать за его уязвимости. Это отдельный компонент в вашей зоне ответственности.
Наш интерфейс — часть платформы, а не отдельный компонент. Он ставится и обновляется вместе с модулем виртуализации, живёт под той же ролевой моделью и теми же проектами, что и весь кластер. Что вам разрешено в API, то вы и видите на экране — вторую систему доступа заводить не нужно.
Он знает ресурсы платформы по смыслу, а не по схеме CRD. Калькулятор допустимых конфигураций читает VirtualMachineClass и не даёт собрать машину, которую откажется принимать кластер. Переключатель политики живой миграции подписан результатом, а не именем поля. USB-устройства, IP-адреса и снимки — это отдельные экраны со своей логикой, а не «ещё один кастомный ресурс, отрисованный по схеме».
Мы стремимся к тому, чтобы UI закрывал основные сценарии работы с платформой. Наша цель — полный паритет с API, но с допустимыми упрощениями там, где они не влияют на пользовательские сценарии. Задача — снизить порог входа для администраторов, привыкших к классическим платформам виртуализации, и избавить их от «БДСМ с YAML».
Например, у живой миграции есть настройка, от которой зависит, что платформа сделает, если машина долго не может переехать. В манифесте это поле с несколькими значениями на выбор. В интерфейсе — простой переключатель, рядом с которым написано, что произойдёт при каждом варианте. Тот же сценарий, но без погружения в спецификацию.
Что можно делать в UI (далеко не полный список):
создавать, изменять и удалять ВМ, образы и диски;
управлять снимками (snapshots);
работать с сетями и IP-адресами;
подключать USB-устройства;
просматривать события и мониторить производительность ВМ.
Всё это — в одном окне, без переключения между инструментами.
Хранилище и работа с образами
Мы постарались максимально автоматизировать работу с дисками и образами в DVP.
Параметры дисков
Параметры создаваемых дисков автоматически определяются на основе выбранного класса хранения. При создании диска из образа его размер также может определяться автоматически. В KubeVirt все параметры PVC и DataVolume задаются явно в манифестах.
Встроенный реестр образов — DVCR
В нашей платформе есть встроенный реестр образов виртуальных дисков — DVCR. Он избавляет от необходимости использовать внешние решения или контейнерные реестры через DataVolume. В KubeVirt для импорта образов используется CDI (Containerized Data Importer), который поддерживает различные источники данных, но не предоставляет встроенных возможностей хранения. При загрузке образов в DVCR система автоматически определяет их тип и размер — это нужно, чтобы потом правильно создавать диски, зная этот размер. В KubeVirt механизм CDI может определить тип образа, а размер диска задаётся явно при создании DataVolume.
Автоматическая очистка
DVP автоматически очищает неиспользуемые образы по расписанию, которое администратор настраивает в интерфейсе. Это помогает не засорять хранилище.
В ванильном KubeVirt хранилища образов как отдельной сущности нет: образы лежат в контейнерном реестре или на PVC, следить за их жизненным циклом — задача администратора. TTL-сборщик DataVolume в CDI был отключён по умолчанию и объявлен устаревшим, так что чистку организуете сами — вручную или внешней задачей (job). В KubeVirt администратору нужно настроить garbage collection вручную.
Создание и экспорт образов
В DVP можно создавать новые образы из уже существующих дисков или других образов. В KubeVirt это тоже можно — через DataVolume с sourceRef, — но такой способ требует больше ручной настройки. Экспорт дисков в нашей платформе доступен «из коробки». В KubeVirt для этого есть отдельный API VirtualMachineExport и команда virtctl vmexport. Механизм включается через feature gate, на каждый экспорт поднимается под export-сервера, а данные забираются по HTTP по временной ссылке, которая по умолчанию живёт два часа. Работает. Но включить, опубликовать эндпоинт и закрыть его доступами придётся самостоятельно.
Управление виртуальными машинами
В DVP реализован ряд механизмов, которые упрощают управление ресурсами виртуальных машин.
CPU-профили и топология
Система автоматически создаёт универсальные CPU-профили с согласованным набором инструкций процессора. Это позволяет запускать ВМ и выполнять её живую миграцию между узлами кластера, даже если на узлах установлены процессоры разных поколений или моделей. При этом ВМ использует общий набор CPU-инструкций, который поддерживается всеми подходящими узлами.
В KubeVirt модель CPU указывается непосредственно в спецификации ВМ (например, host-model, host-passthrough или конкретная модель). Кластер знает о процессорах узлов: компонент node-labeller развешивает лейблы вида cpu-model.node.kubevirt.io/{model} и cpu-model-migration.node.kubevirt.io/{model}, по которым работает планировщик. Однако KubeVirt не вычисляет «общий знаменатель» за вас: при использовании host-model машина сможет мигрировать только на узел с точно такой же моделью процессора. Чтобы обеспечить миграцию в разнородном кластере, администратору приходится вручную собирать и поддерживать универсальный CPU-профиль каждый раз, когда в кластер добавляется новый узел.
Все CPU-профили в DVP централизованно управляются через ресурс VirtualMachineClass. Он поддерживает несколько режимов работы, включая Discovery — автоматическое определение списка инструкций, совместимого на всех узлах кластера. В KubeVirt CPU настраивается напрямую в VirtualMachine, а из режимов доступны только Host, HostPassthrough, Model.
Конфигурация CPU-топологии для виртуальных машин в DVP создаётся автоматически. В KubeVirt параметры cpu.sockets, cores и threads задаются явно в манифестах.
Sizing-политики и переподписка
Размеры виртуальных машин можно регулировать через политики sizing: они централизованно задают допустимые параметры ресурсов и автоматически проверяют ВМ на соответствие этим правилам. Это нужно администраторам кластера, чтобы эффективнее «упаковывать» нагрузку по узлам и защищать платформу от нежизнеспособных конфигураций, например «1 CPU на 128 ГБ памяти».
В KubeVirt параметры CPU и памяти задаются напрямую в ресурсе VirtualMachine.
Также реализовано управление переподпиской CPU — на уровне sizing-политики для группы ВМ или через параметр coreFraction, который задаёт гарантированную долю процессорных ресурсов. Это полезно, когда нужно централизованно отдать определённой группе ВМ необходимые ресурсы. Например, для некритичных систем можно назначить coreFraction=20 (фактически переподписка 1:5), а для прода скорее подойдёт coreFraction=50 (переподписка не более 1:2). В KubeVirt переподписка CPU настраивается на двух уровнях. На уровне кластера — параметром cpuAllocationRatio в ресурсе KubeVirt (по умолчанию 10, то есть переподписка 1:10 включена «из коробки» для всех ВМ). Точечно — вручную через requests.cpu / limits.cpu в конкретной ВМ или через dedicatedCpuPlacement: true, чтобы от переподписки отказаться совсем. В KubeVirt централизованной политики для группы ВМ нет: администратор не может задать разные коэффициенты для продакшена и тестовой среды или ограничить значения, которые пользователь выставит своей ВМ.
В графическом интерфейсе Deckhouse есть «калькулятор» ВМ, который показывает, какие конфигурации допустимы на основе параметров, указанных в VirtualMachineClass.
Политики запуска и изменения конфигурации
Отдельно реализованы политики запуска виртуальных машин: AlwaysOn, AlwaysOnUnlessStoppedManually, Manual. Например, режим AlwaysOnUnlessStoppedManually поддерживает ВМ в работающем состоянии, если пользователь не остановил её явно. В KubeVirt эти задачи решает runStrategy (режимы: Always, RerunOnFailure, Once, Manual, Halted). Однако разница заключается в семантике: прямого эквивалента нашему AlwaysOnUnlessStoppedManually в апстриме нет. Режим Always поднимет машину даже после того, как её выключил человек. Чтобы этого не произошло, администратору придётся править спецификацию ВМ, меняя runStrategy на Halted. В DVP мы развели «желаемое состояние» и факт ручной остановки («оператор нажал стоп») по разным «ручкам», избавляя от необходимости менять манифесты ради временной остановки.
Важная особенность DVP — политики изменения конфигурации: изменения в VirtualMachineClass автоматически применяются ко всем связанным виртуальным машинам. В KubeVirt изменения нужно применять к каждой ВМ отдельно.
Миграция
Живая миграция нужна, чтобы перемещать работающие виртуальные машины между узлами кластера без простоя. В DVP мы автоматизировали многие аспекты этого процесса и устранили типичные проблемы, с которыми сталкиваются пользователи KubeVirt.
Автоматический запуск
Миграция в нашей платформе запускается автоматически при изменении правил размещения (placement): например, если вы обновили nodeSelector или affinity-правила в конфигурации ВМ. Так работает редакция EE (Enterprise Edition); в CE (Community Edition) новые правила размещения учитываются при следующем запуске машины. В KubeVirt контроллер переносит новые nodeSelector и affinity в спецификацию работающей ВМ, но саму миграцию не запускает: её инициирует администратор.
Разнородные хранилища и локальные диски
Ещё один важный момент — работа с разными типами хранилищ. При миграции между хранилищами (которые мы описываем в StorageClass) с разными размерами блоков DVP автоматически выравнивает размеры дисков на блочном хранилище. Это предотвращает потерю производительности и потенциальные проблемы при несовпадении параметров хранилища на исходном и целевом узлах.
Кроме того, мы реализовали живую миграцию ВМ с дисками на локальном хранилище узлов: диски переезжают вместе с машиной, отдельных действий администратора не требуется. Возможность доступна в редакции EE; в CE машина с диском на локальном хранилище живой миграцией не переносится. В KubeVirt живая миграция с локальными дисками тоже возможна, но требует значительной ручной подготовки: администратор должен заранее создать PVC на целевом узле, вручную скорректировать конфигурацию ВМ и выполнить ряд других действий.
Хотплаг
DVP, как и KubeVirt, поддерживает хотплаг дисков. Горячее изменение vCPU и памяти доступно в редакции EE, в CE такие изменения применяются при перезапуске ВМ. Разница в другом: подключённые на лету диски в DVP мигрируют вместе с ВМ без дополнительных манипуляций. Более того, для таких дисков можно изменить StorageClass (фактически смигрировать диск между хранилищами) без остановки ВМ.
В KubeVirt hotplug-диски также мигрируют вместе с ВМ, но при строгом условии: том должен поддерживать режим ReadWriteMany. Использование диска на хранилище с режимом ReadWriteOnce делает машину немигрируемой. Кроме того, сменить класс хранения у уже подключённого диска без его отключения в KubeVirt нельзя.
Политики миграции
Настраиваемые политики живой миграции позволяют гибко управлять процессом переноса ВМ между узлами — можно ограничить пропускную способность сети, задать таймауты и стратегии обработки ошибок. Любую миграцию можно отменить прямо в процессе выполнения.
Политики живой миграции есть и в KubeVirt: ресурс MigrationPolicy навешивается на ВМ или неймспейс по лейблам и задаёт пропускную способность, таймауты и число параллельных миграций. Отмена миграции выполняется командой virtctl migrate-cancel или удалением объекта.
Разница в том, откуда этим управляют. В DVP политика миграции лежит в классе ВМ рядом с остальными её параметрами, а отмена — это кнопка в интерфейсе. В KubeVirt для управления политиками и отмены миграции нужно работать с CLI с рабочего места администратора.
Сеть
Виртуальные машины в Deckhouse используют сетевые возможности Kubernetes так же, как и поды. К ним можно применять Service, Ingress и LoadBalancer, а сетевые подключения продолжают работать даже после живой миграции ВМ на другой узел. В KubeVirt сохранение сетевых подключений при миграции зависит от выбранного CNI-плагина.
Постоянные адреса
Виртуальные машины в DVP автоматически получают постоянные IP-адреса из подсетей main (администратор задаёт их параметром virtualMachineCIDRs в настройках модуля). Адрес хранится в отдельном ресурсе VirtualMachineIPAddress, который не зависит от жизненного цикла пода — ВМ сохраняет его и после перезапуска, и после живой миграции.
В KubeVirt механизм постоянных адресов работает иначе: в режиме masquerade ВМ доступна через NAT-адрес пода virt-launcher, который меняется при каждом старте и миграции — соединения рвутся. Режим bridge даёт постоянный адрес из внешней сети, но полностью запрещает живую миграцию (ВМ получает условие LiveMigratable=False).
Внешние сети и изоляция
Для внешних сетей мы используем общие кластерные (ClusterNetwork) и проектные сети (ресурсы NetworkClass и Network). Они позволяют подключить ВМ к физическим VLAN и при необходимости изолировать ВМ в рамках отдельных тенантов/проектов. В KubeVirt реализация внешних сетей и изоляции сильно зависит от выбранного CNI-плагина и требует настройки и поддержки со стороны администратора.
Безопасность
В DVP безопасность встроена на уровне платформы: ролевая модель, аудит и защищённые образы работают сразу после установки. При использовании KubeVirt администратор самостоятельно настраивает защиту, используя стандартные механизмы Kubernetes.
Готовая ролевая модель
В платформе используется готовая ролевая модель — преднастроенный список ролей для типовых задач. Так администратору не нужно проектировать RBAC с нуля. В KubeVirt роли и разрешения настраиваются индивидуально.
Модель в DVP построена на чётком разделении:
Управление кластером — работа с физической инфраструктурой: подключение хранилищ, настройка внешних сетей, определение политик безопасности.
Управление проектом — работа только в рамках своего проекта (создание виртуальных машин и дисков, управление образами) — в таком случае не видно ресурсы других проектов.
В каждом уровне есть несколько типов ролей: просмотр (viewer), пользователь (user), менеджер (manager), администратор (admin). Включение модуля виртуализации автоматически расширяет возможности существующих ролей платформы. Например, пользователю с ролью viewer не нужно отдельно выдавать права на просмотр ВМ — они добавляются автоматически.
Собирать это разделение вручную не нужно — роли поставляются вместе с модулем. Кластерные роли d8:manage:virtualization:viewer|manager|superadmin дают администратору инфраструктуры права на общекластерные объекты: настройки модуля (ModuleConfig), VirtualMachineClass, ClusterVirtualImage, аренды IP- и MAC-адресов, USB-устройства узлов. Проектные роли d8:use:role:viewer|user|manager|admin|superadmin:virtualization выдаются в пределах проекта и покрывают работу с самими ВМ, дисками и образами внутри него.
Права на чувствительные действия вынесены в отдельные наборы и подключаются к ролям по возрастанию: доступ к консоли и VNC, port-forward, операции над ВМ и снимками, чтение секретов — начиная с роли user; квоты и лимиты проекта — с admin; внутренние ресурсы KubeVirt — только у superadmin.
Такое разделение позволяет строить на базе DVP облака, где в разных проектах живут разные команды или заказчики. Каждый администратор проекта получает те возможности, которые нужны для его задач, — не больше. В KubeVirt для изоляции используется стандартный механизм неймспейсов (namespaces) Kubernetes.
Эта же логика работает и с дополнительными сетями: администратор кластера один раз настраивает физические VLAN и описывает их как сервисы, а администраторы проектов просто подключают к ним ВМ — без необходимости знать, как устроена сеть «под капотом».
KubeVirt использует стандартный ресурс Namespace для размещения ВМ, который обеспечивает логическую изоляцию с политиками безопасности, квотами на ресурсы и сетевой изоляцией.
Distroless-образы и безопасные сборки
Все образы в DVP собраны в формате distroless: в них только нужные бинарники, без лишних системных библиотек. Это уменьшает количество потенциальных уязвимостей и размер, а ещё повышает безопасность и упрощает структуру решения. По сравнению со стандартными образами KubeVirt их размер меньше, а структура проще, что снижает поверхность атаки.
Контроль уязвимостей самой платформы
Безопасность компонентов платформы мы контролируем на своей стороне: регулярно сканируем образы на известные CVE, проводим статический анализ кода и исправляем проблемы ещё до релиза. Для пользователей это означает, что они получают уже проверенные артефакты. В KubeVirt пользователь самостоятельно проверяет образы из upstream-репозиториев.
Аудит событий безопасности
В коммерческих редакциях DVP пользователям доступен аудит событий безопасности для ресурсов виртуализации. В KubeVirt аудит настраивается через стандартный механизм Kubernetes audit.
Мониторинг
DVP предоставляет расширенные метрики по всем ресурсам виртуальных машин. Они дополняют базовые метрики KubeVirt и показывают, что происходит с инфраструктурой, в деталях.
Например, можно отслеживать:
загрузку CPU, памяти, сетевых интерфейсов и дисков каждой ВМ;
текущее состояние ВМ и операции миграции;
состояние подключённых виртуальных дисков и снимков;
заполнение DVCR — платформа заранее предупредит о риске нехватки места для новых образов;
эвакуацию ВМ перед отключением узла: если что-то идёт не так, предупреждение появится до того, как риск простоя повлияет на сервисы.
Подробнее о том как устроен мониторинг в DVP, читайте в документации.
Готовые дашборды
Пользователям доступны готовые дашборды с ключевыми метриками по кластеру, узлам, проектам и ВМ, чтобы не приходилось собирать их самостоятельно.
Статусы и диагностика
Информация о состоянии ресурсов структурирована и отображается прямо в статусах (conditions) и веб-интерфейсе, что упрощает диагностику. В KubeVirt статусы тоже есть, но диагностическая информация распределена по разным ресурсам (VirtualMachine, VirtualMachineInstance, Pod).
И это ещё не всё
Выше мы описали только фундаментальные отличия DVP от KubeVirt — на деле их гораздо больше. Вот ещё несколько вещей, о которых стоит знать:
Сертификат ФСТЭК России. Платформа сертифицирована как средство виртуализации: сертифицированная редакция DVP может использоваться в критической информационной инфраструктуре, информационных системах персональных данных и госсистемах — вплоть до высших классов защищённости.
ИИ-ассистент. Встроенный помощник отвечает на вопросы по работе с платформой в диалоге: как создать ВМ, подключить диск, почему машина не стартует. Снижает порог входа для новичков без чтения документации. Подробнее об ассистенте — в отдельной статье.
USB-устройства. В ВМ можно пробрасывать аппаратные токены и ключи защиты — с поддержкой hot-plug и живой миграции. Устройства пробрасываются по сети (USBIP), поэтому ВМ не привязана к узлу, в котором они физически воткнуты. Доступно в коммерческих редакциях.
Графический установщик. Платформу вместе с модулем виртуализации можно развернуть примерно за 10 минут через пошаговый веб-мастер — без ручного YAML и настройки DNS/Ingress.
Развитие UI. Интерфейс продолжает обрастать возможностями: появились диагностика и сбор бандла для обращений в поддержку.
Полный список отличий заметно длиннее, и в статью он не помещается. Если мы упустили важный для вас сценарий или остались вопросы, пишите в комментариях, разберём.
DVP и KubeVirt в одной таблице
Собрали все ключевые отличия из статьи в одну таблицу. Отметили функции, доступные в коммерческих редакциях (EE и CSE). Если пометки нет — функция есть в бесплатной Community Edition (CE).
Фича | Deckhouse Virtualization Platform | KubeVirt |
Выход в продакшен | Готовая платформа «из коробки» | Конструктор: CNI, CSI, CDI, мониторинг и UI подбираете и настраиваете сами |
Графический интерфейс | Встроенный UI, закрывающий основные сценарии (цель — полный паритет с API) | Не входит в поставку: сторонние проекты (kubevirt-manager, плагин для Headlamp, консоль OpenShift Virtualization), которые вы развёртываете и поддерживаете сами |
Образы |
|
|
Диски |
|
|
Операции с ВМ | Декларативно: ресурс | Императивно: |
Централизованная конфигурация ВМ |
| Настройка в каждом ресурсе |
Допустимые конфигурации и переподписка |
| Глобальный |
Модели и топология CPU | Универсальные профили создаются автоматически (Discovery) | Узлы маркируются автоматически ( |
Диагностика | Структурированные условия в статусе ресурса и в UI | Информация распределена по VM, VMI, Pod и другим объектам |
Живая миграция с локальными дисками | Полностью автоматизированная живая миграция (только в EE) | Требует ручных подготовительных шагов |
Запуск миграции при смене правил размещения | Автоматически (только в EE) | Вручную |
Соединения и IP после миграции | Сохраняются | Могут обрываться, зависит от CNI |
Дополнительные сети | Сеть как сервис: | Multus: пользователям проекта требуется понимание конфигурация на уровне кластера |
Роли и доступы | Готовая ролевая модель, разделение админов кластера и проектов | RBAC проектируется с нуля |
Образы компонентов | Distroless: только проверенные компоненты, меньше поверхность атаки | Стандартные |
Мониторинг | Расширенные метрики и готовые дашборды | Базовые метрики, дашборды настраиваются отдельно |
Сертификация | В реестре российского ПО и сертификат ФСТЭК России для сертифицированной редакции (только в DVP CSE) | Не применимо: сертифицируется продукт, а не открытый проект |
Вместо выводов
Принято считать, что виртуализация на Kubernetes — это выбор между привычным и современным: либо знакомые интерфейсы и предсказуемость, либо декларативность, GitOps и YAML вместо кнопок. Наш опыт говорит, что эта дилемма ложная.
В DVP Kubernetes выступает оркестратором, а не средством исполнения: он решает, где машине жить, как её сеть и диски связаны с остальным кластером и что делать при отказе узла. А за запуск ВМ отвечает KVM с QEMU «под капотом».
Для администратора же точкой входа остаётся привычный графический интерфейс. Создать ВМ, подключить диск, снять снимок, мигрировать ВМ с узла перед обслуживанием, пробросить USB-токен — всё это можно делать в одном окне, без открытия редактора манифестов. Интерфейс — не отдельная надстройка, а неотъемлемая часть платформы: он живёт, используя ту же ролевую модель, что и API, знает, какие конфигурации допустимы, и не даст собрать машину, которую кластер не сможет запустить.
Платформу можно быстро развернуть через графический установщик, а ИИ-ассистент подстрахует там, где иначе пришлось бы идти в документацию.
При этом ВМ не превращается в безликую сущность, которую платформа может в любой момент пересоздать. Она сохраняет постоянный IP, имеет диски со своим жизненным циклом, поддерживает снимки и живую миграцию без обрыва соединений.
Философия классической виртуализации никуда не делась — изменился лишь способ управления. И именно он даёт то, чего в классической среде не получить: спецификация ВМ лежит в Git и раскатывается Helm-чартом или Argo CD, ВМ и контейнеры живут в одной сети, используют общую ролевую модель с мониторингом и единой средой управления. Это не выбор «или классика, или Kubernetes». Это классические сценарии на современных инструментах, которые уже стали индустриальным стандартом.
Как попробовать нашу виртуализацию в деле
Попробовать Deckhouse Virtualization Platform и использовать её в своих проектах можно бесплатно. Самый быстрый способ — установить платформу по гайду быстрого старта. Просто следуйте инструкции и на третьем шаге выберите Community Edition.
В Community Edition нет части возможностей коммерческих редакций, но для знакомства с платформой и многих реальных задач её обычно достаточно. Полное сравнение фич можно посмотреть на странице продукта. Если вам нужна одна из коммерческих редакций, там же можно оставить заявку, чтобы обсудить свой сценарий использования с нашей командой.
Чтобы узнать больше о возможностях платформы, читайте подробный технический обзор Deckhouse Virtualization Platform 1.10, включая анализ архитектуры, безопасности и сценариев миграции.
P. S.
Читайте также в нашем блоге:
Единая платформа с сертификатом ФСТЭК России для управления виртуальными машинами и контейнерами
Обзор Deckhouse Virtualization Platform 1.10, системы для управления ВМ и контейнерами в одной среде
KubeVirt: глубокое погружение для администраторов VMware vSphere
Как я собрал домашнюю виртуализацию в контейнерах за 34 500 рублей
