Бесплатная лицензия KubeVirt не делает виртуализацию бесплатной. KubeVirt работает поверх готового Kubernetes, а отказоустойчивому Control Plane нужны три–пять серверов. Вместо одного гипервизора вы получаете несколько связанных слоёв, которые придётся сопровождать.
Вердикт простой. Если компания уже эксплуатирует Kubernetes, KubeVirt стоит проверить на пилоте. Для отдельного сервера или небольшого кластера 1С Proxmox проще по архитектуре. Сохранять VMware разумно, когда цена миграции и риск простоя выше стоимости лицензий.
Задача здесь не сводится к замене одного продукта другим. Вам нужно перенести ВМ, сохранить отказоустойчивость и не обменять счёт за VMware на расходы по содержанию Kubernetes-команды.
KubeVirt добавляет виртуальные машины в Kubernetes
Официальное руководство KubeVirt называет платформу надстройкой для Kubernetes. Установить её вместо Kubernetes нельзя: сначала нужен работающий кластер одной из трёх последних поддерживаемых версий.
Постоянное описание машины хранит объект VirtualMachine. После запуска контроллер создаёт временный объект VirtualMachineInstance, или VMI. Сама ВМ работает внутри pod virt-launcher, где запущены QEMU и отдельный процесс virtqemud.
Эта разница заметна при перезапуске. KubeVirt удаляет текущий VMI и создаёт новый pod. Машина может получить другой IP-адрес или оказаться на другом узле, если сеть и правила размещения не закрепляют прежние параметры.
Windows- и Linux-машины запускать можно. Для Windows потребуются драйверы virtio-win, иначе гостевая система не увидит часть виртуальных устройств или будет работать через менее подходящие драйверы.
На узлах нужна аппаратная виртуализация. Перед установкой проверьте её командой:
virt-host-validateПроверка должна подтвердить доступность KVM и пригодность хоста для виртуальных нагрузок. Программную эмуляцию KubeVirt тоже поддерживает, но строить на ней рабочую среду 1С не стоит: документация относит этот режим к специальной настройке, а не к штатной схеме.
Установка затрагивает и защитные механизмы Linux. KubeVirt запускает привилегированный virt-handler на каждом узле. AppArmor может заблокировать QEMU или монтирование для VirtIO-FS, а на узлах с SELinux нужен пакет container-selinux. Эти зависимости перечислены в руководстве по установке KubeVirt.
Привычную ВМ перенести можно. Но перенос диска ещё не возвращает привычную среду VMware: сеть, хранилище, снимки и правила миграции придётся собрать средствами Kubernetes.
VMware, Proxmox и KubeVirt требуют разной глубины сопровождения
Ни одна из трёх платформ сама по себе не ускоряет 1С. Сопоставимых замеров на одной конфигурации в материалах нет, поэтому сравнивать проценты производительности было бы нечестно. Ниже — архитектура и эксплуатация.
| Критерий | VMware vSphere | Proxmox VE | KubeVirt |
|---|---|---|---|
| Базовая модель | Гипервизор и централизованное управление через vCenter | Debian, KVM, LXC и веб-интерфейс в одной платформе | Виртуальные машины как ресурсы Kubernetes |
| Лицензирование | Платные лицензии; бессрочная модель прекращена | Открытая платформа, платная поддержка по выбору | Лицензионной платы за KubeVirt нет |
| Отказ узла | Кластер перезапускает ВМ на доступном хосте | Кластер и HA настраиваются средствами Proxmox | Перезапуском и размещением управляют контроллеры Kubernetes и KubeVirt |
| Живая миграция | vMotion переносит работающую ВМ | Встроенная миграция между узлами | Нужны совместимые узлы и общее RWX-хранилище |
| Хранение | Datastore и политики хранения vSphere | Локальные и распределённые хранилища, репликация | StorageClass, PVC, CSI и при необходимости Ceph или Longhorn |
| Резервное копирование | Зависит от редакции и выбранного продукта резервирования | Встроенные задания и Proxmox Backup Server | Нужны CSI-снимки либо отдельная система резервного копирования |
| Требования к команде | Знание ESXi, vCenter, сети и хранилища VMware | Знание Linux, KVM, кластера и выбранного хранилища | Знание Kubernetes API, CNI, CSI, Control Plane и KubeVirt |
Описание VMware и Proxmox опирается на сравнительный материал Osmio. Архитектуру KubeVirt, условия установки и живой миграции фиксируют официальное руководство KubeVirt, руководство Kubermatic по миграции и технический разбор Portworx.
KubeVirt сокращает число платформ только там, где Kubernetes уже принят. Если его нет, компания добавит второй контур управления к самой 1С, СУБД и резервному копированию.
Отдельный вопрос — накладные расходы любой виртуальной среды. Их границы и влияние на размещение базы разобраны в материале про ресурсную цену виртуализации 1С.
Хранилище и сеть определяют результат миграции
При переходе с VMware знакомые сущности меняют не только названия. Datastore превращается в сочетание StorageClass и PVC. Образ VMDK импортируется через DataVolume, а CDI записывает его в том, который использует выбранное хранилище.
Вместо vSwitch работает сетевой плагин CNI, например Calico или Cilium. Если ВМ нужны несколько интерфейсов или отдельная сеть второго уровня, потребуется Multus и объект NetworkAttachmentDefinition.
Снимки томов зависят от CSI-драйвера. Само наличие кнопки или объекта VolumeSnapshot ничего не гарантирует: драйвер хранилища должен поддерживать снимки. Это нужно подтвердить до переноса первой машины.
Для обычной живой миграции KubeVirt требует режим RWX: один том доступен с нескольких узлов. Платформа создаёт pod на целевом узле, переносит состояние памяти, переключает машину и удаляет прежний pod.
Если общего хранилища нет, возможна блочная миграция. Она переносит память вместе с блоками диска, поэтому создаёт больше трафика и занимает больше времени. Технический разбор Portworx прямо разделяет эти два метода.
| Исходная среда | Способ переноса | Что получите | Ограничение |
|---|---|---|---|
| Парк от 50 VMware ВМ | Forklift | Инвентаризацию через vCenter, создание PVC, конвертацию гостя и манифест ВМ | Нужен доступ к API vCenter; сеть и хранилище всё равно проектируют отдельно |
| Небольшой парк ВМ | virt-v2v и импорт через CDI | Конвертацию VMDK и загрузку образа в PVC | Больше ручных операций, отдельно проверяются драйверы и параметры ВМ |
| Закрытый контур | Локальная конвертация virt-v2v, затем CDI | Перенос без постоянного доступа мигратора к vCenter | Образы приходится доставлять и сверять вручную |
| Новая инфраструктура | Создание ВМ заново | Чистые манифесты, новая сеть и диски без наследия VMware | Потребуется отдельный перенос приложений, настроек и данных |
Границу в 50 ВМ приводит руководство Kubermatic по миграции с VMware на KubeVirt. Это ориентир для выбора инструмента, а не обещание автоматического переноса любого парка.
До миграции подтвердите четыре вещи: драйверы Windows, схему CNI, класс хранения и поддержку RWX. Затем проверьте снимки CSI. Без этой проверки вы перенесёте диск, но не получите ожидаемую замену vMotion.
Пилот из десяти ВМ требует запаса на отказ узла
Посчитаем ресурсы для трёхузлового пилота. Исходные данные: десять ВМ, каждой назначены 4 vCPU и 16 ГБ памяти. Полезная нагрузка составляет 40 vCPU и 160 ГБ.
Допущение первое: процессор не переподписан, то есть один назначенный vCPU требует одного доступного потока. Допущение второе: кластер должен выдержать отказ одного узла. Нагрузку делим между двумя оставшимися серверами.
Руководство Kubermatic советует оставить Kubernetes и компонентам KubeVirt 15–20% ресурсов. Для консервативного расчёта берём верхнюю границу — 20%. Под ВМ остаётся коэффициент 0,8:
CPU: 40 / (2 × 0,8) = 25 vCPU на узел
Память: 160 / (2 × 0,8) = 100 ГБ на узелЭто расчётный минимум, а не спецификация сервера. В него не входят память файлового кэша, резерв под рост ВМ, служебные машины, NUMA-ограничения и хранилище.
Если Ceph работает на тех же узлах, Kubermatic советует добавить 10–15% на демоны хранения. Берём 15% сверх 20% для Kubernetes и KubeVirt. Под ВМ остаётся 65% ресурсов:
CPU: 40 / (2 × 0,65) ≈ 31 vCPU на узел
Память: 160 / (2 × 0,65) ≈ 123 ГБ на узелПравило переносится на другой парк ВМ. Сложите назначенные vCPU и память, разделите сумму на число узлов после одного отказа. Полученный результат разделите на 0,8 без Ceph или на 0,65 при совместном размещении Ceph.
Если допускаете переподписку CPU, сначала задайте её коэффициент и проверьте нагрузку пилотом. Для памяти такую уступку не применяйте: назначенная гостям память должна физически помещаться на оставшихся узлах.
После запуска проверьте задержку по всей цепочке. Порядок замеров от гостевой системы до физического узла есть в маршруте поиска задержек виртуальной 1С.
KubeVirt подходит команде с работающим Kubernetes
Выбирайте KubeVirt, если Kubernetes уже обслуживает рабочие нагрузки, а инженеры отвечают за CNI, CSI и Control Plane. Тогда ВМ и контейнеры попадут в одну модель управления через API, пространства имён и квоты.
Перед пилотом проверьте версию Kubernetes, аппаратную виртуализацию и запуск привилегированных DaemonSet. Затем разберите ограничения AppArmor или SELinux, поддержку снимков CSI и RWX. Без этих условий пилот проверит лишь запуск одной ВМ, но не рабочую эксплуатацию.
Proxmox лучше подходит небольшой инфраструктуре, которой не нужен отдельный Kubernetes-контур. В одной платформе уже собраны KVM, веб-интерфейс, кластер, репликация и резервное копирование. Практическое продолжение — развёртывание узлов и ВМ Proxmox для 1С.
VMware стоит сохранить, если vSphere уже встроен в эксплуатацию, резервирование и процедуры восстановления. Миграционный риск может оказаться дороже продления лицензий, особенно при большом парке Windows-машин и сложной сети.
После покупки Broadcom стоимость лицензий для многих организаций выросла в два–три раза — такую оценку приводит Kubermatic. Это не универсальный коэффициент. Сравнивать нужно свой счёт с затратами на миграцию, обучение и сопровождение нового контура.
Решение принимают после пяти проверок пилота
Нет работающего Kubernetes и людей, которые сопровождают его сеть и хранение, — не переносите небольшую инфраструктуру 1С на KubeVirt ради нулевой лицензии. Сначала сравните Proxmox с сохранением VMware.
Для пилота KubeVirt достаточно одной некритичной машины. Проверка должна пройти последовательно:
- Запустите
virt-host-validateна каждом вычислительном узле. - Подтвердите RWX и снимки у выбранного CSI-драйвера.
- Перенесите одну ВМ через
virt-v2vи CDI либо Forklift. - Выполните живую миграцию командой
virtctl migrate <имя-vmi>. - Пересоздайте VMI и проверьте адрес, сеть, диски и запуск служб 1С.
Для рассмотренного парка из десяти ВМ нижняя расчётная граница — 25 vCPU и 100 ГБ на каждый из трёх узлов. При Ceph на тех же серверах граница поднимается примерно до 31 vCPU и 123 ГБ. Если такой резерв не помещается в бюджет, KubeVirt не решает вашу задачу.
Когда выбор зависит от текущего парка VMware, схемы хранения и допустимого простоя, потребуется разбор архитектуры виртуального контура. До него соберите перечень ВМ, назначенные ресурсы, зависимости по сети, требования к снимкам и окно миграции.