Проект KubeVirt, созданный Red Hat в 2016 году для запуска виртуальных машин рядом с контейнерами в Kubernetes, наметил следующую большую перестройку: GPU и сетевые устройства должны выделяться через нативные механизмы Kubernetes, конфиденциальные ВМ — получать проверяемую среду исполнения, а сам стек виртуализации — стать сменным. Будущее KubeVirt важно и для российских команд: оно определит, можно ли переносить унаследованные ВМ, AI-нагрузки и edge-сервисы в единый кластер без отдельного острова виртуализации.
Как пишет The New Stack, KubeVirt уже имеет статус инкубационного проекта CNCF и собирает вклад от инженеров Nvidia, Microsoft, AMD, Intel и SUSE. Сообщество рассчитывает довести проект до следующей стадии CNCF — graduation. При этом речь не о готовом наборе релизных обещаний, а о направлениях работы: часть возможностей уже появилась в версиях 1.8 и 1.9, другие пока проходят обсуждение и зависят от ревью, интеграции и тестирования.
Главный практический сдвиг касается аппаратных ресурсов. В KubeVirt 1.9 поддержка выделения GPU виртуальным машинам через Kubernetes Dynamic Resource Allocation получила статус beta. Этот подход заменяет привычную схему с device plugins: Kubernetes сам должен согласованно распределять GPU, CPU и, в перспективе, сетевые адаптеры вроде SR-IOV. Авторы также работают над тем, чтобы ResourceClaim создавался из спецификации ВМ и политики поставщика, а не требовал от каждого пользователя ручного описания объектов. Для платформенной команды это меньше специальной логики вокруг ВМ; для разработчика — шанс получать вычислительные ресурсы тем же декларативным способом, что и для контейнерных workload’ов.
Отдельная линия — поддержка нового ускоренного железа. Участники проекта, включая инженеров Nvidia, адаптируют KubeVirt для систем Grace Hopper, Grace Blackwell и Vera Rubin; работа началась в группе Accelerated Infrastructure Enablement и переносится в апстрим. Здесь полезно не путать дорожную карту с наличием функции в продакшене: сама возможность запускать ВМ рядом с контейнерами не решает вопросы драйверов, прошивок, гостевой ОС, сетевой топологии и квот. Но для инфраструктур, где GPU нельзя просто отдать одному pod’у и забыть, направление выглядит логично: ВМ остаётся привычной границей совместимости, а Kubernetes — точкой управления ресурсами.
Не менее важна тема конфиденциальных виртуальных машин. KubeVirt расширяет работу с доверенными средами исполнения и рассматривает интеграцию с удалённой аттестацией и сервисами выдачи секретов, включая Trustee из проекта Confidential Containers. В версии 1.9 функциональность AMD SEV и SEV-SNP перешла в beta; поддержка Intel TDX остаётся alpha, а IBM Secure Execution достигла статуса GA. Поддержка Arm CCA ещё разрабатывается. Идея проста, хотя реализация совсем не проста: Kubernetes должен понимать, на каких узлах есть нужные аппаратные возможности, а владелец нагрузки — получать доказательство, что ключи или чувствительные данные попадают именно в доверенную среду.
Для AI-сценариев это критичнее, чем звучит в презентации о безопасности. Модель, данные и вычисления часто живут на общей инфраструктуре, а доверять приходится не только гостевой ВМ, но и связке CPU, ускорителя, межсоединений, драйверов и сервисов аттестации. KubeVirt хочет собрать эту цепочку в знакомом Kubernetes-интерфейсе. Однако проект прямо оговаривает: конфиденциальное выделение устройств и защищённый обмен между CPU и ускорителями потребуют согласованной поддержки со стороны железа, firmware, виртуализационного стека, гостевой системы и внешних сервисов. Магической галочки в манифесте здесь не будет.
Третье направление будущего KubeVirt — расширяемость без раздувания ядра. В версии 1.9 в alpha появился механизм структурированных плагинов: кластерный администратор может подключать domain hooks, node hooks и admission-логику, а изменения домена описывать выражением CEL либо сайдкаром, если нужен внешний контекст. Это попытка не превращать основной репозиторий в музей редко используемых функций. Для компаний, развивающих собственную платформу, подход ценен тем, что специализированная интеграция может жить вне core, но работать с гарантиями API KubeVirt.
Наконец, проект пытается ослабить привязку к связке libvirt, QEMU и KVM. Она остаётся стандартом KubeVirt, однако в 1.8 появился внутренний Hypervisor Abstraction Layer, а бэкенд Microsoft MSHV получил статус alpha. Дальняя цель — позволить Cloud Hypervisor, OpenVMM или Firecracker подключаться как внешние плагины, не заставляя команды форкать KubeVirt. Такая архитектура потенциально расширит выбор для изолированных sandbox-сред, edge-развёртываний и специфичных облачных платформ, но потребует глубокой переработки и не должна восприниматься как уже доступная опция.
За десять лет KubeVirt прошёл путь от инструмента миграции legacy-ВМ к кандидату на роль общей плоскости для контейнеров, виртуальных машин, AI и периферийных узлов. Теперь ключевой вопрос не в том, можно ли запустить ВМ в Kubernetes — это давно возможно, — а в том, удастся ли проекту сохранить совместимость, добавляя ускорители, аттестацию и альтернативные гипервизоры. Детали предложенной архитектуры собраны в материале .
