CNCF спонсировал этот пост.
Kubernetes зарекомендовал себя как основа современных контейнерных приложений, однако в корпоративных ИТ все чаще обсуждается вопрос о том, должен ли он также стать домом для виртуальных машин (ВМ). Речь идет не просто об объединении платформ. Он затрагивает более широкие вопросы навыков, ожиданий и миграции, которые сейчас формируют стратегические решения в залах заседаний и на отраслевых конференциях.
Возможность запуска виртуальных машин вместе с контейнерами в единой плоскости управления имеет явную привлекательность. Оно обещает операционную согласованность, потенциальную экономию средств и упрощенное представление инфраструктуры для команд платформы. Однако это сближение не лишено серьезных проблем. Этот сдвиг требует новых навыков, предъявляет новые требования к самому Kubernetes и порождает сложную проблему миграции.
Недостаток навыков для операторов виртуальных машин
Операторы, построившие свою карьеру на VMware, Hyper-V или Nutanix, интуитивно понимают такие понятия, как хранилища данных, группы портов и моментальные снимки. Эти конструкции тесно связаны с физическими серверами и традиционными ИТ-практиками. Kubernetes, напротив, требует нового мышления.
Поды эфемерны. Развертывания и службы определяют желаемое состояние. Сеть управляется политиками, а хранилище абстрагировано. Управление часто осуществляется через файлы YAML и API, а не через графические консоли. Как бывший администратор VMware, я привык перетаскивать виртуальные машины в vCenter; это не то, что инженер платформы даже подумал бы сделать со своими модулями. Для команд, привыкших к стабильному состоянию виртуальных машин, это может показаться дезориентирующим сдвигом.
Проект KubeVirt с открытым исходным кодом находится на переднем крае устранения этого пробела. Он расширяет возможности Kubernetes для управления виртуальными машинами почти так же, как и с контейнерами, предоставляя знакомые конструкции через Kubernetes API. Red Hat пошла дальше, выпустив отдельную лицензию на виртуализацию OpenShift, предназначенную для организаций, которые по-прежнему хотят использовать Kubernetes в качестве своей плоскости управления, но должны сосредоточиться на размещении виртуальных машин.
Интерес к этой теме очевиден. Мое собственное руководство по глубокому погружению «KubeVirt для администраторов vSphere» стало одним из моих самых читаемых постов, что свидетельствует о том, что операторы виртуальных машин активно ищут способы применить свои навыки в средах Kubernetes.
Разные ожидания от платформы Kubernetes
Запуск виртуальных машин в Kubernetes также меняет ожидания предприятий от самой платформы. Контейнеры спроектированы так, чтобы сохранять состояние и быть временными, в то время как виртуальные машины часто имеют состояние, долговечны и привязаны к постоянному хранилищу. Объединение этих двух моделей требует гибкости в планировании, хранении и управлении жизненным циклом.
Сеть иллюстрирует проблему наиболее четко. Рабочие нагрузки виртуальных машин часто зависят от статических IP-адресов, сетей VLAN и конструкций брандмауэра. Kubernetes предполагает плоскую сеть с динамической адресацией и сетевыми политиками. Примирение этих миров – нетривиальная задача.
Именно здесь вступают в разговор такие проекты, как Cilium. Cilium предлагает сетевую модель на базе eBPF, которая знакома операторам виртуальных машин, работавшим с такими решениями, как NSX. Он обеспечивает микросегментацию, видимость и элементы управления безопасностью, повторяющие функции традиционных платформ SDN виртуальных машин, но последовательно применяемые как к виртуальным машинам, так и к контейнерам. Для предприятий, изучающих эту конвергенцию, она демонстрирует, как сети Kubernetes могут развиваться, чтобы соответствовать ожиданиям, ориентированным на виртуальные машины, без фрагментации операционных моделей.
Дилемма миграции
Даже если Kubernetes сможет удовлетворить операционные потребности виртуальных машин, остается вопрос миграции. Перемещение рабочих нагрузок на платформу на базе Kubernetes предполагает гораздо больше, чем просто копирование дискового файла.
Виртуальные машины привязаны к настройкам, специфичным для гипервизора. Их диски часто находятся в собственных системах хранения. Их сетевое взаимодействие основано на конструкциях, которых может не быть в среде Kubernetes. Сопоставить все это с новым набором абстракций — серьезная задача.
Также важно признать, что мы вряд ли увидим массовую миграцию активов VMware. Большинство предприятий лишь недавно завершили реализацию программ виртуализации. Перенос каждой рабочей нагрузки в контейнеры может занять десятилетия, точно так же, как рабочие нагрузки мэйнфреймов и физических серверов все еще выполняются сегодня. Более реалистичным является выборочная миграция. Организации могут начать с более простых рабочих нагрузок: систем CI и сборки, пакетных заданий, веб-интерфейсов или определенных баз данных, где усилия по миграции оправданы.
Продавцы начинают внедрять инновации в этой области. Набор инструментов для миграции для виртуализации (MTV) Red Hat предоставляет основу для перемещения виртуальных машин в среды Kubernetes, выполняя многие задачи перевода, которые в противном случае пришлось бы выполнять вручную. Аналогичным образом, такие проекты, как изовалентный сетевой мост, представленный на Cisco Live 2025, направлены на упрощение сетевых переходов. Это позволяет перенесенным виртуальным машинам поддерживать связь с существующими средами центров обработки данных, уменьшая сбои, вызванные сменой платформ.
Эти инновации подчеркивают растущее признание того, что миграция — это не просто техническая задача, а стратегический барьер на пути внедрения. Предприятия не смогут полностью использовать Kubernetes в качестве дома для виртуальных машин до тех пор, пока процесс перемещения рабочих нагрузок не станет менее рискованным и более предсказуемым.
Что это значит для предприятий
Конвергенция виртуальных машин и контейнеров в Kubernetes — не абстрактная идея. Сегодня это живой разговор, формирующий стратегии на предприятиях. Лидеры платформ сопоставляют стоимость обслуживания отдельных инфраструктур со сложностью их объединения. ИТ-директора оценивают, действительно ли Kubernetes может служить универсальной основой для рабочих нагрузок или же он рискует оказаться обремененным слишком большим количеством обязанностей.
Эта тема будет доминировать в дискуссиях на таких конференциях, как предстоящая KubeCon North America 2025. Ожидайте услышать больше о таких проектах, как KubeVirt, достижениях в области сетевых технологий Kubernetes и развивающейся экосистеме инструментов миграции. За каждой из этих технических дискуссий стоит более глубокий вопрос: как предприятия согласовывают свой выбор инфраструктуры с более широкими целями цифровой трансформации, эффективности и устойчивости?
Для читателей, заинтересованных в дальнейшем изучении этой темы, сообщество KubeVirt поддерживает активную группу по особым интересам (SIG) и регулярно проводит телеконференции. Red Hat публикует обновления по OpenShift Virtualization и MTV, а сообщество Cilium регулярно публикует подробные обзоры сетевых достижений. Это ценные места, где можно наблюдать за лучшими практиками и извлеченными уроками.
Заключение
Kubernetes уже изменил способ доставки программного обеспечения в организациях. Следующим испытанием для компании может стать возможность взять на себя роль управления виртуальными машинами, объединяя старые и новые рабочие нагрузки на единой платформе. Задачи очевидны: переподготовка операторов, адаптация платформы к различным ожидаемым рабочим нагрузкам и переход к сложным конфигурациям, хранилищам и сетям.
Это немаловажные препятствия, однако они привлекают растущее внимание как со стороны сообществ разработчиков программного обеспечения с открытым исходным кодом, так и со стороны корпоративных поставщиков. Результат определит, останется ли Kubernetes контейнерной платформой или превратится в универсальную основу для корпоративных вычислений.
KubeCon + CloudNativeCon North America 2025 пройдет 10–13 ноября в Атланте, штат Джорджия. Зарегистрируйтесь сейчас.
Фонд Cloud Native Computing Foundation (CNCF) размещает критически важные компоненты глобальной технологической инфраструктуры, включая Kubernetes, Prometheus и Envoy. CNCF — это нейтральная площадка для сотрудничества, объединяющая ведущих разработчиков отрасли, конечных пользователей и поставщиков. Узнайте больше Последние новости от CNCF TRENDING STORIES YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Дин Льюис — старший технический руководитель в Isoвалентной компании, разрабатывающей облачное решение Cilium с открытым исходным кодом. Дин работал в различных областях технологий, от поддержки до эксплуатации, архитектурного проектирования и доставки у поставщиков ИТ-решений, базирующихся… Подробнее от Дина Льюиса
