Общедоступная версия. Готово к использованию в production-средах.
Компоненты модуля необходимо развёртывать на физических серверах (bare-metal).
Установка на виртуальные машины допустима только в демонстрационных целях, но при этом должна быть включена вложенная виртуализация (nested virtualization). Если модуль развёрнут на виртуальных машинах, техническая поддержка не предоставляется.
Возможности масштабирования
Модуль поддерживает следующую конфигурацию:
- максимальное количество узлов:
1000; - максимальное количество виртуальных машин:
50000.
Модуль не накладывает дополнительных ограничений и совместим с любым оборудованием, поддерживаемым операционными системами, на которые он может быть установлен.
Требования к программному и аппаратному обеспечению
Требования к аппаратному обеспечению для модуля виртуализации совпадают с требованиями, предъявляемыми к Deckhouse Kubernetes Platform, с дополнительным требованием поддержки виртуализации CPU на хостах, где будут запускаться виртуальные машины.
Дополнительные требования для поддержки виртуализации
На всех узлах кластера, где планируется запуск виртуальных машин, необходимо обеспечить поддержку аппаратной виртуализации:
- Процессор: поддержка инструкций Intel-VT (VMX) или AMD-V (SVM);
- BIOS/UEFI: включена поддержка аппаратной виртуализации в настройках BIOS/UEFI.
Обеспечение стабильной работы механизмов живой миграции требует использования идентичной версии ядра Linux на всех узлах кластера.
Это связано с тем, что различия в версиях ядра могут привести к несовместимости интерфейсов, системных вызовов и особенностей работы с ресурсами, что может нарушить процесс миграции виртуальных машин.
Поддерживаемые гостевые ОС
Модуль виртуализации поддерживает операционные системы, работающие на архитектурах x86 и x86-64, в качестве гостевых ОС. Для корректной работы в режиме паравиртуализации необходимо установить драйверы VirtIO, обеспечивающие эффективное взаимодействие между виртуальной машиной и гипервизором.
Успешный запуск операционной системы определяется следующими критериями:
- корректная установка и загрузка ОС;
- бесперебойная работа основных компонентов, таких как сеть и хранилище;
- отсутствие сбоев или ошибок в процессе работы.
Для операционных систем семейства Linux рекомендуется использовать образы гостевых ОС с поддержкой cloud-init, что позволяет выполнять инициализацию виртуальных машин после их создания.
Для операционных систем семейства Windows платформа поддерживает инициализацию с помощью autounattend установки.
Поддерживаемые конфигурации виртуальных машин
- Максимальное число поддерживаемых ядер:
248. - Максимальный объем оперативной памяти:
1024 ГБ. - Максимальное количество подключаемых блочных устройств:
16.
Поддерживаемые хранилища
Диски виртуальных машин создаются на основе ресурсов PersistentVolume. Для управления этими ресурсами и выделения дискового пространства в кластере должно быть развернуто одно или несколько поддерживаемых хранилищ:
| Хранилище | Расположение дисков |
|---|---|
| sds-local-volume | Локальное |
| sds-replicated-volume | Реплики на узлах кластера |
| Ceph-кластер | Внешнее хранилище |
| NFS (Network File System) | Внешнее хранилище |
| TATLIN.UNIFIED (Yadro) | Внешнее хранилище |
| Huawei Dorado | Внешнее хранилище |
| HPE 3par | Внешнее хранилище |
Порядок установки
-
Разверните кластер Deckhouse Kubernetes Platform по инструкции.
-
Для хранения данных виртуальных машин (виртуальные диски и образы) включите одно или несколько поддерживаемых хранилищ.
-
Установите
StorageClassпо умолчанию.# Укажите имя своего объекта StorageClass. DEFAULT_STORAGE_CLASS=replicated-storage-class sudo -i d8 k patch mc global --type='json' -p='[{"op": "replace", "path": "/spec/settings/defaultClusterStorageClass", "value": "'"$DEFAULT_STORAGE_CLASS"'"}]' -
Включите модуль
console, который позволит управлять компонентами виртуализации через веб-интерфейс Deckhouse (данная возможность доступна только пользователям EE-редакции). -
Включите модуль
virtualization:Включение модуля
virtualizationпредполагает рестарт kubelet/containerd и агентов cilium на всех узлах, где предполагается запуск виртуальных машин. Это необходимо для настройки связности containerd и DVCR.Для включения модуля
virtualizationсоздайте ресурс ModuleConfig с настройками модуля.Перед включением модуля внимательно ознакомьтесь с его настройками в Руководстве администратора.
Пример конфигурации модуля:
d8 k apply -f - <<EOF apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: virtualization spec: enabled: true # Включить модуль. settings: dvcr: storage: persistentVolumeClaim: size: 50G type: PersistentVolumeClaim virtualMachineCIDRs: - 10.66.10.0/24 version: 1 EOFОтследить готовность модуля можно с использованием следующей команды:
d8 k get modules virtualizationПример вывода:
NAME WEIGHT SOURCE PHASE ENABLED READY virtualization 900 deckhouse Ready True TrueФаза модуля должна быть
Ready.
Размещение компонент по узлам
Распределение компонентов по узлам кластера зависит от его конфигурации. Например, в кластере могут присутствовать:
- только master-узлы, для запуска компонент плоскости управления и нагрузки;
- только master-узлы и worker-узлы;
- master-узлы, system-узлы и worker-узлы;
- другие комбинации (в зависимости от архитектуры).
Под worker-узлами понимаются узлы, на которых нет ограничений (taints), мешающих запуску обычной рабочей нагрузки (подов, виртуальных машин).
В таблице приведены основные компоненты control plane виртуализации и узлы, на которых они могут быть размещены. Компоненты распределяются по приоритету — если в кластере есть подходящий тип узлов, компонент будет размещён на нём.
| Название компонента | Группа узлов | Комментарий |
|---|---|---|
cdi-operator-* |
system/worker | |
cdi-apiserver-* |
master | |
cdi-deployment-* |
system/worker | |
virt-api-* |
master | |
virt-controller-* |
system/worker | |
virt-operator-* |
system/worker | |
virtualization-api-* |
master | |
virtualization-controller-* |
master | |
virtualization-audit-* |
system/worker | |
dvcr-* |
system/worker | На узле должно быть доступно хранилище |
virt-handler-* |
Все узлы кластера | |
vm-route-forge-* |
Все узлы кластера |
Компоненты для создания и загрузки (импорта) образов или дисков виртуальных машин (они запускаются только на время создания или загрузки):
| Название компонента | Группа узлов | Комментарий |
|---|---|---|
importer-* |
system/worker | |
uploader-* |
system/worker |
Обновление модуля
Модуль virtualization использует пять каналов обновлений, предназначенных для использования в разных окружениях, к которым с точки зрения надежности применяются разные требования:
| Канал обновлений | Описание |
|---|---|
| Alpha | Наименее стабильный канал обновлений с наиболее частым появлением новых версий. Ориентирован на кластеры разработки с небольшим количеством разработчиков. |
| Beta | Ориентирован на кластеры разработки, как и канал обновлений Alpha. Получает версии, предварительно опробованные на канале обновлений Alpha. |
| Early Access | Рекомендуемый канал обновлений, если вы не уверены в выборе. Подойдет для кластеров, в которых идет активная работа (запускаются, дорабатываются новые приложения и т. п.). Обновления функционала до этого канала обновлений доходят не ранее чем через одну неделю после их появления в релизе. |
| Stable | Стабильный канал обновлений для кластеров, в которых закончена активная работа и преимущественно осуществляется эксплуатация. Обновления функционала до этого канала обновлений доходят не ранее чем через две недели после их появления в релизе. |
| Rock Solid | Наиболее стабильный канал обновлений. Подойдет для кластеров, которым необходимо обеспечить повышенный уровень стабильности. Обновления функционала до этого канала доходят не ранее чем через месяц после их появления в релизе. |
Компоненты модуля virtualization могут обновляться автоматически, либо с ручным подтверждением по мере выхода обновлений в каналах обновления.
При обновлении модуля компоненты можно разделить на две категории:
- компоненты управления ресурсами виртуализации (управляющий слой);
- компоненты запуска виртуальных машин (“прошивка”).
Обновление компонентов управляющего слоя не влияет на работу уже запущенных виртуальных машин, но может привести к кратковременному разрыву установленных соединений по VNC/последовательному порту на время рестарта компонента управляющего слоя.
Обновления в прошивке виртуальных машин в процессе обновления платформы могут потребовать миграции виртуальных машин для перехода на новую версию “прошивки”. Миграция при обновлении осуществляется один раз. Если она проходит неуспешно, владельцу виртуальной машины потребуется выполнить её самостоятельно, выполнив evict, либо перезагрузку виртуальной машины.
Информацию по версиям, доступным на каналах обновления, можно получить на сайте https://releases.deckhouse.ru/.