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

Компоненты модуля необходимо развёртывать на физических серверах (bare-metal).

Установка на виртуальные машины допустима только в демонстрационных целях, но при этом должна быть включена вложенная виртуализация (nested virtualization). Если модуль развёрнут на виртуальных машинах, техническая поддержка не предоставляется.

Возможности масштабирования

Модуль поддерживает следующую конфигурацию:

  • максимальное количество узлов: 1000;
  • максимальное количество виртуальных машин: 50000.

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

Требования к аппаратному обеспечению

  1. Отдельная машина для установки.

    Здесь будет запускаться установщик Deckhouse. Это может быть ноутбук администратора или любой другой компьютер, который не планируется добавлять в кластер. Требования к этой машине:

    • ОС: Windows 10+, macOS 10.15+, Linux (Ubuntu 18.04+, Fedora 35+);
    • установленный Docker Engine или Docker Desktop (инструкции для Ubuntu, macOS, Windows);
    • HTTPS-доступ к хранилищу образов контейнеров registry.deckhouse.ru;
    • SSH-доступ по ключу к узлу, который будет master-узлом будущего кластера;
    • SSH-доступ по ключу к узлу, который будет worker-узлом будущего кластера (если кластер будет состоять не из одного master-узла).
  2. Сервер для master-узла.

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

    Требования к физическому bare-metal-серверу:

    • Ресурсы:
      • процессор:
        • архитектура x86-64;
        • поддержка инструкций Intel-VT (VMX) или AMD-V (SVM);
        • не менее 4 ядер;
      • ОЗУ не менее 8 ГБ;
      • дисковое пространство:
        • не менее 60 ГБ;
        • быстрый диск (400+ IOPS);
    • ОС из списка поддерживаемых:
      • ядро Linux версии 5.7 или новее;
    • Уникальный hostname среди всех серверов будущего кластера;
    • Сетевые доступы:
      • HTTPS-доступ к хранилищу образов контейнеров registry.deckhouse.ru;
      • доступ к репозиториям пакетов используемой ОС;
      • SSH-доступ от машины для установки (см. п.1) по ключу;
      • сетевой доступ от машины для установки (см. п.1) по порту 22322/TCP;
    • Требуемое ПО:
      • пакеты cloud-utils и cloud-init должны быть установлены.

    Container runtime будет установлен автоматически, поэтому пакеты containerd и/или docker устанавливать не нужно.

  3. Серверы для worker-узлов.

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

    Требования к физическому bare metal-серверу:

    • Ресурсы:
      • процессор:
        • архитектура x86-64;
        • поддержка инструкций Intel-VT (VMX) или AMD-V (SVM);
        • не менее 4 ядер;
      • ОЗУ не менее 8 ГБ;
      • дисковое пространство:
        • не менее 60 ГБ;
        • быстрый диск (400+ IOPS);
        • дополнительные диски для программно-определяемого хранилища;
    • ОС из списка поддерживаемых:
      • ядро Linux версии 5.7 или новее;
    • Уникальный hostname среди всех серверов будущего кластера;
    • Сетевые доступы:
      • HTTPS-доступ к хранилищу образов контейнеров registry.deckhouse.ru;
      • доступ к репозиториям пакетов используемой ОС;
      • SSH-доступ от машины для установки (см. п.1) по ключу;
    • Требуемое ПО:
      • пакеты cloud-utils и cloud-init должны быть установлены (названия могут отличаться в зависимости от выбранной ОС).

    Container runtime будет установлен автоматически, поэтому пакеты containerd и/или docker устанавливать не нужно.

  4. Оборудование для хранилища.

    В зависимости от выбранного хранилища могут потребоваться дополнительные ресурсы. Подробности смотрите в разделе Управление хранилищами.

Поддерживаемые ОС для узлов платформы

Дистрибутив Linux Поддерживаемые версии
РЕД ОС 7.3, 8.0
РОСА Сервер 7.9, 12.4, 12.5.1
ALT Linux p10, 10.0, 10.1, 10.2, 11
Astra Linux Special Edition 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.8
CentOS 7, 8, 9
Debian 10, 11, 12
Ubuntu 18.04, 20.04, 22.04, 24.04

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

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

Поддерживаемые гостевые ОС

Модуль виртуализации поддерживает операционные системы, работающие на архитектурах x86 и x86-64, в качестве гостевых ОС. Для корректной работы в режиме паравиртуализации необходимо установить драйверы VirtIO, обеспечивающие эффективное взаимодействие между виртуальной машиной и гипервизором.

Успешный запуск операционной системы определяется следующими критериями:

  • корректная установка и загрузка ОС;
  • бесперебойная работа основных компонентов, таких как сеть и хранилище;
  • отсутствие сбоев или ошибок в процессе работы.

Для операционных систем семейства Linux рекомендуется использовать образы гостевых ОС с поддержкой cloud-init, что позволяет выполнять инициализацию виртуальных машин после их создания.

Для операционных систем семейства Windows платформа поддерживает инициализацию с помощью autounattend установки.

Поддерживаемые конфигурации виртуальных машин

  • Максимальное число поддерживаемых ядер: 248.
  • Максимальный объем оперативной памяти: 1024 ГБ.

Поддерживаемые хранилища

Виртуальные машины используют ресурсы PersistentVolume. Для управления этими ресурсами и выделения дискового пространства в кластере должно быть установлено одно или несколько поддерживаемых хранилищ:

Хранилище Расположение дисков
sds-local-volume Локальное
sds-replicated-volume Реплики на узлах кластера
Ceph-кластер Внешнее хранилище
NFS (Network File System) Внешнее хранилище
TATLIN.UNIFIED (Yadro) Внешнее хранилище
Huawei Dorado Внешнее хранилище
HPE 3par Внешнее хранилище

Порядок установки

  1. Разверните кластер Deckhouse Kubernetes Platform по инструкции.

  2. Для хранения данных виртуальных машин (виртуальные диски и образы) включите одно или несколько поддерживаемых хранилищ.

  3. Установите 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"'"}]'
    
  4. Включите модуль console, который позволит управлять компонентами виртуализации через веб-интерфейс Deckhouse (данная возможность доступна только пользователям EE-редакции).

  5. Включите модуль 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
              storageClassName: sds-replicated-thin-r1
            type: PersistentVolumeClaim
        virtualMachineCIDRs:
          - 10.66.10.0/24
      version: 1
    EOF
    

    Здесь:

    • блок .spec.settings.dvcr описывает настройки для репозитория хранения образов виртуальных машин. В нём указывается размер хранилища предоставляемого для хранения образов .spec.settings.dvcr.storage.persistentVolumeClaim.size и класс хранилища .spec.settings.dvcr.storage.persistentVolumeClaim.storageClassName;
    • в блоке .spec.settings.virtualMachineCIDRs задаётся список подсетей. Адреса виртуальных машин будут выделяться автоматически или по по запросу из заданных диапазонов подсетей по порядку.

    Подсети блока .spec.settings.virtualMachineCIDRs не должны пересекаться с подсетями узлов, подсетью сервисов и подов.

    Запрещено удалять подсети, если адреса из них уже выданы виртуальным машинам.

    Отследить готовность модуля можно с использованием следующей команды:

    d8 k get modules virtualization
    

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

    NAME             WEIGHT   SOURCE      PHASE   ENABLED   READY
    virtualization   900      deckhouse   Ready   True      True
    

    Фаза модуля должна быть Ready.

Обновление модуля

Модуль virtualization использует пять каналов обновлений, предназначенных для использования в разных окружениях, к которым с точки зрения надежности применяются разные требования:

Канал обновлений Описание
Alpha Наименее стабильный канал обновлений с наиболее частым появлением новых версий. Ориентирован на кластеры разработки с небольшим количеством разработчиков.
Beta Ориентирован на кластеры разработки, как и канал обновлений Alpha. Получает версии, предварительно опробованные на канале обновлений Alpha.
Early Access Рекомендуемый канал обновлений, если вы не уверены в выборе. Подойдет для кластеров, в которых идет активная работа (запускаются, дорабатываются новые приложения и т. п.). Обновления функционала до этого канала обновлений доходят не ранее чем через одну неделю после их появления в релизе.
Stable Стабильный канал обновлений для кластеров, в которых закончена активная работа и преимущественно осуществляется эксплуатация. Обновления функционала до этого канала обновлений доходят не ранее чем через две недели после их появления в релизе.
Rock Solid Наиболее стабильный канал обновлений. Подойдет для кластеров, которым необходимо обеспечить повышенный уровень стабильности. Обновления функционала до этого канала доходят не ранее чем через месяц после их появления в релизе.

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

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

  • компоненты управления ресурсами виртуализации (управляющий слой);
  • компоненты запуска виртуальных машин (“прошивка”).

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

Обновления в прошивке виртуальных машин в процессе обновления платформы могут потребовать миграции виртуальных машин для перехода на новую версию “прошивки”. Миграция при обновлении осуществляется один раз. Если она проходит неуспешно, владельцу виртуальной машины потребуется выполнить её самостоятельно, выполнив evict, либо перезагрузку виртуальной машины.

Информацию по версиям, доступным на каналах обновления, можно получить на сайте https://releases.deckhouse.ru/.