Когда мы работаем с командами, переносящими виртуальные машины в Kubernetes, один из первых вопросов, который мы задаем, — кто именно занимается миграцией, так как ответ варьируется от компании к компании. В одних организациях команда платформы Kubernetes получает виртуальные машины «в наследство» и учится запускать то, что не является контейнером. В других решение принимает команда виртуализации, и именно она осваивает Kubernetes, будь то Red Hat OpenShift, Nutanix NKP, SUSE Rancher или другая платформа. Обычно это разные команды с разными привычками, и было бы ошибкой полагать, что специалисты по vSphere просто поглотят Kubernetes только потому, что виртуальные машины теперь переезжают туда.
Если вы работаете на стороне виртуализации, причина включиться в процесс сейчас заключается в том, куда движется развитие инфраструктуры. Все больше задач переносится в Kubernetes: там создаются нагрузки ИИ (AI workloads), растут базы данных и контейнеры с сохранением состояния (stateful), а виртуальные машины все чаще работают бок о бок с контейнерами, а не в отдельном изолированном окружении. Собственная платформа VMware указывает в том же направлении, поскольку VMware Cloud Foundation включает vSphere Kubernetes Service, так что даже команды, остающиеся на VMware, в итоге сталкиваются с Kubernetes на каком-то уровне стека.
В опросе 451 Research от S&P Global за 2026 год, 49% of organizations said they expect VMs and Kubernetes to coexist for the long term. Наши анонсы на KubeCon на этой неделе охватывают обе стороны этой картины: виртуальные машины и ИИ. На какой бы платформе Kubernetes ни остановилась ваша организация, администратор, понимающий обе стороны, получает право голоса в том, как будет происходить миграция, вместо того чтобы просто следовать плану, написанному кем-то другим.
Хорошая новость заключается в том, что перенос виртуальных машин в Kubernetes меняет повседневную работу меньше, чем ожидает большинство администраторов. Вы по-прежнему создаете системы из эталонных образов (golden images), делаете снимки (snapshots) перед установкой патчей, переносите нагрузки с хоста перед обслуживанием и рассчитываете на восстановление виртуальных машин после сбоя оборудования. Почти у каждой из этих задач есть прямой эквивалент в KubeVirt. Для большинства из них ошибка в деталях обходится дешево: манифест не проходит валидацию или консоль не подключается; вы исправляете это, и цена вопроса — час работы в лаборатории.
Несколько задач работают иначе, и, как правило, это те, что кажутся наиболее знакомыми. Снимок может завершиться без данных диска. Виртуальная машина, которую вы планировали перенести с помощью живой миграции (live migrate) во время обслуживания, может оказаться с дисками, которые не могут быть подключены к двум узлам одновременно. А вышедший из строя узел может оставить свои виртуальные машины в ожидании подтверждения того, что он действительно отключен.
Общим для этих задач является место, где определяются предварительные условия. В vCenter поддержка общего хранилища и снимков настраивалась при создании кластера, поэтому к моменту запуска виртуальных машин эти функции просто работали. В KubeVirt они привязаны к StorageClass, на основе которого были созданы диски каждой виртуальной машины. Таким образом, две виртуальные машины в одном кластере могут вести себя совершенно по-разному в одно и то же окно обслуживания, и ничто в самих виртуальных машинах не подскажет вам, в чем разница, пока вы не проверите их хранилище.
В примерах используется ванильный (upstream) KubeVirt — проект с открытым исходным кодом для запуска виртуальных машин в Kubernetes, который лежит в основе OpenShift Virtualization и других дистрибутивов, с использованием команд kubectl и virtctl. Некоторые аспекты зависят от дистрибутива, например, восстановление узлов (node remediation) и некоторые рабочие процессы миграции хранилища; в таких случаях в качестве примера приводится OpenShift.
Каков эквивалент каждой задачи vSphere Day-Two в KubeVirt?
Если классифицировать задачи по стоимости невыполненного предварительного условия, типичную неделю администратора vSphere можно разделить на три группы.
Большинство проблем можно решить в лаборатории, если что-то пойдет не так. Некоторые ошибки остаются незаметными до того дня, когда они вам понадобятся, а некоторые проявляются именно в тот момент, когда вы на них рассчитываете: во время окна обслуживания или сбоя узла.
Какие задачи vSphere наименее рискованны для изучения в KubeVirt?
Первую группу лучше всего изучать на практике. Шаблон (template) превращается в манифест VirtualMachine — YAML-файл, в котором указывается имя виртуальной машины, задается ее размер с помощью типа инстанса (instance type) и привязывается корневой диск к DataVolume, клонированному из эталонного образа. Дистрибутивы, такие как OpenShift Virtualization, поставляют эталонные образы для популярных гостевых операционных систем и позволяют добавлять собственные, а cloud-init или Sysprep берут на себя задачи, которые раньше выполняли спецификации настройки (customization specs). Если манифест составлен неверно, API отклонит его еще до запуска, так что исправление сводится к редактированию и повторной попытке.
Более серьезная перемена касается привычки работы с шаблонами. Шаблон, который раньше находился в инвентаре vCenter, становится файлом, который вы храните в Git, проверяете через pull request и сравниваете (diff), когда кто-то спрашивает, почему две виртуальные машины, которые должны быть идентичными, различаются. Это изменение обычно оправдывает себя в первый же раз, когда команде приходится пересобирать 50 виртуальных машин одинаковым способом.
Консоли, права доступа и размещение также не несут больших рисков. Команды virtctl console и virtctl vnc заменяют консоль vCenter, при условии, что гостевая система настроена на работу с последовательной консолью. Пулы ресурсов (resource pools) и папки превращаются в пространства имен (namespaces) с ResourceQuotas, а роли vCenter становятся ролями RBAC, привязанными к каждому пространству имен. Худшим последствием неточного сопоставления будет серия запросов на доступ после миграции. DRS разделяется на две части. Планировщик (scheduler) Kubernetes размещает виртуальную машину при запуске, используя запросы ресурсов (resource requests), селекторы узлов (node selectors) и правила соответствия (affinity), которые покажутся знакомыми тем, кто писал правила DRS. А депланировщик (descheduler) перераспределяет работающие виртуальные машины, вытесняя их с загруженных узлов для живой миграции в более спокойные места. Если депланировщик не настроен, виртуальные машины просто остаются на своих местах и продолжают работать.
На этом моменте простые задачи заканчиваются. Перебалансировка зависит от живой миграции, а каждая задача в двух других группах зависит от того, что позволяет или не позволяет делать хранилище, на котором размещена виртуальная машина.
Работают ли снимки (snapshots) KubeVirt так же, как снимки vSphere?
Снимки — это та задача, которая с наибольшей вероятностью может казаться выполненной успешно, даже если это не так. VirtualMachineSnapshot фиксирует конфигурацию виртуальной машины и, через снимки томов CSI (CSI volume snapshots), ее диски. Если StorageClass, на котором базируется диск, не поддерживает CSI VolumeSnapshots, KubeVirt все равно сохранит конфигурацию виртуальной машины. В результате объект снимка будет существовать, и процесс установки патчей продолжится, но данные диска так и не будут зафиксированы, о чем большинство команд узнает только во время восстановления.
Второе, что нужно проверить, — это гостевой агент. При запущенном QEMU guest agent KubeVirt «замораживает» гостевые файловые системы перед созданием снимка и «размораживает» их после, что обеспечивает согласованный (quiesced) снимок, к которому вы привыкли в VMware Tools. Без агента снимок будет согласованным только по сбою (crash-consistent), и в его статусе будет отметка NoGuestAgent. Оба условия легко проверить перед первым окном обслуживания: убедитесь, что VolumeSnapshotClass существует для каждого StorageClass, используемого вашими виртуальными машинами, и что агент запущен в гостевых системах, для которых планируется создание снимков.
Восстановление требует еще одного изменения в регламенте (runbook). В vSphere откат к снимку — это одно действие над виртуальной машиной. В KubeVirt вы останавливаете виртуальную машину, дожидаетесь завершения остановки, а затем применяете VirtualMachineRestore с указанием имени снимка. Таким образом, откат во время окна обслуживания включает время простоя, которое необходимо планировать, а также заранее принятое решение о том, кому разрешено останавливать рабочую виртуальную машину для выполнения отката.
Что требуется для живой миграции (live migration) в KubeVirt по сравнению с vMotion?
Live migration – это ситуация, когда пропущенное предварительное условие проявляется посреди окна обслуживания. virtctl migrate app01 переносит работающий VM на другой узел, а создание объекта VirtualMachineInstanceMigration делает то же самое в форме, которую можно автоматизировать.
Успех любого из них зависит от заявок на постоянные тома VM. KubeVirt only live migrates VMs whose PVCs use the ReadWriteMany (RWX) режим доступа, потому что оба узла должны иметь диск подключенным во время передачи, и он отклоняет запросы на миграцию для VM, которые не соответствуют требованиям. В vSphere совместное хранилище было свойством datastore и дизайна кластера. В KubeVirt оно принадлежит каждому PVC и задаётся StorageClass при выделении диска, что означает, что один кластер может содержать VM, которые мигрируют без проблем рядом с VM, которые не могут переместиться вовсе. Выполнение kubectl get pvc -n <namespace> и чтение столбца ACCESS MODES для каждой VM, которую вы планируете переместить, занимает несколько минут, и это стоит сделать до того, как первое окно обслуживания появится в календаре.
Сеть имеет собственное условие. VM, подключённая к сети pod с bridge binding, не может выполнять live migration, поэтому оставьте здесь привязку masquerade по умолчанию.
То же правило RWX регулирует режим обслуживания, который становится drain узла. kubectl drain <node> –ignore-daemonsets –delete-emptydir-data выгружает рабочие нагрузки узла, а VM с evictionStrategy: LiveMigrate перемещаются на другие узлы, пока продолжают работать. VM на RWO дисках не могут сделать этот переход, поэтому сценарий, где узел обслуживает оба типа, следует отработать в лаборатории до того, как вы полагаетесь на drain в продакшене. Если вы предпочитаете управлять cordon и drain как одним ресурсом, Node Maintenance Operator OpenShift делает это.
Есть ли эквивалент Storage vMotion для VM KubeVirt?
Перемещение дисков работающего VM на другое хранилище основано на live migration, поэтому всё, что выше о RWX, применимо и здесь. KubeVirt может мигрировать диски работающего VM в другой StorageClass: платформа выделяет новые тома в целевом классе, копирует данные, пока VM продолжает работать (параллельно выполняя live migration VM на другой узел), и переключает VM на новые тома. Это функция миграции томов, задаваемая updateVolumesStrategy: Migration на VM, а OpenShift Virtualization оборачивает эту же возможность в рабочий процесс миграции хранилища.
Две привычки Storage vMotion не переходят. Копирование проходит через хосты и конкурирует с I/O VM во время выполнения, поэтому оно заслуживает того же внимания к планированию, что и любая другая тяжёлая задача. Вторая привычка более тихая. Миграция не удаляет исходные тома после завершения, и они продолжают потреблять место, пока кто‑то не удалит старые PVC, поэтому очистка становится шагом, который нужно прописать в runbook, а не просто вспомнить позже.
Другая половина Storage vMotion – это знание, куда попадают диски. В vSphere datastore обычно означал конкретный массив, поэтому выбор одного указывал, куда попадут данные. Kubernetes StorageClass описывает свойства, такие как репликация и режим доступа, не указывая, какой массив находится под ним. Portworx® от Everpure заполняет эту пробел с помощью Kube Datastores, которые группируют хранилище по FlashArray™ системе и генерируют StorageClass для каждого массива, так что перемещение дисков VM на другой массив использует тот же рабочий процесс миграции хранилища с другим целевым классом. Процедура Portworx перемещает диски одного VM за раз, и каждый диск на VM должен использовать один и тот же тип тома RWX. Kube Datastores находятся в Directed Availability с Portworx Enterprise 3.7 на FlashArray Cloud Drives и требуют OpenShift Virtualization 4.18 или новее, поэтому уточните у вашей команды Portworx, прежде чем планировать их.
Как vSphere HA переводится в KubeVirt?
vSphere HA перезапускает VM с неудачного хоста самостоятельно, используя сетевые и datastore heartbeat, чтобы отличить изолированный хост от мёртвого. KubeVirt тоже может перезапустить VM в другом месте: установите runStrategy: Always на VM, и контроллер восстановит её, когда она неожиданно остановится. Разница в том, что происходит до перезапуска. Kubernetes не предполагает, что узел мёртв, только потому что он перестал отвечать, и VM на недоступном узле остаётся назначенной этому узлу, пока не подтвердится, что узел действительно down, потому что запуск второй копии, пока первая может всё ещё писать на тот же диск, приводит к повреждению данных.
Подтверждение приходит от механизма ремедиации, и детали зависят от вашего дистрибутива. В OpenShift Node Health Check Operator наблюдает за нездоровыми узлами и передаёт их Self Node Remediation или Fence Agents Remediation, которые перезагружают или выключают узел, чтобы его VM могли запуститься где‑то ещё. Без одного из этих механизмов сбой узла может оставить VM в ожидании вмешательства. Настройте ремедиацию до того, как продакшн VM попадут в кластер, затем протестируйте в лаборатории, выключив питание узла и измерив, сколько времени потребуется VM, чтобы вернуться.
HA – это одна из дорогих задач, предварительное условие которой не является настройкой StorageClass, хотя хранилище и является причиной существования этого условия. Fence нужен, чтобы гарантировать, что две копии VM никогда не пишут на один и тот же диск.
Как проверить StorageClass перед запуском VM на нём?
В рамках дорогих задач шаблон повторяется. Каждая из них зависит от свойства StorageClass, которое ничего не проверяет при выделении VM из него. Класс без RWX выделит диски VM без жалоб, и эти VM не смогут выполнить live migration. Класс без поддержки snapshot примет VirtualMachineSnapshots, и эти снимки не будут хранить данные диска. CSI‑драйвер сообщает, что Kubernetes может выделять хранилище на массиве, и каждая из этих возможностей – отдельный вопрос о драйвере и классе.
Итак, до того как продакшн VM попадут, проверяйте класс за классом. Узнайте, предлагает ли он RWX блочные тома, существует ли для него VolumeSnapshotClass, какую репликацию использует, и, если размещение важно для производительности или соответствия, на каком массиве находятся данные. Храните ответы рядом с именами классов. Этот короткий список говорит вам, VM за VM, какая из вышеуказанных задач будет вести себя так, как вы ожидаете.
Как протестировать KubeVirt в лаборатории перед миграцией?
Самый быстрый способ увидеть, к какой группе относится каждая задача для вашего окружения, – это взять одну некритичную VM и провести её обычную неделю в лабораторном кластере. Создайте её из золотого образа, сделайте снимок и восстановите, выполните live migration, выполните drain узла, переместите её диски в другой StorageClass и выключите питание узла. Каждый шаг либо работает, либо указывает на StorageClass, оператор или сетевую настройку, требующую внимания, и каждый из них легче исправить до того, как продакшн VM будут зависеть от него.
Независимо от того, является ли для вас KubeCon первым знакомством с Kubernetes или вы являетесь опытным профессионалом, Portworx by Everpure поможет вашим командам ускорить переход на Kubernetes. Благодаря привычным рабочим процессам виртуальных машин, созданным специально для Kubernetes, интеграциям с такими платформами Kubernetes, как Red Hat OpenShift и SUSE Rancher, а также полноценной платформе хранения и управления данными, созданной для виртуальных машин в Kubernetes, мы можем упростить переход для администраторов vSphere.
Если вы находитесь на конференции KubeCon + CloudNativeCon North America в Солт-Лейк-Сити 9–12 ноября, команда Portworx будет ждать вас на стенде booth #191 и с радость обсудит любые из этих задач. Сессия Натана Вуда (Nathan Wood) в демонстрационном зале продолжит тему хранения данных и расскажет о том, почему сама по себе поддержка CSI не гарантирует отказоустойчивость, аварийное восстановление или мобильность данных. На стенде мы также будем подписывать экземпляры книги «The VMware Professional’s Field Guide to Kubernetes», в которой сопоставляются концепции vCenter, NSX и vSAN с их аналогами в Kubernetes.
Что почитать дальше
- Руководство пользователя KubeVirt: Живая миграция
- Руководство пользователя KubeVirt: API создания снимков и восстановления
- Руководство пользователя KubeVirt: Миграция томов
- Документация Portworx: Миграция дисков виртуальных машин KubeVirt в другое хранилище данных Kube
- «The VMware Professional’s Field Guide to Kubernetes» (электронная книга)
