Предварительная версия. Функциональность может измениться, но основные возможности сохранятся. Совместимость с будущими версиями может потребовать ручных действий по миграции.
Введение
Данное руководство предназначено для администраторов 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.virtualMachineCIDRs
не должны пересекаться с подсетями узлов кластера, подсетью сервисов или подсетью подов (podCIDR
).
Запрещено удалять подсети, если адреса из них уже выданы виртуальным машинам.
Настройки классов хранения для образов
Настройки классов хранения для образов определяются в параметре .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
не задан.
Полный перечень параметров конфигурации приведен в разделе Настройки.
Образы
Ресурс ClusterVirtualImage служит для загрузки образов виртуальных машин во внутрикластерное хранилище, после чего с его помощью можно создавать диски виртуальных машин. Он доступен во всех пространствах имен и проектах кластера.
Процесс создания образа включает следующие шаги:
- Пользователь создаёт ресурс ClusterVirtualImage.
- После создания образ автоматически загружается из указанного в спецификации источника в хранилище (DVCR).
- После завершения загрузки ресурс становится доступным для создания дисков.
Существуют различные типы образов:
- ISO-образ — установочный образ, используемый для начальной установки операционной системы (ОС). Такие образы выпускаются производителями ОС и используются для установки на физические и виртуальные серверы.
- Образ диска с предустановленной системой — содержит уже установленную и настроенную операционную систему, готовую к использованию после создания виртуальной машины. Готовые образы можно получить на ресурсах разработчиков дистрибутива, либо создать самостоятельно.
Примеры ресурсов для получения образов виртуальной машины:
- Ubuntu
- Debian
- AlmaLinux
- RockyLinux
- CentOS
- Alt Linux
- Astra Linux
Поддерживаются следующие форматы образов с предустановленной системой:
qcow2
;raw
;vmdk
;vdi
.
Образы могут быть сжаты одним из следующих алгоритмов сжатия: gz
, xz
.
После создания ресурса ClusterVirtualImage тип и размер образа определяются автоматически, и эта информация отражается в статусе ресурса.
Образы могут быть загружены из различных источников, таких как HTTP-серверы, где расположены файлы образов, или контейнерные реестры. Также доступна возможность загрузки образов напрямую из командной строки с использованием утилиты curl
.
Образы могут быть созданы из других образов и дисков виртуальных машин.
С полным описанием параметров конфигурации ресурса ClusterVirtualImage можно ознакомиться в разделе Custom Resources.
Создание образа с 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/noble/current/noble-server-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
менять нельзя.
Диагностика проблем с ресурсом осуществляется путем анализа информации в блоке .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
Создание образа из реестра контейнеров
Образ, хранящийся в реестре контейнеров, имеет определённый формат. Рассмотрим на примере:
-
Для начала загрузите образ локально:
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
-
Соберите образ и загрузите его в реестр контейнеров. В качестве реестра контейнеров в примере ниже использован
docker.io
. Для выполнения вам необходимо иметь учётную запись сервиса и настроенное окружение.docker build -t docker.io/<username>/ubuntu2204:latest
где
<username>
— имя пользователя, указанное при регистрации вdocker.io
. -
Загрузите созданный образ в реестр контейнеров:
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" }
Здесь:
inCluster
— URL-адрес, который используется, если необходимо выполнить загрузку образа с одного из узлов кластера;external
— URL-адрес, который используется во всех остальных случаях.
-
В качестве примера загрузите образ 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 generic
, который представляет универсальную модель CPU, использующую достаточно старую, но поддерживаемую большинством современных процессоров модель Nehalem. Это позволяет запускать ВМ на любых узлах кластера с возможностью «живой» миграции.
Рекомендуется создать как минимум один ресурс VirtualMachineClass в кластере с типом Discovery
сразу после того, как все узлы будут настроены и добавлены в кластер.
Это позволит использовать в виртуальных машинах универсальный процессор с максимально возможными характеристиками с учетом CPU на узлах кластера, что позволит виртуальным машинам использовать максимум возможностей CPU и при необходимости беспрепятственно осуществлять миграцию между узлами кластера.
Пример настройки смотрите в разделе Пример конфигурации vCPU Discovery
Чтобы вывести список ресурсов 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
после создания ресурса VirtualMachineClass изменять нельзя.
Примеры настройки блока .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.nodeSelector
влияет на все виртуальные машины, использующие данный ресурс VirtualMachineClass, следует учитывать следующее:
- в Enterprise-редакции это может привести к миграции виртуальных машин на новые узлы назначения, если текущие узлы не соответствуют требованиям размещения;
- в Community-редакции это может вызвать перезапуск виртуальных машин в соответствии с автоматической политикой применения изменений, установленной в параметре
.spec.disruptions.restartApprovalMode
.
Настройки политики сайзинга
Блок .spec.sizingPolicy
позволяет задать политики сайзинга ресурсов виртуальных машин, которые используют vmclass.
Изменения в блоке .spec.sizingPolicy
также могут повлиять на виртуальные машины.
Для виртуальных машин, чья политика сайзинга не будет соответствовать новым требованиям политики, условие SizingPolicyMatched
в блоке .status.conditions
будет ложным (status: False
).
При настройке sizingPolicy
будьте внимательны и учитывайте топологию CPU для виртуальных машин.
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
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 до 248 ядер возможно использовать от 1 до 2 ГБ оперативной памяти из расчёта на одно ядро.
# Доступны для использования только выделенные ядра.
# Единственный доступный параметр `corefraction` = 100%.
- cores:
min: 17
max: 248
memory:
perCore:
min: 1Gi
max: 2Gi
dedicatedCores: [true]
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: { ... }
Механизмы обеспечения надежности
Миграция и режим обслуживания
Миграция виртуальных машин является важной функцией в управлении виртуализированной инфраструктурой. Она позволяет перемещать работающие виртуальные машины с одного физического узла на другой без их отключения. Миграция виртуальных машин необходима для ряда задач и сценариев:
- Балансировка нагрузки. Перемещение виртуальных машин между узлами позволяет равномерно распределять нагрузку на серверы, обеспечивая использование ресурсов наилучшим образом.
- Перевод узла в режим обслуживания. Виртуальные машины могут быть перемещены с узлов, которые нужно вывести из эксплуатации для выполнения планового обслуживания или обновления программного обеспечения.
- Обновление «прошивки» виртуальных машин. Миграция позволяет обновить «прошивку» виртуальных машины, не прерывая их работу.
Запуск миграции произвольной машины
Далее будет рассмотрен пример миграции выбранной виртуальной машины.
-
Перед запуском миграции проверьте текущий статус виртуальной машины:
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
-
Если необходимо прервать миграцию, удалите соответствующий ресурс
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.
Рассмотрим как это работает на примере:
- Кластер состоит из трех узлов:
master
,workerA
иworkerB
. На worker-узлах включён механизм Fencing. Виртуальная машинаlinux-vm
запущена на узлеworkerA
. - На узле
workerA
возникает проблема (выключилось питание, пропала сеть, и т. д.). - Контроллер проверяет доступность узлов и обнаруживает, что
workerA
недоступен. - Контроллер удаляет узел
workerA
из кластера. - Виртуальная машина
linux-vm
запускается на другом подходящем узле (workerB
).