Руководство администратора

Введение

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

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

Параметры модуля

Конфигурация модуля virtualization задаётся через ресурс ModuleConfig в формате YAML. Ниже приведен пример базовой настройки:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: virtualization
spec:
  enabled: true
  version: 1
  settings:
    dvcr:
      storage:
        persistentVolumeClaim:
          size: 50G
          storageClassName: sds-replicated-thin-r1
        type: PersistentVolumeClaim
    virtualMachineCIDRs:
      - 10.66.10.0/24

Описание параметров

Включение модуля

Управление состоянием модуля осуществляется через поле .spec.enabled. Укажите:

• true — чтобы включить модуль;
• false — чтобы выключить модуль.

Версия конфигурации

Параметр .spec.version определяет версию схемы настроек. Структура параметров может меняться между версиями. Актуальные значения приведены в разделе настроек.

Хранилище образов виртуальных машин (DVCR)

Блок .spec.settings.dvcr.storage настраивает постоянный том для хранения образов:

• .spec.settings.dvcr.storage.persistentVolumeClaim.size — размер тома (например, 50G). Для расширения хранилища увеличьте значение параметра;
• .spec.settings.dvcr.storage.persistentVolumeClaim.storageClassName — класс хранения (например, sds-replicated-thin-r1).

Сетевые настройки

В блоке .spec.settings.virtualMachineCIDRs указываются подсети в формате CIDR (например, 10.66.10.0/24). IP-адреса для виртуальных машин распределяются из этих - диапазонов автоматически или по запросу.

Пример:

spec:
  settings:
    virtualMachineCIDRs:
      - 10.66.10.0/24
      - 10.66.20.0/24
      - 10.77.20.0/16

Первый и последний адреса подсети зарезервированы и недоступны для использования.

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

Настройки классов хранения для образов определяются в параметре .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 не задан.

Аудит событий безопасности

Чтобы включить аудит событий безопасности, установите параметр .spec.settings.audit.enabled настроек модуля в true:

spec:
  enabled: true
  settings:
    audit:
      enabled: true

Образы

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

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

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

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

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

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

• Ubuntu
  • 24.04 LTS (Noble Numbat)
  • 22.04 LTS (Jammy Jellyfish)
  • 20.04 LTS (Focal Fossa)
  • Minimal images
• Debian
  • 12 bookworm
  • 11 bullseye
• AlmaLinux
  • 9
  • 8
• RockyLinux
  • 9.5
  • 8.10
• CentOS
  • 10 Stream
  • 9 Stream
  • 8 Stream
  • 8
• Alt Linux
  • p10
  • p9
• Astra Linux

Поддерживаются следующие форматы образов с предустановленной системой:

• qcow2;
• raw;
• vmdk;
• vdi.

Образы могут быть сжаты одним из следующих алгоритмов сжатия: gz, xz.

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

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

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

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

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

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

1. Чтобы создать ресурс 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/noble/current/noble-server-cloudimg-amd64.img
   EOF
   

2. Проверьте результат создания ресурса 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 менять нельзя.

Диагностика проблем с ресурсом осуществляется путем анализа информации в блоке .status.conditions.

Чтобы отследить процесс создания образа, добавьте ключ -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

Создание образа из реестра контейнеров

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

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

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

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

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

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

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

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

4. Загрузите созданный образ в реестр контейнеров:

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

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

   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
   

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

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

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

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

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

   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"
   }
   

   Здесь:

   • inCluster — URL-адрес, который используется, если необходимо выполнить загрузку образа с одного из узлов кластера;
   • external — URL-адрес, который используется во всех остальных случаях.

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

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

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

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

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

   d8 k get cvi some-image
   

   Пример вывода:

   NAME         PHASE   CDROM   PROGRESS   AGE
   some-image   Ready   false   100%       1m
   

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

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

По умолчанию автоматически создается один ресурс VirtualMachineClass generic, который представляет универсальную модель CPU, использующую достаточно старую, но поддерживаемую большинством современных процессоров модель Nehalem. Это позволяет запускать ВМ на любых узлах кластера с возможностью «живой» миграции.

Чтобы вывести список ресурсов VirtualMachineClass, выполните следующую команду:

d8 k get virtualmachineclass

Пример вывода:

NAME               PHASE   AGE
generic            Ready   6d1h

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

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

Настройки VirtualMachineClass

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

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

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

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

Далее рассмотрим настройки блоков более детально.

Настройки vCPU

Блок .spec.cpu позволяет задать или настроить vCPU для ВМ.

Примеры настройки блока .spec.cpu:

• Класс с 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
  

• Класс c type: Host использует виртуальный vCPU, максимально соответствующий набору инструкций vCPU узла платформы, что обеспечивает высокую производительность и функциональность. Он также гарантирует совместимость с живой миграцией для узлов с похожими типами процессоров. Например, миграция виртуальной машины между узлами с процессорами Intel и AMD невозможна. Это также относится к процессорам разных поколений, так как их наборы инструкций могут отличаться.

  spec:
    cpu:
      type: Host
  

• Класс с type: HostPassthrough использует физический CPU узла платформы без изменений. Виртуальная машина, использующая этот класс, может быть мигрирована только на узел, у которого CPU точно совпадает с CPU исходного узла.

  spec:
    cpu:
      type: HostPassthrough
  

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

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

  Пример вывода:

  Broadwell-noTSX
  Broadwell-noTSX-IBRS
  Haswell-noTSX
  Haswell-noTSX-IBRS
  IvyBridge
  IvyBridge-IBRS
  Nehalem
  Nehalem-IBRS
  Penryn
  SandyBridge
  SandyBridge-IBRS
  Skylake-Client-noTSX-IBRS
  Westmere
  Westmere-IBRS
  

  Далее укажите в спецификации ресурса VirtualMachineClass следующее:

  spec:
    cpu:
      model: IvyBridge
      type: Model
  

Настройки размещения

Блок .spec.nodeSelector опционален. Он позволяет задать узлы, на которых будут размещаться ВМ, использующие данный vmclass:

  spec:
    nodeSelector:
      matchExpressions:
        - key: node.deckhouse.io/group
          operator: In
          values:
          - green

Настройки политики сайзинга

Блок .spec.sizingPolicy позволяет задать политики сайзинга ресурсов виртуальных машин, которые используют vmclass.

Блок cores обязательный и задает диапазоны ядер, на которые распространяется правило, описанное в этом же блоке.

Диапазоны [min; max] для параметра cores должны быть строго последовательными и непересекающимися.

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

- cores:
    min: 1
    max: 4
    ...
- cores:
    min: 5   # Начало следующего диапазона = (предыдущий max + 1)
    max: 8

Недопустимый вариант (пересечение значений):

- cores:
    min: 1
    max: 4
    ...
- cores:
    min: 4   # Ошибка: Значение 4 уже входит в предыдущий диапазон
    max: 8

Для каждого диапазона ядер cores можно задать дополнительные требования:

1. Память (memory) — указывается:

   • Либо минимум и максимум памяти для всех ядер в диапазоне,
   • Либо минимум и максимум памяти на одно ядро (memoryPerCore).

2. Допустимые доли ядер (coreFractions) — список разрешенных значений (например, [25, 50, 100] для 25%, 50% или 100% использования ядра).

Пример политики с подобными настройками:

spec:
  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
      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
      coreFractions: [20, 50, 100]
    # Для диапазона от 9 до 16 ядер возможно использовать от 9 до 32 ГБ оперативной памяти с шагом 1 ГБ.
    # При необходимости можно использовать выделенные ядра.
    # Доступны некоторые варианты параметра `corefraction`.
    - cores:
        min: 9
        max: 16
      memory:
        min: 9Gi
        max: 32Gi
        step: 1Gi
      coreFractions: [50, 100]
    # Для диапазона от 17 до 248 ядер возможно использовать от 1 до 2 ГБ оперативной памяти из расчёта на одно ядро.
    # Доступны для использования только выделенные ядра.
    # Единственный доступный параметр `corefraction` = 100%.
    - cores:
        min: 17
        max: 248
      memory:
        perCore:
          min: 1Gi
          max: 2Gi
      coreFractions: [100]

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

Представим, что у нас есть кластер из четырех узлов. Два из этих узлов с лейблом 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: { ... }

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

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

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

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

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

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

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

   d8 k get vm
   

   Пример вывода:

   NAME                                   PHASE     NODE           IPADDRESS     AGE
   linux-vm                              Running   virtlab-pt-1   10.66.10.14   79m
   

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

2. Для осуществления миграции виртуальной машины с одного узла на другой, с учетом требований к размещению виртуальной машины используется ресурс 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
   

3. Сразу после создания ресурса 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
   

4. Если необходимо прервать миграцию, удалите соответствующий ресурс vmop, пока он находится в фазе Pending или InProgress.

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

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

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

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

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

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

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

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

Чтобы вывести его из режима обслуживания, остановите выполнение команды drain (Ctrl+C), затем выполните:

d8 k uncordon <nodename>

ColdStandby

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

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

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

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

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