KubeVirt предоставляет очень базовые функции администрирования гипервизора и ограничен в использовании. Для интеграции ограниченного числа виртуальных машин относительное отсутствие функциональности и расширенных операционных возможностей, таких как интеграция управления хранилищем, не поддерживает расширенные функции, ожидаемые в управлении виртуальными машинами. Поскольку инфраструктура на основе виртуальных машин используется уже несколько десятилетий, виртуальные машины извлекают выгоду из обширного понимания отрасли и постоянных инноваций в управлении в этой области. В идеале расширенные возможности виртуальных машин должны быть доступны с контейнерами в общей инфраструктуре.
Поскольку KubeVirt был создан для виртуальных машин, исполняющих Kubernetes, это означает, что организации, использующие KubeVirt, остаются зависимыми от поставщиков хранилищ, которые поддерживают Container Storage Interface (CSI). По данным Gartner, по состоянию на январь 2025 года среди перечисленных драйверов CSI:
— 54% не поддерживают моментальные снимки.
— 49% не поддерживают чтение/запись в несколько модулей.
— 57% не поддерживают расширение.
Требования CSI могут нарушить работу многих сред хранения, использующих множество общих функций, таких как моментальные снимки и расширение. Это резко контрастирует с традиционными решениями для хранения в виртуальных средах, будь то на основе внешнего или программно-определяемого хранилища. Проверенные, фактические API позволили поставщикам хранилищ последовательно разгружать функции хранения для виртуальных рабочих нагрузок. Примерами служат клонирование, миграция, предоставление, восстановление и контроль доступа.
По словам Майкла Уоррилоу, вице-президента и аналитика Gartner, «большинство предприятий, скорее всего, обнаружат, что повторная виртуализация существующих производственных виртуальных рабочих нагрузок будет наиболее технически сложной, рискованной и труднооправданной задачей как минимум до 2028 года».
Интеграция с системами хранения не является функцией реализации KubeVirt по умолчанию. Без стандартизированного элемента хранения, который присоединяется к KubeVirt или является стандартным для него, различные поставщики хранилищ могут или не могут легко работать с ним или предлагать его поддержку.
Хотя организации могут управлять существующими виртуальными машинами с помощью KubeVirt, возможности управления минимальны и ограничиваются базовым администрированием гипервизора. Виртуальные машины продолжают существовать в инфраструктуре, но KubeVirt не хватает многих расширенных функций управления эксплуатацией и жизненным циклом, которые предоставляют платформы виртуализации корпоративного уровня.
Повышение навыков
Организации продолжают полагаться на виртуальные машины, поскольку они предлагают простоту эксплуатации, доказанную эффективность и более низкую совокупную стоимость владения (TCO). Кроме того, существующий кадровый резерв лучше соответствует управлению VM; найм квалифицированных специалистов в традиционных средах VM остается значительно проще, чем поиск эквивалентных экспертов в контейнерных или собственных инфраструктурах Kubernetes.
По сравнению с традиционными платформами VM, Kubernetes вносит значительно больше эксплуатационной сложности. Этот архитектурный сдвиг создает существенное трение, поскольку он требует от организаций отхода от устоявшихся практик управления VM и перехода к подходу, ориентированному на Kubernetes. Хотя Kubernetes предлагает мощные возможности оркестровки, он также требует совершенно нового набора навыков. Администраторы виртуальной инфраструктуры должны пройти переподготовку, а организации должны переподготовить целые команды для управления существующими рабочими нагрузками VM через новую плоскость управления, такую как KubeVirt.
Сегодняшние операции виртуальных машин поддерживаются зрелыми инструментами оркестровки, расширенными функциями и усиленными фреймворками безопасности и соответствия. Внедрение виртуальных машин в среду Kubernetes через KubeVirt потребует от организаций пересмотреть свои инструменты и значительно переподготовить технические команды — усилия, которые влекут за собой значительные затраты и эксплуатационный риск. Таким образом, обоснование запуска виртуальных машин внутри кластеров Kubernetes с использованием KubeVirt остается ограниченным весьма специфическими вариантами использования и не рекомендуется для общего корпоративного внедрения.
Для организаций в регулируемых или критически важных секторах, таких как банковское дело, федеральные, государственные и местные органы власти, коммунальные службы или розничная торговля, риски, связанные с принятием такой зарождающейся технологии, как KubeVirt, значительны. В отличие от лидеров технологий, таких как NVIDIA, Google или Meta, которые имеют внутренние инженерные возможности для настройки и поддержки инструментов с открытым исходным кодом, большинство предприятий не оснащены для самостоятельного управления этим уровнем технической сложности.
KubeVirt специально создан для сред Kubernetes, однако требования к корпоративному внедрению остаются значительными. Платформа работает на основе предположения, что все рабочие нагрузки в конечном итоге будут перенесены в Kubernetes. Однако такие переходы редко происходят немедленно; даже обновления между версиями Kubernetes могут занять несколько месяцев — или, в некоторых случаях, лет.
«Это очевидный пробел в навыках, который необходимо будет преодолеть для успешного внедрения KubeVirt, будь то для производства или нет. Многие существующие сотрудники I&O не будут иметь навыков и опыта в современных облачных инструментах и методологиях», — пишет Уоррилоу. «Внедрение DevOps требует значительных инвестиций как в технологии, так и в обучение, что, как оказалось, является препятствием для широкого внедрения. KubeVirt заставит это изменить».
Эта точка зрения согласуется с наблюдениями Gartner, которая отметила, что такие поставщики, как Red Hat с ее платформой OpenShift, приняли KubeVirt в качестве стратегического входа на рынок управления виртуальными машинами. Разработка зрелой платформы управления виртуальными машинами корпоративного уровня обычно требует многих лет, если не десятилетий, постоянного проектирования и операционного совершенствования, независимо от того, является ли решение открытым исходным кодом или проприетарным.