Виртуальные машины KubeVirt — это просто: VM Disk и VM Instance в Cozystack

KubeVirt делает запуск виртуальных машин в Kubernetes мощным, но сложным. Cozystack сводит VirtualMachine, DataVolume и PVC к двум чистым примитивам — VM Disk и VM Instance — с независимыми жизненными циклами для золотых образов, клонирования и быстрого выделения ресурсов.
Автор Timur Tukaev |

Виртуальные машины KubeVirt — это просто с Cozystack VM Disk и VM Instance

Если вы работали с KubeVirt напрямую, вам знакома эта боль: VirtualMachine, VirtualMachineInstance, DataVolume, PVC — целый лабиринт ресурсов только для того, чтобы запустить простую виртуальную машину. А если нужно клонировать VM, использовать общий базовый образ или мигрировать хранилище независимо от вычислительных ресурсов? Удачи собрать всё это вручную.

Cozystack сводит это к двум пользовательским ресурсам: VMDisk и VMInstance. У них независимые жизненные циклы, и в этом весь смысл — удалите VM, а диск останется; позже подключите тот же диск к более мощной VM; клонируйте золотой образ один раз и переиспользуйте его для каждой новой VM. Неизменяемая инфраструктура и быстрое выделение ресурсов достаются бесплатно.

VM Disk подключаются к VM Instance; при удалении VM диски сохраняются

Сравнение

VMDiskVMInstance
Что этоПостоянное блочное устройствоРаботающая виртуальная машина
Жизненный циклНезависимый, переживает удаление VMЭфемерный — пересоздаётся в любой момент без потери данных
Аналог в KubeVirtDataVolume + PVCVirtualMachine + VirtualMachineInstance
Что настраиваетеИсходный образ, размер, storageClassТип инстанса, диски, SSH-ключи, cloud-init, GPU
Для чегоЗолотые образы, диски с данными, предварительное выделение ресурсовВычисления, сеть, пользовательские данные

Создание VM Disk

Через панель управления: Catalog -> VM Disk -> задайте имя, выберите исходный образ (Ubuntu, Windows и т.д.), укажите размер и storageClass -> Deploy.

Через kubectl:

apiVersion: apps.cozystack.io/v1alpha1
kind: VMDisk
metadata:
  name: ubuntu-base
  namespace: tenant-team1
spec:
  source:
    image:
      name: ubuntu
  storage: 50Gi
  storageClass: replicated

Источники также включают http.url (загрузка по URL) и disk.name (клонирование существующего VMDisk для сценариев с золотыми образами).

Создание VM Instance

Через панель управления: Catalog -> VM Instance -> имя, тип инстанса (например, u1.medium), подключите VMDisk, добавьте SSH-ключ и, при необходимости, cloud-init -> Deploy.

Через kubectl:

apiVersion: apps.cozystack.io/v1alpha1
kind: VMInstance
metadata:
  name: dev-server
  namespace: tenant-team1
spec:
  instanceType: u1.medium
  instanceProfile: ubuntu
  disks:
    - name: ubuntu-base
  sshKeys:
    - "ssh-ed25519 AAAA... user@workstation"
  cloudInit: |
    #cloud-config
    packages:
      - nginx

Поле disks[].name — это metadata.name существующего VMDisk в том же пространстве имён.

Доступ к вашей VM

# Последовательная консоль
virtctl console dev-server

# SSH
virtctl ssh ubuntu@dev-server

# VNC (графический интерфейс)
virtctl vnc dev-server

Почему это отдельные CR (а не релизы Helm)

Под капотом Cozystack по-прежнему использует Flux и Helm для развёртывания ресурсов, но обращённый к пользователю API — это группа apps.cozystack.io/v1alpha1. Вы пишете VMDisk или VMInstance, а оператор Cozystack берёт на себя всю обвязку HelmRelease/KubeVirt/DataVolume. То же самое относится к каждому управляемому сервису в каталоге — Postgres, Kubernetes, VPC, OpenBao имеют собственные нативные CR.

Документация

Присоединяйтесь к сообществу