Функциональность модуля может измениться, но основные возможности сохранятся. Совместимость с будущими версиями обеспечивается, но может потребовать дополнительных действий по миграции.

Введение

Данное руководство предназначено для администраторов Deckhouse Virtualization Platform и описывает порядок создания и изменения кластерных ресурсов.

Также администратор обладает правами на управление проектными ресурсами, описание которых содержится в документе “Инструкция пользователя”.

Образы

Ресурс ClusterVirtualImage служит для загрузки образов виртуальных машин во внутрикластерное хранилище, после чего с его помощью можно создавать диски виртуальных машин. Он доступен во всех пространствах имен/проектах кластера.

Процесс создания образа включает следующие шаги:

  • Пользователь создаёт ресурс ClusterVirtualImage.
  • После создания образ автоматически загружается из указанного в спецификации источника в хранилище (DVCR).
  • После завершения загрузки ресурс становится доступным для создания дисков.

Существуют различные типы образов:

  • ISO-образ — установочный образ, используемый для начальной установки операционной системы. Такие образы выпускаются производителями ОС и используются для установки на физические и виртуальные серверы.
  • Образ диска с предустановленной системой — содержит уже установленную и настроенную операционную систему, готовую к использованию после создания виртуальной машины. Эти образы предлагаются несколькими производителями и могут быть представлены в таких форматах, как qcow2, raw, vmdk и другие.

Примеры ресурсов для получения образов виртуальной машины:

После создания ресурса тип и размер образа определяются автоматически, и эта информация отражается в статусе ресурса.

Образы могут быть загружены из различных источников, таких как HTTP-серверы, где расположены файлы образов, или контейнерные реестры. Также доступна возможность загрузки образов напрямую из командной строки с использованием утилиты curl.

Образы могут быть созданы из других образов и дисков виртуальных машин.

С полным описанием параметров конфигурации ресурса ClusterVirtualImage можно ознакомиться по ссылке.

Создание образа с HTTP-сервера

Рассмотрим вариант создания кластерного образа.

Выполните следующую команду для создания ClusterVirtualImage:

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: ClusterVirtualImage
metadata:
  name: ubuntu-22.04
spec:
  # Источник для создания образа.
  dataSource:
    type: HTTP
    http:
      url: "https://cloud-images.ubuntu.com/minimal/releases/jammy/release/ubuntu-22.04-minimal-cloudimg-amd64.img"
EOF

Проверьте результат создания ClusterVirtualImage:

d8 k get clustervirtualimage ubuntu-22.04
# или более короткий вариант
d8 k get cvi ubuntu-22.04

# NAME           PHASE   CDROM   PROGRESS   AGE
# ubuntu-22.04   Ready   false   100%       23h

После создания ресурс ClusterVirtualImage может находиться в следующих состояниях (фазах):

  • Pending - ожидание готовности всех зависимых ресурсов, требующихся для создания образа.
  • WaitForUserUpload - ожидание загрузки образа пользователем (фаза присутствует только для type=Upload).
  • Provisioning - идет процесс создания образа.
  • Ready - образ создан и готов для использования.
  • Failed - произошла ошибка в процессе создания образа.
  • Terminating - идет процесс удаления Образа. Образа может “зависнуть” в данном состоянии если он еще подключен к виртуальной машине.

До тех пор пока образ не перешёл в фазу Ready содержимое всего блока .spec допускается изменять. При изменении процесс создании диска запустится заново. После перехода в фазу Ready содержимое блока .spec менять нельзя!

Отследить процесс создания образа можно путем добавления ключа -w к предыдущей команде:

d8 k get cvi ubuntu-22.04 -w

# NAME           PHASE          CDROM   PROGRESS   AGE
# ubuntu-22.04   Provisioning   false              4s
# ubuntu-22.04   Provisioning   false   0.0%       4s
# ubuntu-22.04   Provisioning   false   28.2%      6s
# ubuntu-22.04   Provisioning   false   66.5%      8s
# ubuntu-22.04   Provisioning   false   100.0%     10s
# ubuntu-22.04   Provisioning   false   100.0%     16s
# ubuntu-22.04   Ready          false   100%       18s

В описание ресурса ClusterVirtualImage можно получить дополнительную информацию о скачанном образе:

d8 k describe cvi ubuntu-22.04

Создание образа из Container Registry

Образ, хранящийся в Container Registry имеет определенный формат. Рассмотрим на примере:

Для начала загрузите образ локально:

curl -L https://cloud-images.ubuntu.com/minimal/releases/jammy/release/ubuntu-22.04-minimal-cloudimg-amd64.img -o ubuntu2204.img

Далее создайте Dockerfile со следующим содержимым:

FROM scratch
COPY ubuntu2204.img /disk/ubuntu2204.img

Соберите образ и загрузите его в container registry. В качестве container registry в примере ниже использован docker.io. для выполнения вам необходимо иметь учетную запись сервиса и настроенное окружение.

docker build -t docker.io/<username>/ubuntu2204:latest

где username — имя пользователя, указанное при регистрации в docker.io.

Загрузите созданной образ в container registry:

docker push docker.io/<username>/ubuntu2204:latest

Чтобы использовать этот образ, создайте в качестве примера ресурс:

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: ClusterVirtualImage
metadata:
  name: ubuntu-2204
spec:
  dataSource:
    type: ContainerImage
    containerImage:
      image: docker.io/<username>/ubuntu2204:latest
EOF

Загрузка образа из командной строки

Чтобы загрузить образ из командной строки, предварительно создайте следующий ресурс, как представлено ниже на примере ClusterVirtualImage:

d8 k apply -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: ClusterVirtualImage
metadata:
  name: some-image
spec:
  # Настройки источника образа.
  dataSource:
    type: Upload
EOF

После создания, ресурс перейдет в фазу WaitForUserUpload, а это значит, что он готов для загрузки образа.

Доступно два варианта загрузки с узла кластера и с произвольного узла за пределами кластера:

d8 k get cvi some-image -o jsonpath="{.status.imageUploadURLs}"  | jq

# {
#   "external":"https://virtualization.example.com/upload/g2OuLgRhdAWqlJsCMyNvcdt4o5ERIwmm",
#   "inCluster":"http://10.222.165.239/upload"
# }

В качестве примера загрузите образ Cirros:

curl -L http://download.cirros-cloud.net/0.5.1/cirros-0.5.1-x86_64-disk.img -o cirros.img

Выполните загрузку образа с использование следующей команды

curl https://virtualization.example.com/upload/g2OuLgRhdAWqlJsCMyNvcdt4o5ERIwmm --progress-bar -T cirros.img | cat

После завершения загрузки образ должен быть создан и перейти в фазу Ready

d8 k get cvi some-image
# NAME         PHASE   CDROM   PROGRESS   AGE
# some-image   Ready   false   100%       1m

Классы виртуальных машин

Ресурс VirtualMachineClass предназначен для централизованной конфигурации предпочтительных параметров виртуальных машин. Он позволяет определять инструкции CPU и политики конфигурации ресурсов CPU и памяти для виртуальных машин, а также определять соотношения этих ресурсов. Помимо этого, VirtualMachineClass обеспечивает управление размещением виртуальных машин по узлам платформы. Это позволяет администраторам эффективно управлять ресурсами платформы виртуализации и оптимально размещать виртуальные машины на узлах платформы.

Структура ресурса VirtualMachineClass выглядит следующим образом:

apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: <vmclass-name>
spec:
  # Блок описывает параметры виртуального процессора для виртуальных машин.
  # Изменять данны блок нельзя после создания ресурса.
  cpu: ...

  # (опциональный блок) Описывает правила размещения виртуальных машины по узлам.
  # При изменении автоматически применяется ко всем виртуальных машинам, использующим данный VirtualMachineClass.
  nodeSelector: ...

  # (опциональный блок) Описывает политику настройки ресурсов виртуальных машин.
  # При изменении автоматически применяется ко всем виртуальных машинам, использующим данный VirtualMachineClass.
  sizingPolicies: ...

Внимание! Поскольку изменение параметра .spec.nodeSelector влияет на все виртуальные машины, использующие данный VirtualMachineClass, следует учитывать следующее:

Для Enterprise-редакции: это может привести к миграции виртуальных машин на новые узлы назначения, если текущие узлы не соответствуют требованиям размещения. Для Community-редакции: это может вызвать перезапуск виртуальных машин в соответствии с автоматической политикой применения изменений, установленной в параметре .spec.disruptions.restartApprovalMode.

Платформа виртуализации предоставляет 3 предустановленных ресурса VirtualMachineClass:

d8 k get virtualmachineclass
NAME               PHASE   AGE
host               Ready   6d1h
host-passthrough   Ready   6d1h
generic            Ready   6d1h
  • host - данный класс использует виртуальный CPU, максимально близкий к CPU узла платформы по набору инструкций. Это обеспечивает высокую производительность и функциональность, а также совместимость с живой миграцией для узлов с похожими типами процессоров. Например, миграция ВМ между узлами с процессорами Intel и AMD не будет работать. Это также справедливо для процессоров разных поколений, так как набор инструкций у них отличается.
  • host-passthrough - используется физический CPU узла платформы напрямую без каких-либо изменений. При использовании данного класса, гостевая ВМ может быть мигрирована только на целевой узел, у которого CPU точно соответствует CPU исходного узла.
  • generic - универсальная модель CPU, использующая достаточно старую, но поддерживаемую большинством современных процессоров модель Nehalem. Это позволяет запускать ВМ на любых узлах кластера с возможностью живой миграции.

VirtualMachineClass является обязательным для указания в конфигурации виртуальной машины, пример того как указывать класс в спецификации ВМ:

apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachine
metadata:
  name: linux-vm
spec:
  virtualMachineClassName: generic # название ресурса VirtualMachineClass
  ...

Рекомендуется создать как минимум один ресурс VirtualMachineClass в кластере с типом Discovery сразу после того как все узлы будут настроены и добавлены в кластер. Это позволит использовать в виртуальных машинах универсальный процессор с максимально возможными характеристиками с учетом ЦП на узлах кластера, что позволит виртуальным машинам использовать максимум возможностей ЦП и при необходимости беспрепятственно осуществлять миграцию между узлами кластера.

Администраторы платформы могут создавать требуемые классы виртуальных машин по своим потребностям, но рекомендуется создавать необходимый минимум. Рассмотрим на следующем примере:

Пример конфигурации VirtualMachineClass

Представим, что у нас есть кластер из четырех узлов. Два из этих узлов с лейблом group=blue оснащены процессором “CPU X” с тремя наборами инструкций, а остальные два узла с лейблом group=green имеют более новый процессор “CPU Y” с четырьмя наборами инструкций.

Для оптимального использования ресурсов данного кластера, рекомендуется создать три дополнительных класса виртуальных машин (VirtualMachineClass):

  • universal: Этот класс позволит виртуальным машинам запускаться на всех узлах платформы и мигрировать между ними. При этом будет использоваться набор инструкций для самой младшей модели CPU, что обеспечит наибольшую совместимость.
  • cpuX: Этот класс будет предназначен для виртуальных машин, которые должны запускаться только на узлах с процессором “CPU X”. ВМ смогут мигрировать между этими узлами, используя доступные наборы инструкций “CPU X”.
  • cpuY: Этот класс предназначен для виртуальных машин, которые должны запускаться только на узлах с процессором “CPU Y”. ВМ смогут мигрировать между этими узлами, используя доступные наборы инструкций “CPU Y”.

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

Примерные конфигурации ресурсов для данного кластера:

---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: universal
spec:
  cpu:
    discovery: {}
    type: Discovery
  sizingPolicies: { ... }
---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: cpuX
spec:
  cpu:
    discovery: {}
    type: Discovery
  nodeSelector:
    matchExpressions:
      - key: group
        operator: In
        values: ["blue"]
  sizingPolicies: { ... }
---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: cpuY
spec:
  cpu:
    discovery:
      nodeSelector:
        matchExpressions:
          - key: group
            operator: In
            values: ["green"]
    type: Discovery
  sizingPolicies: { ... }

Прочие варианты конфигурации

Пример конфигурации ресурса VirtualMachineClass:

apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: discovery
spec:
  cpu:
    # сконфигурировать универсальный vCPU для заданного набора узлов
    discovery:
      nodeSelector:
        matchExpressions:
          - key: node-role.kubernetes.io/control-plane
            operator: DoesNotExist
    type: Discovery
  # разрешать запуск ВМ с данным классом только на узлах группы worker
  nodeSelector:
    matchExpressions:
      - key: node.deckhouse.io/group
        operator: In
        values:
          - worker
  # политика конфигурации ресурсов
  sizingPolicies:
    # для диапазона от 1 до 4 ядер возможно использовать от 1 до 8 Гб оперативной памяти с шагом 512Mi
    # т.е 1Гб, 1,5Гб, 2Гб, 2,5Гб итд
    # запрещено использовать выделенные ядра
    # и доступны все варианты параметра corefraction
    - cores:
        min: 1
        max: 4
      memory:
        min: 1Gi
        max: 8Gi
        step: 512Mi
      dedicatedCores: [false]
      coreFractions: [5, 10, 20, 50, 100]
    # для диапазона от 5 до 8 ядер возможно использовать от 5 до 16 Гб оперативной памяти с шагом 1Гб
    # т.е. 5Гб, 6Гб, 7Гб, итд
    # запрещено использовать выделенные ядра
    # и доступны некоторые варианты параметра corefraction
    - cores:
        min: 5
        max: 8
      memory:
        min: 5Gi
        max: 16Gi
        step: 1Gi
      dedicatedCores: [false]
      coreFractions: [20, 50, 100]
    # для диапазона от 9 до 16 ядер возможно использовать от 9 до 32 Гб оперативной памяти с шагом 1Гб
    # можно использовать выделенные ядра (а можно и не использовать)
    # и доступны некоторые варианты параметра corefraction
    - cores:
        min: 9
        max: 16
      memory:
        min: 9Gi
        max: 32Gi
        step: 1Gi
      dedicatedCores: [true, false]
      coreFractions: [50, 100]
    # для диапазона от 17 до 1024 ядер возможно использовать от 1 до 2 Гб оперативной памяти из расчета на одно ядро
    # доступны для использования только выделенные ядра
    # и единственный параметр corefraction = 100%
    - cores:
        min: 17
        max: 1024
      memory:
        perCore:
          min: 1Gi
          max: 2Gi
      dedicatedCores: [true]
      coreFractions: [100]

Далее приведены фрагменты конфигураций VirtualMachineClass для решения различных задач:

  • класс с vCPU с требуемым набором процессорных инструкций, для этого используем type: Features, чтобы задать необходимый набор поддерживаемых инструкций для процессора:

    spec:
  cpu:
    features:
      - vmx
    type: Features

  • класс c универсальным vCPU для заданного набора узлов, для этого используем type: Discovery:

    spec:
  cpu:
    discovery:
      nodeSelector:
        matchExpressions:
          - key: node-role.kubernetes.io/control-plane
            operator: DoesNotExist
    type: Discovery

  • чтобы создать vCPU конкретного процессора с предварительно определенным набором инструкций, используем тип type: Model. Предварительно, чтобы получить перечень названий поддерживаемых CPU для узла кластера, выполните команду:

    d8 k get nodes <node-name> -o json | jq '.metadata.labels | to_entries[] | select(.key | test("cpu-model")) | .key | split("/")[1]' -r

# Примерный вывод:
#
# IvyBridge
# Nehalem
# Opteron_G1
# Penryn
# SandyBridge
# Westmere

далее указать в спецификации ресурса VirtualMachineClass:

spec:
  cpu:
    model: IvyBridge
    type: Model

Механизмы обеспечения надежности

Миграция / Режим обслуживания

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

  • Балансировка нагрузки: Перемещение виртуальных машин между узлами позволяет равномерно распределять нагрузку на серверы, обеспечивая использование ресурсов наилучшим образом.
  • Перевод узла в режим обслуживания: Виртуальные машины могут быть перемещены с узлов, которые нужно вывести из эксплуатации для выполнения планового обслуживания или обновления программного обеспечения.
  • Обновление «прошивки» виртуальных машин: Миграция позволяет обновить “прошивку” виртуальных машины не прерывая их работу.

Запуск миграции произвольной машины

Далее будет рассмотрен пример миграции выбранной виртуальной машины:

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

d8 k get vm
# NAME                                   PHASE     NODE           IPADDRESS     AGE
# linux-vm                              Running   virtlab-pt-1   10.66.10.14   79m

Мы видим что на данный момент она запущена на узле virtlab-pt-1.

Для осуществления миграции виртуальной машины с одного узла на другой, с учетом требований к размещению виртуальной машины используется ресурс VirtualMachineOperations (vmop) с типом Evict.

d8 k create -f - <<EOF
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineOperation
metadata:
  generateName: evict-linux-vm-
spec:
  # имя виртуальной машины
  virtualMachineName: linux-vm
  # операция для миграции
  type: Evict
EOF

Сразу после создания ресурса vmop, выполните команду:

d8 k get vm -w
# NAME                                   PHASE       NODE           IPADDRESS     AGE
# linux-vm                              Running     virtlab-pt-1   10.66.10.14   79m
# linux-vm                              Migrating   virtlab-pt-1   10.66.10.14   79m
# linux-vm                              Migrating   virtlab-pt-1   10.66.10.14   79m
# linux-vm                              Running     virtlab-pt-2   10.66.10.14   79m

Режим обслуживания

При выполнении работ на узлах с запущенными виртуальными машинами существует риск нарушения их работоспособности. Чтобы этого избежать, узел можно перевести в режим обслуживания и мигрировать виртуальные машины на другие свободные узлы.

Для этого необходимо выполнить следующую команду:

d8 k drain <nodename> --ignore-daemonsets --delete-emptydir-dat

где <nodename> - узел, на котором предполагается выполнить работы и который должен быть освобожден от всех ресурсов (в том числе и от системных).

Если есть необходимость вытеснить с узла только виртуальные машины, выполните следующую команду:

d8 k drain <nodename> --pod-selector vm.kubevirt.internal.virtualization.deckhouse.io/name --delete-emptydir-data

После выполнения конмад d8 k drain - узле перейдет в режим обслуживания и виртуальные машины на нем запускаться не смогут. Чтобы вывести его из режима обслуживания выполните следующую команду:

d8 k uncordon <nodename>

ColdStandby

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

Для работы данного механизма необходимо выполнит следующие требования:

  • Политика запуска виртуальной машины (.spec.runPolicy) должна быть одна из: AlwaysOnUnlessStoppedManually, AlwaysOn.
  • На узлах, где запущены виртуальные машины, должен быть включен механизм fencing.

Рассмотрим как это работает на примере:

  • Кластер состоит из трех узлов master, workerA и workerB. На worker-узлах включен механизм Fencing.
  • Виртуальная машина linux-vm запущена на узле workerA.
  • На узле workerA возникает проблема (выключилось питание, пропала сеть, итд)
  • Контроллер проверяет доступность узлов и обнаруживает, что workerA недоступен.
  • Контроллер удаляет узел workerA из кластер.
  • Виртуальная машина linux-vm запускается на другом подходящем узле (workerB).

Настройки хранения дисков и образов

Для хранения дисков (VirtualDisk) и образов (VirtualImage) с типом PersistentVolumeClaim используются хранилища, предоставляемые платформой.

Перечень поддерживаемых платформой хранилищ можно посмотреть, выполнив команду, для просмотра классов хранилищ (StorageClass)

d8 k get storageclass

Пример выполнения команды:

# NAME                                       PROVISIONER                           RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
# ceph-pool-r2-csi-rbd                       rbd.csi.ceph.com                      Delete          WaitForFirstConsumer   true                   49d
# ceph-pool-r2-csi-rbd-immediate (default)   rbd.csi.ceph.com                      Delete          Immediate              true                   49d
# linstor-thin-r1                            replicated.csi.storage.deckhouse.io   Delete          WaitForFirstConsumer   true                   28d
# linstor-thin-r2                            replicated.csi.storage.deckhouse.io   Delete          WaitForFirstConsumer   true                   78d
# nfs-4-1-wffc                               nfs.csi.k8s.io                        Delete          WaitForFirstConsumer   true                   49d

Маркер (default) рядом с названием класса показывает, что данный StorageClass будет использоваться по умолчанию, в случае если пользователь не указал название класса явно в создаваемом ресурсе.

Если StorageClass по умолчанию в кластере отсутствует, то пользователь должен указать требуемый StorageClass в спецификации ресурса явно.

Также модуль virtualization позволяет задать индивидуальные настройки для хранения дисков и образов.

Настройки классов хранения для образов

Настройки классов хранения для образов определяется в параметре .spec.settings.virtualImages настроек модуля.

Пример:

spec:
  ...
  settings:
    virtualImages:
       allowedStorageClassNames:
       - sc-1
       - sc-2
       defaultStorageClassName: sc-1

allowedStorageClassNames — (опционально) это список допустимых StorageClass для создания VirtualImage, которые можно явно указать в спецификации ресурса. defaultStorageClassName — (опционально) это StorageClass, используемый по умолчанию при создании VirtualImage, если параметр .spec.persistentVolumeClaim.storageClassName не задан.

Настройки классов хранения для дисков

Настройки классов хранения для дисков определяется в параметре .spec.settings.virtualDisks настроек модуля.

Пример:

spec:
  ...
  settings:
    virtualDisks:
       allowedStorageClassNames:
       - sc-1
       - sc-2
       defaultStorageClassName: sc-1

allowedStorageClassNames — (опционально) это список допустимых StorageClass для создания VirtualDisk, которые можно явно указать в спецификации ресурса.

defaultStorageClassName — (опционально) это StorageClass, используемый по умолчанию при создании VirtualDisk, если параметр .spec.persistentVolumeClaim.storageClassName не задан.

Тонкая настройка классов хранения для дисков

При создании диска контроллер автоматически выберет наиболее оптимальные параметры, поддерживаемые хранилищем, на основании известных ему данных.

Приоритеты настройки параметров PersistentVolumeClaim при создании диска посредством автоматического определения характеристик хранилища:

  • RWX + Block
  • RWX + FileSystem
  • RWO + Block
  • RWO + FileSystem

Если хранилище неизвестно и определить его параметры автоматически - невозможно, используется режим: RWO + FileSystem