Примечание переводчика: недавно Дин Льюис, который много лет проработал в компании VMware, написал отличную сравнительную статью о технологиях виртуализации, где рассказал о KubeVirt и его отличиях от привычного многим vSphere. Мы решили перевести этот фундаментальный труд для хабрасообщества. Советуем тем, кто задумывался об оркестрации ВМ средствами Kubernetes, но ещё не погружался в специфику такого варианта. 

Как администратор vSphere, вы построили свою карьеру на доскональном понимании инфраструктуры: датасторов, кластеров DRS, виртуальных коммутаторов (vSwitch) и HA-конфигураций. Вы привыкли управлять виртуальными машинами в больших масштабах. И вот вы слышите о KubeVirt. Он обещает оркестрацию виртуальных машин средствами Kubernetes, но есть один нюанс: нужно хорошо разбираться в самом Kubernetes. 

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

Содержание

• Что такое KubeVirt

• KVM + QEMU: стек гипервизора

• Хранилище: PVC, блочный режим и живая миграция

• Сети: Multus, режим моста и сеть подов

• Жизненный цикл ВМ: создание, запуск и использование

• Эксплуатация и поддержка: что меняется?

• Open Source- или Enterprise-поддержка: что учесть при реальном развёртывании

• Подводим итоги

Что такое KubeVirt?

KubeVirt — это расширение для Kubernetes, которое позволяет запускать обычные виртуальные машины внутри кластера Kubernetes, используя те же механизмы оркестрации, что и для контейнеров. Под капотом задействованы KVM (Kernel-based Virtual Machine, виртуальная машина на основе ядра) и QEMU для запуска ВМ (подробнее об этом ниже).

Kubernetes не заменяет гипервизор, он им управляет. Можно представить, что Kubernetes в данном случае — это эквивалент vCenter: оркестратор отвечает за управляющий слой, сеть, планирование и интерфейсы хранилищ для виртуальных машин. В свою очередь KubeVirt добавляет в кластер новый тип ресурсов — «виртуальные машины».

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

Основные компоненты vSphere и их аналоги в KubeVirt

KVM + QEMU: стек гипервизора

В то время как vSphere использует свой гипервизор ESXi, в котором модули ядра и управляющие демоны тесно связаны, KubeVirt полагается на стандартный для Linux набор технологий виртуализации: KVM, QEMU и libvirt.

Вот роль каждого компонента:

• KVM — модуль ядра Linux, который пробрасывает расширения виртуализации (Intel VT-x или AMD-V) в пространство пользователя (userspace). Благодаря этому виртуальные машины работают быстро, используя аппаратные ресурсы напрямую.

• QEMU — эмулятор в пространстве пользователя и монитор виртуальных машин. Вместе с KVM запускает операционные системы внутри виртуальных машин. 

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

• Libvirt — демон и одновременно слой абстракции API, который управляет QEMU и KVM. Libvirt берёт на себя задачи по запуску, остановке, миграции и настройке виртуальных машин.

На каждом узле libvirt выступает как уровень оркестрации — по сути это похоже на то, как работают hostd или vpxa на хостах ESXi. В модели KubeVirt пользователи не работают с libvirt напрямую; им управляют компоненты KubeVirt через демон virt-handler.

                     Kubernetes Node (Worker Node)
+---------------------------------------------------------------+
|                      KubeVirt Components                      |
|                                                               |
|  +------------------+       +------------------------------+  |
|  |   virt-handler    | <--->|         libvirtd daemon      |  |
|  +------------------+       +------------------------------+  |
|           |                            |                      |
|           |                            v                      |
|           |                   +------------------+            |
|           |                   |    QEMU Process   |           |
|           |                   | (inside pod via   |           |
|           |                   |  virt-launcher)   |           |
|           |                   +------------------+            |
|           |                            |                      |
|           |                            v                      |
|           |                    Hardware Virtualization        |
|           |                        (via KVM)                  |
+---------------------------------------------------------------+

Каждая виртуальная машина работает внутри специального пода, называемого virt-launcher, который запускает процесс QEMU. Этот процесс локально на узле взаимодействует с библиотекой libvirt. Компонент virt-handler осуществляет связь с Kubernetes и управляет жизненным циклом виртуальных машин (VMI), отдавая команды libvirt.

Процесс запуска виртуальной машины в KubeVirt выглядит следующим образом:

1. В Kubernetes создаётся ресурс VirtualMachine.

2. virt-controller обнаруживает этот ресурс и создаёт под virt-launcher на одном из узлов кластера.

3. После того как под virt-launcher размещён на узле, virt-handler берёт на себя дальнейшие действия и через libvirt запускает процесс QEMU внутри этого пода.

4. KVM обеспечивает процессу QEMU доступ к необходимым аппаратным ресурсам.

Libvirt также отвечает за реализацию таких функций, как живая миграция, создание снимков состояния (snapshots) и привязка вычислений к конкретным ядрам CPU (CPU pinning). Однако для использования в нативном для Kubernetes стиле они должны быть проброшены через API KubeVirt. Libvirt выступает в роли «операционного бэкенда гипервизора» для KubeVirt подобно тому, как ESXi выполняет операции на уровне хоста от имени vCenter.

Как администратор vSphere, вы можете рассматривать libvirt как нижележащий интерфейс гипервизора, который KubeVirt инкапсулирует и контролирует, абстрагируясь от прямого взаимодействия с гипервизором в пользу нативных для Kubernetes API и воркфлоу.

Примечание переводчика: автор допускает неточность. Libvirt запускается в каждом поде с виртуальной машиной. Libvirt, QEMU и монитор этих процессов virt-launcher работают в одном контейнере внутри одной cgroup’ы. 

Хранилище: PVC, блочный режим и живая миграция

В VMware vSphere управление хранилищем реализуется через абстракции вроде датасторов (datastores) (VMFS, NFS, vSAN), а виртуальные диски представляют собой .vdmk-файлы. Эти диски подключаются к виртуальным машинам, а управление их доступностью, производительностью и политиками осуществляется с помощью механизма управления хранилищем на основе политик (Storage Policy-Based Management, SPBM). Кроме того, подразумевается, что хранилище доступно всем хостам в кластере — это необходимо для vMotion (живой миграции) и высокой доступности (HA).

KubeVirt использует принципиально иной подход к хранилищу виртуальных машин. Вместо монтирования датасторов на уровне гипервизора KubeVirt опирается на стандартную для Kubernetes модель постоянных томов (PersistentVolumes, PV) и запросов (PersistentVolumeClaims, PVC). Эти абстракции описывают, каким образом ресурсы хранилища запрашиваются и используются различными рабочими нагрузками, в том числе и виртуальными машинами. Базовый том может быть блочным устройством или файлом, выделяться статически или динамически и управляться любым совместимым с Kubernetes драйвером CSI (Container Storage Interface).

Драйвер CSI в Kubernetes выступает в роли связующего звена между Kubernetes и конкретной системой хранения данных. Именно он предоставляет Kubernetes необходимую логику для динамического выделения томов, их подключения к подам (в том числе виртуальным машинам через KubeVirt) или отключения от них, а также для выполнения операций по управлению жизненным циклом томов, например для изменения их размера или создания снимков.

С точки зрения vSphere, CSI-драйвер аналогичен тому, как API от VMware, предназначенные для работы с хранилищами (VAAI, VASA), взаимодействуют с датасторами, дисковыми массивами и управлением хранилищем на основе политик (SPBM) vSphere. Подобно тому, как vSphere полагается на поставщиков хранилища (например, поставщиков VASA для vSAN, Pure или NetApp) для фоновой оркестрации операций с томами, Kubernetes использует CSI-драйверы для стандартизации операций с хранилищем между различными вендорами. Каждый CSI-драйвер обеспечивает доступ к таким фичам, как динамическое выделение, расширение томов и создание снимков (конечно, в зависимости от того, что поддерживает нижележащая система хранения). При развёртывании KubeVirt выбор и конфигурация CSI-драйвера являются критически важными для обеспечения производительности виртуальных машин, живой миграции и стратегий защиты данных.

Сопоставление концепций

Примечание автора: в контексте хранилищ Kubernetes ReadWriteOnce (RWO) подразумевает, что том может быть смонтирован для чтения и записи только одним узлом кластера в каждый момент времени. Это стандартное поведение для большинства бэкендов хранения блочного типа. Режим ReadWriteMany (RWX) позволяет монтировать том для чтения и записи одновременно несколькими узлами. Такая возможность важна для сценариев вроде живой миграции виртуальных машин в KubeVirt, когда и исходному, и целевому узлу требуется параллельный доступ к диску ВМ.

Доступ ВМ к хранилищу в KubeVirt

Определяя VirtualMachine в KubeVirt, вы подключаете к ней тома, запрошенные через PVC (PersistentVolumeClaims). Эти PVC привязаны к PV (PersistentVolumes), которые представляют реальные диски в бэкенде хранилища (будь то iSCSI, Ceph RBD, NFS, Fibre Channel, Portworx или другое CSI-совместимое хранилище).

Тома монтируются внутри пода virt-launcher и после этого предоставляются процессу QEMU в виде виртуальных дисков (VirtIO или SATA — в зависимости от настроек). Похоже на то, как VMDK добавляются к SCSI/SATA-контроллеру виртуальной машины в vSphere.

Живая миграция: что поменялось

В vSphere технология миграции vMotion позволяет перемещать работающую ВМ между узлами кластера, поскольку все хосты ESXi в кластере имеют доступ к одному и тому же общему хранилищу и общей сети. При этом сам файл диска VMDK перемещать не нужно — между хостами передаётся только состояние памяти и устройств ВМ. (Стоит отметить, что есть нюансы, например, когда нет общего хранилища.) По сути, те же концепции используются и в KubeVirt, но требуют более явной настройки.

Что нужно для живой миграции в KubeVirt:

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

• PVC должны поддерживать:

  • либо режим доступа ReadWriteMany (RWX) — обычно используется для общих томов CephFS, NFS или Portworx;

  • либо блочные тома (volumeMode: Block) — обычно это Ceph RBD или raw-iSCSI-тома.

Если PVC использует режим файловой системы по умолчанию и поддерживает только ReadWriteOnce (RWO), провести живую миграцию не получится, поскольку целевой узел не сможет примонтировать том, пока тот используется.

Типовые топологии хранилищ в KubeVirt

Как и в кластерах vSphere, которые, как правило, проектируются с учётом использования общих датасторов VMFS, NFS или vSAN, KubeVirt также требует тщательного планирования того, как хранилище будет предоставляться кластеру Kubernetes и его узлам. Далее рассматриваются несколько основных топологий хранилищ, применяемых в KubeVirt, с описанием их плюсов, минусов и практических соображений.

1. Общая файловая система (RWX), например NFS, CephFS

Эта топология аналогична подключению NFS-датастора ко всем хостам ESXi. Общая POSIX-файловая система (соответствует стандартным правилам UNIX для файловых операций в части разрешений, блокировок и обработки файлов, обеспечивая совместимость между разными системами) монтируется и используется одновременно несколькими узлами кластера.

Для Kubernetes том предоставляется в режиме ReadWriteMany (RWX). Это позволяет проводить живую миграцию ВМ и осуществлять доступ к нему из нескольких подов.

• Сценарии использования: простое резервное копирование на уровне файлов, поддержка живой миграции, многоузловой доступ.

• Плюсы: легко настраивается, поддерживает снимки состояния, совместима с большинством бэкендов хранения.

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

2. Совместно используемое блочное хранилище (RWX через CSI), например Portworx, OpenEBS Mayastor, Ceph RBD с поддержкой RWX

В этом случае бэкенд хранилища предоставляет распределённое блочное хранилище, доступное с нескольких узлов. Само нижележащее блочное устройство может реплицироваться в рамках кластера, а за синхронизацию отвечает драйвер CSI. В зависимости от возможностей CSI поддерживаются режимы тома RWX и Block.

• Сценарии использования: stateful-виртуальные машины с высокой доступностью, живая миграция ВМ с подключёнными блочными устройствами, обеспечение отказоустойчивости (Fault Tolerance).

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

• Минусы: нужен драйвер CSI, поддерживающий RWX или репликацию, более сложная настройка.

3. Блочное хранилище (режим RWO + Block), например Ceph RBD, iSCSI 

Эта конфигурация похожа на использование Raw Device Mappings (RDM) в vSphere. В каждый момент времени том представляется одному узлу как raw-блочное устройство c volumeMode: Block. При этом всё ещё поддерживается живая миграция, если хранилище поддерживает multi-attachment, так как том не монтируется с файловой системой и может передаваться между узлами. 

• Сценарии использования: высокопроизводительные нагрузки, виртуальные машины с базами данных или те, которым нужна живая миграция без режима RWX.

• Плюсы: низкий оверхед, не нужно управлять файловой системой, хорошо подходит для ВМ с высоким IOPS.

• Минусы: только один узел может получить доступ в каждый момент времени. Миграция зависит от совместимости используемого хранилища.

4. Локальное хранилище (RWO + файловая система), например HostPath, LVM, локальные диски

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

• Сценарии использования: dev/test-кластеры, рабочие нагрузки, не требующие миграции или высокой доступности.

• Плюсы: простота развёртывания, хорошая производительность, отсутствие внешних зависимостей.

• Минусы: отсутствие живой миграции, отсутствие высокой доступности, потеря данных при сбое узла.

Ручная миграция ВМ, которая использует локальное хранилище

Если ВМ в KubeVirt использует локальное хранилище (RWO + файловая система), живая миграция невозможна, поскольку данные привязаны к конкретному узлу. Мигрировать ВМ на другой узел можно вручную с определённым периодом простоя в момент обслуживания:

1. Остановите ВМ. Корректно завершите работу экземпляра VirtualMachineInstance (VMI), чтобы гарантировать целостность данных на диске.

virtctl stop vm-name

2. Создайте резервную копию или скопируйте диск ВМ. Вручную скопируйте данные PVC с исходного узла в место, доступное для целевого узла. Возможные способы:

• Используйте kubectl cp, если доступен HostPath.

• Используйте rsync или scp для прямого копирования файлов образов дисков (например, qcow2 или raw) между узлами.

3. Воссоздайте PVC на целевом узле. Создайте новый PVC, указывающий на новый локальный путь на целевом узле. Убедитесь, что параметр nodeAffinity привязывает PVC к этому узлу.

5. Объектное хранилище для шаблонов/импорта, например S3, MinIO

Объектное хранилище напрямую не используется для корневых дисков ВМ, но часто задействуется вместе с CDI (Containerized Data Importer) для импорта образов ВМ, снимков или ISO. Считайте его аналогом библиотеки vSphere Content Library или хранилища образов.

• Сценарии использования: управление шаблонами, загрузочные ISO-носители, клонирование ВМ.

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

• Минусы: необходима интеграция с CDI, медленнее при необходимости быстрого доступа к «горячим» данным.

Рекомендация по проектированию хранилища

В vSphere проектирование хранения данных фокусируется на разделении их по уровням производительности и избыточности. В KubeVirt это также справедливо, однако необходимо дополнительно учитывать, как хранилище взаимодействует с примитивами Kubernetes, такими как запросы на выделение томов (volume claims), режимы доступа и возможности драйверов CSI. Не все варианты СХД поддерживают volumeMode: Block или режим ReadWriteMany. Топология должна соответствовать операционным задачам, особенно если планируется использовать живую миграцию или автоматическое перепланирование.

Прочие соображения и примечания

• StorageClass определяет, как выделяются ресурсы. Здесь настраиваются тонкие диски (при которых пространство выделяется по мере фактической необходимости), расширение томов и ограничения по IOPS, подобно политикам SPBM в vSphere.

• CDI (Containerized Data Importer) часто используется для импорта образов дисков ВМ (например, QCOW2, ISO) в PVC. Это аналог клонирования шаблона или развёртывания из OVA-файла.

• Снимки доступны, если их поддерживает драйвер CSI, — с ними можно делать резервные копии или деплоить ВМ на основе шаблонов.

• Горячее добавление и удаление дисков поддерживается для VMI через patch-операции Kubernetes, хотя не все комбинации СХД корректно их обрабатывают.

Хранилище — резюме

В vSphere хранилище абстрагировано и хорошо интегрировано в стек виртуальной инфраструктуры, предлагая богатый пользовательский интерфейс и надёжную автоматизацию. В KubeVirt управление хранилищем более явное и проходит через Kubernetes. Вы выигрываете в гибкости, портативности и интеграции с GitOps-процессами, платя за это необходимостью внимательно выбирать подходящие accessMode и volumeMode для конкретного сценария использования.

Если требуются живая миграция, высокая доступность или динамическое масштабирование, крайне важно выбрать и должным образом настроить подходящий вариант в StorageClasses и PVC. Модель хранилища KubeVirt предлагает возможности, аналогичные vSphere, но при этом раскрывает больше низкоуровневых механизмов (что оценят платформенные инженеры).

Сети: Multus, режим моста и сеть подов

В vSphere сетевое взаимодействие строится вокруг виртуальных коммутаторов (vSwitches), групп портов, сегментов с поддержкой VLAN и распределённых коммутаторов, управляемых посредством vCenter и, при необходимости, NSX. Каждой виртуальной машине выделяется один или несколько виртуальных сетевых интерфейсов (vNIC), которые подключаются к группам портов, соответствующим физическим или оверлейным сетям. KubeVirt применяет аналогичную модель, но она базируется на сетевых примитивах Kubernetes и предлагает повышенную гибкость (и сложность) благодаря плагинам вроде Multus.

Сетевое взаимодействие в VMware и KubeVirt: сравнение фич

Сеть подов по умолчанию (eth0)

Каждый под в Kubernetes, включая виртуальные машины KubeVirt, по умолчанию получает сетевой интерфейс, подключённый к дефолтному CNI (Container Network Interface) кластера. Обычно это Calico, Cilium, Flannel или OVN-Kubernetes. Этот интерфейс, который обычно называется eth0, подключает виртуальную машину к тому же сетевому пространству имён, что и поды Kubernetes.

• Сценарий использования: виртуальные машины, которые взаимодействуют с сервисами внутри кластера Kubernetes (например, микросервисами, DNS, Ingress-контроллерами). Подключение к Kubernetes CNI обычно позволяет использовать все возможности CNI как для контейнеров, так и для виртуальных машин.

• Сравнение с vSphere: аналогично подключению виртуальной машины к стандартному vSwitch без тегирования VLAN; предназначено исключительно для внутреннего трафика, если тот явно не маршрутизируется наружу.

Multus: вторичные сети

Multus — метаплагин CNI для Kubernetes, который позволяет поду (и, следовательно, ВМ) подключаться к нескольким сетям. Именно так ВМ подключается к внешним или изолированным сетям, помимо сети подов по умолчанию. Каждая дополнительная сеть определяется в NetworkAttachmentDefinition, ссылающийся на конкретный плагин CNI (например, macvlan, SR-IOV, bridge или host-device).

• Сценарий использования: подключение ВМ к внешним сетям L2/L3, VLAN или к legacy-инфраструктуре.

• Сравнение с vSphere: эквивалентно назначению ВМ нескольких виртуальных сетевых адаптеров (vNIC) в различных группах портов на разных vSwitch'ах или сегментах NSX.

Bridge Binding

Режим моста (Bridge mode) позволяет напрямую подключать ВМ к сетевому интерфейсу хоста посредством бридж-устройств Linux. Этот метод часто применяется в bare-metal-кластерах, где физический сетевой адаптер (NIC) подключается к ВМ через мост, предоставляя доступ на уровне L2 к физическим сетям.

• Преимущества: простота, отсутствие оверлейных сетей. ВМ в физической сети выглядят как нативные устройства.

• Недостатки: отсутствие изоляции на уровне пространств имён. Требуется продуманная настройка IPAM.

• Сравнение с vSphere: аналогично назначению ВМ стандартной группе портов на vSwitch, связанном с физическим сетевым адаптером.

SR-IOV: высокопроизводительная сеть

Для рабочих нагрузок с низкими задержками или высокой пропускной способностью KubeVirt поддерживает SR-IOV (Single Root I/O Virtualization). В этом режиме физические сетевые адаптеры разделяются на виртуальные функции (Virtual Functions, VF), которые назначаются напрямую к ВМ. Это позволяет обойти обработку трафика на уровне ядра и виртуального коммутатора — производительность становится почти нативной.

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

• Требования: сетевые адаптеры с поддержкой SR-IOV, соответствующие драйверы ядра, а также надлежащая конфигурация на хосте и в Kubernetes.

• Сравнение с vSphere: сходно с применением технологии сквозного доступа DirectPath I/O или сетевого адаптера VMXNET3 с активированной поддержкой SR-IOV в ESXi.

Режимы masquerade, bridge и slirp

При настройке интерфейсов для ВМ выбирается способ привязки, который определяет, как интерфейс ВМ подключается к базовой сети пода.

Примечание переводчика: встроенная реализация режима привязки slirp считается устаревшей, взамен эта привязка вынесена в плагин Slirp.

Дополнительные соображения

• Управление IP-адресами (IPAM): ВМ, подключённые к дефолтной сети пода, как правило, автоматически получают IP-адрес посредством внутренней сетевой модели Kubernetes. По умолчанию применяется NAT (masquerade). Прямое статическое назначение IP-адресов в дефолтной сети представляет собой нетривиальную задачу без дополнительной настройки CNI. Для вторичных сетей, определённых через Multus, распределение IP-адресов осуществляется соответствующим плагином CNI (например, DHCP, статический IPAM или ручное конфигурирование адресов), что обеспечивает расширенный контроль для статических или маршрутизируемых сетевых архитектур.

• Файрвол: на ВМ распространяются сетевые политики (Network Policies) Kubernetes, если за их исполнением следит плагин CNI. В некотором смысле это похоже на группы безопасности NSX или правила DFW.

• Балансировка нагрузки: доступ к ВМ может быть организован посредством сервисов Kubernetes (ClusterIP, NodePort, LoadBalancer) или внешних Ingress-контроллеров.

Файрволы и микросегментация

В vSphere сетевая безопасность часто реализуется через правила распределённого файрвола NSX (DFW) или группы безопасности. Это позволяет администраторам задавать политики микросегментации для рабочих нагрузок, основываясь на тегах ВМ, группах портов и других метаданных.

В KubeVirt ВМ подчиняются сетевым политикам Kubernetes. Эти политики контролируют ingress- и egress-трафик подов (включая ВМ) на основе IP-адресов, пространств имён и лейблов. Однако не все плагины CNI применяют эти политики на уровне передачи данных (dataplane). Некоторые CNI интерпретируют политики как рекомендации, если явно не используется принудительный режим.

Cilium предлагает значительно более функциональную модель. Это единственный CNI, одобренный (graduated) CNCF, который следит за применением политик на уровне данных с помощью eBPF. Cilium поддерживает применение сетевых политик на уровнях L3–L7, включая полноценный файрвол с отслеживанием состояния соединений, «осведомленные» о DNS правила и инструменты для мониторинга. Пользователям NSX, привыкшим к детализированным наборам правил DFW и контролю трафика между ВМ в рамках одной сети East-West, Cilium предлагает наиболее близкий аналог этих возможностей в нативном для Kubernetes исполнении с дополнительным преимуществом в виде программируемости через GitOps и интеграции в пайплайны наблюдаемости.

Ключевые соображения:

• Если используется базовый CNI (например, Flannel), сетевые политики могут не применяться вовсе.

• OVN-Kubernetes поддерживает базовое применение политик, что ближе к традиционным файрволам на базе iptables.

• Cilium обеспечивает функциональность, максимально приближенную к NSX: распределённая stateful-безопасность с возможностью программирования и полным аудитом.

Сети: итог

В vSphere виртуальная сеть по большей части абстрагирована группами портов и аплинками, настраиваемыми через графический интерфейс. В KubeVirt эти абстракции приходится создавать вручную с помощью CRD-ресурсов Kubernetes и CNI-плагинов. Хотя порог вхождения выше, гибкость здесь огромна: можно строить сложные, программируемые сетевые топологии, используя лишь YAML- и Open Source-плагины. Освоив эту модель, вы сможете использовать подход «инфраструктура как код» для управления сетевым подключением и безопасностью ВМ, что не всегда доступно в традиционных гипервизорах напрямую.

Жизненный цикл ВМ: создание, запуск и использование

В vSphere управление жизненным циклом ВМ основано на интуитивных графических интерфейсах и воркфлоу через vCenter Server. Создание ВМ, изменение аппаратной конфигурации и управление шаблонами стандартизированы и просты.

KubeVirt предлагает схожие возможности, но реализуются они через YAML-манифесты, API Kubernetes и утилиты командной строки вроде kubectl и virtctl. Фундаментальные задачи остаются теми же, но процесс эксплуатации существенно отличается, требуя более декларативного, ориентированного на автоматизацию подхода.

Сравнение того, как стандартные операции жизненного цикла ВМ реализованы в vSphere и KubeVirt

В этом видео Майкл Ливан (Michael Leavan) показывает, как загрузить ISO-образ гостевой операционной системы в Containerized Data Importer, чтобы затем создать из него виртуальную машину.

Я включил его в статью, поскольку разобраться в том, как это работает, непросто; сами шаги не очень сложные, но они несколько отличаются от процедур в vSphere (хотя кто-то, вероятно, решит, что это похоже на использование ovatool для загрузки в датастор).

Как работают манифесты ВМ в KubeVirt

В KubeVirt ВМ не является «бинарным» файлом, как конфиг .vmx в VMware, а представляет собой декларативный YAML-манифест, хранящийся в базе данных etcd Kubernetes. Этот манифест описывает желаемое состояние ВМ: параметры CPU, памяти, дисков, сетевых интерфейсов, настройки cloud-init и другие. Манифесты можно версионировать, развёртывать с помощью GitOps-практик и динамически обновлять по мере необходимости.

Ниже приведён аннотированный пример на YAML, который поможет администраторам vSphere разобраться в эквивалентных концепциях:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: webserver-vm
spec:
  running: true          # То же самое, что установить в vSphere переключатель в "powered on" — ВМ будет автоматически запускаться после создания.
  template:
    metadata:
      labels:
        kubevirt.io/domain: webserver-vm
    spec:
      domain:
        cpu:
          cores: 2        # У ВМ будут два vCPU, как и аналогичный параметр в vSphere.
        devices:
          disks:
          - name: rootdisk
            disk:
              bus: virtio # Дисковый контроллер VirtIO — аналог SCSI/Paravirtual в VMware.
          interfaces:
          - name: default
            bridge: {}    # Подключить к сети пода по умолчанию — аналог базового доступа через vSwitch.
          - name: secondary-net
            bridge: {}    # Подключить к внешней сети через Multus — то же самое, что добавить второй vNIC к другой VLAN/portgroup.
        resources:
          requests:
            memory: 4Gi   # ВМ получит 4GB RAM — аналог настройки памяти ВМ в vSphere.
      networks:
      - name: default
        pod: {}           # Подключается к CNI-сети кластера по умолчанию, IP присваиваются автоматически.
      - name: secondary-net
        multus:
          networkName: multus-external-network  # Вторичная сеть от Multus — аналогично ещё одной группе портов — portgroup.
      volumes:
      - name: rootdisk
        persistentVolumeClaim:
          claimName: webserver-pvc # Корневой диск подключается через PVC — так же, как добавить VMDK из датастора.

Основные моменты для администраторов vSphere:

• CPU, память, диски и сетевые адаптеры явно определяются в YAML, подобно тому, как настраивается оборудование ВМ в vSphere Web Client.

• Сеть описывается декларативно: и интерфейсы, и сетевые источники должны быть определены и совпадать по имени.

• Каждый сетевой интерфейс привязан к своему типу сети (дефолтная сеть пода или сети, определённые Multus).

• Хранилище подключается через ссылку на PersistentVolumeClaim (PVC), который необходимо создать заранее или который может быть динамически выделен через StorageClass.

• Состояние вкл/выкл (эквивалент powered on/off в vSphere) управляется параметром running: true или running: false.

Примечание переводчика: параметр running считается устаревшим. Взамен предлагается определить стратегию управления питанием через параметр runStrategy и управлять состоянием ВМ через virtctl.

Пример: добавление нового сетевого интерфейса к работающей ВМ

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

kubectl patch vm webserver-vm --type='json' -p='[
  {
    "op": "add",
    "path": "/spec/template/spec/networks/-",
    "value": {
      "name": "secondary-net",
      "multus": {
        "networkName": "multus-secondary-net"
      }
    }
  },
  {
    "op": "add",
    "path": "/spec/template/spec/domain/devices/interfaces/-",
    "value": {
      "name": "secondary-net",
      "bridge": {}
    }
  }
]'

Этот изменение:

• подключает ВМ ко второй сети, заданной через Multus;

• создаёт новый мост внутри ВМ;

• аналогично добавлению vNIC, подключённого к другой группе портов.

Пример: увеличение диска ВМ (PVC)

Чтобы расширить диск ВМ в KubeVirt, нужно выполнить два действия:

1. Увеличить размер PersistentVolumeClaim (PVC), если используемый StorageClass допускает расширение томов.

2. Вручную инициировать изменение размера файловой системы внутри гостевой ОС.

kubectl patch pvc webserver-pvc --patch '
spec:
  resources:
    requests:
      storage: 40Gi
'

После изменения размера PVC нужно пересканировать и расширить раздел/файловую систему в гостевой ОС — точно так же, как вы сделали бы это в Linux- или Windows-ВМ после расширения VMDK в vSphere.

Смена операционной парадигмы

Для администраторов vSphere KubeVirt знаменует собой сдвиг от операций, управляемых через GUI, к API-ориентированному управлению и концепции «инфраструктура как код». Задачи вроде развёртывания ВМ или расширения хранилища по сути остаются прежними, однако инструменты и процессы серьёзно меняются. Внедрение GitOps, конфигураций в формате YAML и автоматизированных пайплайнов становится ключевым фактором для эффективной эксплуатации и поддержки (day-2 operations) в большом масштабе.

Инструментарий и взаимодействие с KubeVirt

В vSphere повседневные операции выполняются через пользовательский интерфейс vCenter, клиент vSphere или CLI-инструменты, такие как PowerCLI. В KubeVirt основные инструменты следующие:

• kubectl: стандартный инструмент командной строки Kubernetes. Используется для взаимодействия с ресурсами кластера, включая VirtualMachines, VirtualMachineInstances, PersistentVolumeClaims и другие CustomResourceDefinitions.

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

Примеры операций:

# Показать все объекты VirtualMachine (ВМ) (независимо от того, активны они или нет).
kubectl get vm

# Показать все активные объекты VirtualMachineInstance (VMI) (только работающие ВМ).
kubectl get vmi

# Запустить ВМ (перевести её из состояния "ВМ определена" в состояние "ВМ запущена").
virtctl start vm-name

# Подключиться к консоли работащей ВМ (доступ к серийной консоли).
virtctl console vm-name

# Провести живую миграцию работающей ВМ на другой узел в кластере.
virtctl migrate vm-name

Видео ниже от проекта KubeVirt показывает, как выглядит CLI-взаимодействие для запуска ВМ и управления ими в KubeVirt.

В видео демонстрируются следующие операции:

• создание ВМ из YAML и облачного образа;

• запуск ВМ;

• подключение через консоль и SSH к ВМ;

• подключение к ВМ через VNC;

• остановка и удаление ВМ.

Поскольку объекты KubeVirt являются стандартными ресурсами Kubernetes, управлять ими можно с помощью любых нативных инструментов Kubernetes. Это естественным образом приводит к применению GitOps-процессов:

• Описание ВМ в формате YAML: создавайте манифесты VirtualMachine декларативно, указывая конфигурацию CPU, оперативной памяти, хранилища и сетевых интерфейсов.

• Хранение в Git-репозитории: версионируйте манифесты ВМ наряду с прочими ресурсами кластера.

• Развёртывание через пайплайны: используйте GitOps-контроллер (например, ArgoCD, Flux) для автоматического применения изменений к кластеру Kubernetes после каждого коммита.

GitOps делает управление ВМ похожим на управление развёртываниями, ConfigMap'ами или сервисами Kubernetes, предоставляя пользователю полный аудит, возможность проводить код-ревью и откатывать изменения виртуальной инфраструктуры.

Администраторы vSphere могут рассматривать это как замену ручного создания ВМ или шаблонов vSphere на полностью автоматизированную систему управления жизненным циклом ВМ с контролем источников образов.

Совет автора: с GitOps можно автоматизировать не только создание ВМ, но и их обновление, миграцию и вывод из эксплуатации через pull-реквесты.

Во многом процессы на базе GitOps с KubeVirt повторяют то, что vRealize Automation (Aria Automation) реализует в окружениях vSphere: шаблонные манифесты ВМ, автоматизированные развёртывания, управление изменениями с версионированием и полный аудит.

Однако вместо графического дизайнера шаблонов ВМ управляются декларативно через YAML-файлы, которые хранятся в Git-репозиториях, а доставка запускается в рамках Git-процессов и CI/CD-пайплайнов.

В GitOps-модели инфраструктура по своей природе становится самовосстанавливающейся и самодокументируемой.

kubectl vs virtctl: когда какой инструмент лучше использовать

Эксплуатация и поддержка: что меняется?

Когда окружение KubeVirt запущено и работает, операции второго дня, включающие управление, обслуживание, мониторинг, устранение неполадок и масштабирование ВМ, значительно отличаются от тех, что приняты в vSphere. В то время как основные заботы (обеспечение доступности, производительности, резервного копирования и соответствия нормативам) остаются, инструменты, паттерны и операционные ожидания сильно отличаются.

Сравнение: операции второго дня в vSphere и KubeVirt

Мониторинг ВМ и инфраструктуры

В vSphere для унифицированного мониторинга и алертинга используются vCenter и vRealize (Aria) Operations Manager. В KubeVirt для обеспечения наблюдаемости требуется интеграция нескольких систем: 

• Метрики. Предоставляются компонентами KubeVirt (virt-controller, virt-handler, virt-launcher) через Prometheus.

• Логи. Собираются из логов подов (поды virt-launcher) и журнала systemd на узлах:

  • Необходимо также учитывать логи из самой ВМ (гостевой ОС).

• События. Поток событий Kubernetes крайне важен для выявления аномалий жизненного цикла ВМ (например, ошибок миграции).

Для VMI обычно создают дашборды в Grafana и настраивают кастомные алерты, отслеживая такие метрики, как:

• использование процессора и памяти внутри ВМ (гостевые метрики, при условии установки QEMU guest agent);

• доля успешных/неуспешных миграций;

• доступность узлов и загруженность ресурсов (например, дискового пространства, оперативной памяти, троттлинг CPU).

Диагностика и решение проблем с ВМ

В vSphere поиск неисправностей обычно сводится к просмотру уведомлений в vCenter, логов хостов ESXi и журналов событий самой ВМ. В KubeVirt диагностика затрагивает несколько слоев:

• Проблемы на уровне подов. Используйте kubectl describe pod virt-launcher-xxx и kubectl logs, чтобы разобраться со сбоями запуска контейнеров.

• Проблемы на уровне ВМ. Получите доступ к консоли ВМ через virtctl console <vm-name> или изучите логи cloud-init (если тот настроен).

• Проблемы на уровне узла. Проверьте логи virt-handler, статус KVM-устройства и доступность ресурсов на узле.

Типичная последовательность поиска неисправностей:

# Вывести список всех VirtualMachine, VirtualMachineInstance и подов в пространстве имён.
kubectl get vm,vmi,pod -n {namespace}

# Сделать describe VirtualMachineInstance (VMI), чтобы увидеть подробный статус, события и состояния.
kubectl describe vmi my-vm

# Получить логи из пода virt-launcher из контейнера 'compute', в котором работает процесс QEMU. 
kubectl logs virt-launcher-xxx -c compute

# Подключиться напрямую к серийной консоли ВМ для интерактивного поиска проблем внутри гостевой ОС.
virtctl console my-vm

Управление патчами и обновлениями

Если в vSphere для патчей и апгрейдов есть Update Manager с графическим интерфейсом, то в KubeVirt дела обстоят следующим образом:

• Узлы Kubernetes патчатся и обновляются через автоматизированные пайплайны. Как именно — зависит от платформы Kubernetes и/или способа развёртывания кластера (например, это может быть Kured, Cluster API, RKE2 или освобождение (drain) узла вручную с последующим обновлением).

• Сам KubeVirt обновляется через virt-operator с поочередным (rolling) перезапуском компонентов по всему кластеру.

• Чтобы виртуальные машины, поддерживающие живую миграцию, переехали с узла на время обновления, нужно либо запустить миграцию вручную, либо настроить дрейнинг узлов с помощью политик вытеснения (eviction policies), адаптированных для объектов VMI.

Безопасность и соответствие регламентам

Ответственность за обеспечение безопасности значительно меняется:

• RBAC: контролирует, кто может создавать, менять и удалять ВМ и все ресурсы, которые с ними связаны.

• Сетевая безопасность: за неё отвечают сетевые политики Kubernetes, которые можно дополнить сетевыми плагинами (CNI), например Cilium или OVN-Kubernetes.

• Шифрование данных: шифрование на томах (data at-rest encryption) — задача CSI-бэкенда хранилища, а не самого KubeVirt.

• Защита ВМ: осуществляется через настройки безопасности гостевой ОС, скрипты cloud-init или использование неизменяемых образов ВМ.

Конечно, это далеко не все тонкости, которые нужно учесть в плане безопасности.

Основные изменения в работе для администраторов vSphere

• Декларативный подход вместо императивного. Вместо использования мастеров для настройки желаемое состояние кластера описывается через YAML-манифесты; взаимодействие осуществляется посредством CLI, API или GitOps-платформы.

• Автоматизация в основе. «Инфраструктура как код» и GitOps-пайплайны становятся стандартом для управления жизненным циклом ВМ и инфраструктурных изменений.

• Ориентированное на кластер мышление. Отсутствует фокус на центральной точке входа для администрирования — vCenter; управление ресурсами осуществляется через API, а состояние узлов кластера напрямую влияет на запуск ВМ и их доступность.

• Многообразие инструментов. По умолчанию нет единой панели управления; задачи наблюдаемости (observability), резервного копирования и обеспечения безопасности решаются комбинацией различных Open Source-инструментов или их коммерческих аналогов.

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

Open Source- или Enterprise-поддержка: что учесть при реальном развёртывании

KubeVirt — проект с открытым исходным кодом, лицензируемый по Apache 2.0. В отличие от VMware vSphere, здесь нет встроенной коммерческой поддержки или соглашения об уровне обслуживания (SLA); основная поддержка осуществляется через форумы сообщества, email-рассылку, Issues на GitHub и публичные Slack-каналы.

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

Компаниям, которым нужна коммерческая поддержка, Red Hat предлагает OpenShift Virtualization — готовый к использованию в production дистрибутив KubeVirt, тесно интегрированный в OpenShift. Red Hat вносит значительный вклад в основной проект KubeVirt и дополняет его управлением жизненным циклом, продвинутым мониторингом, усиленными настройками безопасности по умолчанию и поддержкой с SLA.

Благодаря значительному участию Red Hat нововведения из upstream незамедлительно оказываются в их корпоративном продукте, что позволяет клиентам идти в ногу с планами сообщества. Другие вендоры также объединяют дистрибутивы Kubernetes с KubeVirt для рабочих нагрузок на базе ВМ, но Red Hat в настоящее время считается лидером рынка в этой сфере. Выбор корпоративного решения вроде OpenShift Virtualization открывает путь к управлению ВМ нативным для Kubernetes образом без отказа от операционных гарантий, которые организации ожидают от традиционных платформ вроде vSphere.

Совет автора: Red Hat OpenShift Virtualization скрывает большую часть сложности Kubernetes и KubeVirt за удобным графическим интерфейсом, мощной автоматизацией и сертифицированными интеграциями. Это идеальный вариант для команд, переходящих с VMware и ищущих преемственность в операционной деятельности. Однако, по моему опыту, большинство пользователей OpenShift не пользуются графическим интерфейсом.

Подводим итоги

KubeVirt предлагает принципиально иную операционную модель для виртуализации, глубоко интегрированную в нативный облачный подход Kubernetes к управлению инфраструктурой. Для администраторов vSphere это открывает новые возможности, но и представляет некий вызов: привычные концепции, такие как вычислительные ресурсы, хранилище и сеть, сохраняются, однако процессы, инструментарий и уровни абстракции смещаются в сторону декларативных, управляемых через API моделей. Осознание этих различий является ключевым фактором для принятия взвешенного решения о внедрении KubeVirt параллельно с традиционными окружениями vSphere или в качестве их замены.

VMware vSphere: плюсы и минусы

Плюсы:

• Проверенная временем платформа корпоративного уровня с глубокой интеграцией в экосистему (vRealize (Aria), NSX, Tanzu, VCF).

• Удобный графический интерфейс с простым и понятным управлением.

• Богатый набор фич: высокая доступность, DRS, vMotion, шифрование виртуальных машин, снимки, планирование ресурсов.

• Большая база знаний по работе с системой и сильная поддержка от вендора.

• Надёжные инструменты для резервного копирования, мониторинга и управления жизненным циклом.

Минусы:

• Высокая стоимость лицензий и эксплуатации, особенно после изменений, последовавших за покупкой компанией Broadcom.

• Платформа хуже подходит для современных рабочих процессов, ориентированных на контейнеры и GitOps.

• Масштабирование (например, кластеры, апгрейды) не такое «эластичное», как у систем на основе Kubernetes.

Примечание переводчика: а также к минусам можно отнести переход на подписную модель лицензирования и уход компании из России.

KubeVirt: плюсы и минусы

Плюсы:

• Полностью интегрирован в Kubernetes; обеспечивает унифицированное управление виртуальными машинами и контейнерами на единой платформе.

• Открытый исходный код, легко расширяется и не требует больших затрат; не нужно платить за лицензии на проприетарные гипервизоры.

• Работает с подходами «инфраструктура как код», GitOps и моделями эксплуатации, «заточенными» под автоматизацию.

• Можно использовать нативные для Kubernetes инструменты для наблюдаемости, политики безопасности и динамическое масштабирование.

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

Минусы:

• Пока ещё в процессе развития по сравнению с vSphere, у которой были годы для создания фич enterprise-уровня и множества готовых интеграций.

• Более высокая сложность эксплуатации; предполагает наличие глубоких знаний и навыков работы с Kubernetes.

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

• Ограниченный набор GUI-инструментов; процессы преимущественно основаны на YAML и API.

О чём стоит подумать перед сменой платформы

• Оцените уровень компетенций организации в Kubernetes. KubeVirt предполагает знакомство с операторами Kubernetes, пользовательскими ресурсами (CRD), YAML-манифестами и API-операциями.

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

• Запланируйте переход на новые операционные инструменты. Мониторинг, резервное копирование, безопасность и управление жизненным циклом придётся переделывать под Kubernetes.

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

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

В конечном итоге ваш опыт работы с vSphere — отличная отправная точка для освоения и успешного использования KubeVirt. Инструменты управления, процессы и сами подходы могут отличаться, однако основные принципы — планирование рабочих нагрузок, распределение ресурсов, сеть, хранилище и высокая доступность — выглядят вполне знакомо. При должной подготовке и адаптации KubeVirt позволит перенести виртуализацию в будущее, ориентированное на Kubernetes, и сможет заменить платформу VMware, если у вашего бизнеса есть такая цель.

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

P. S. 

Читайте также в нашем блоге:

• KubeVirt: внутреннее устройство и сеть. Как достигнуть совершенства?

• Живая миграция, мониторинг и безопасность: дайджест обновлений Deckhouse Virtualization Platform 0.15–0.18 

• Эволюция технологий виртуализации сети в Linux