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

Руководство описывает, как настроить модуль virtualization и управлять его кластерными ресурсами.

Права администратора включают и управление проектными ресурсами, которые описаны в руководстве пользователя.

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

Конфигурация модуля virtualization задаётся в ресурсе ModuleConfig. Ниже приведён пример базовой настройки, в которой указаны класс Ingress-контроллера, хранилище образов и подсеть для виртуальных машин:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: virtualization
spec:
  enabled: true
  version: 1
  settings:
    ingressClass: nginx # опциональный параметр
    dvcr:
      storage:
        persistentVolumeClaim:
          size: 50G
          storageClassName: rv-thin-r1
        type: PersistentVolumeClaim
    virtualMachineCIDRs:
      - 10.66.10.0/24

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

За состояние модуля отвечает параметр .spec.enabled. Значение true включает модуль, значение false выключает его.

Выключение модуля останавливает все системные компоненты, которые создают и запускают виртуальные машины (ВМ), поэтому по умолчанию модуль выключить нельзя. Чтобы это стало возможным, добавьте на ModuleConfig virtualization аннотацию modules.deckhouse.io/allow-disabling со значением true.

Перед выключением подготовьте кластер:

1. Удалите все ресурсы модуля, включая виртуальные машины, диски и образы.

2. Убедитесь, что в кластере не осталось активных ресурсов:

   d8 k get virtualization -A
   d8 k get virtualization-cluster

После этого отредактируйте ModuleConfig virtualization:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: virtualization
  annotations:
    modules.deckhouse.io/allow-disabling: "true"
spec:
  enabled: false
  version: 1
  settings:
    # Укажите существующие настройки.

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

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

Настройки Ingress

Образы виртуальных машин загружаются в кластер через Ingress-контроллер, класс которого определяет параметр .spec.settings.ingressClass. Указывать его необязательно, и если параметр не задан, модуль использует глобальное значение из конфигурации Deckhouse Platform (DP). Задавайте его только тогда, когда для загрузки образов нужен отдельный Ingress-контроллер.

Пример:

spec:
  settings:
    ingressClass: nginx

apiVersion: deckhouse.io/v1
kind: IngressNginxController
metadata:
  name: nginx
spec:
  config:
    worker-shutdown-timeout: 1800s  # 30 минут или более при необходимости

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

В блоке .spec.settings.virtualMachineCIDRs перечисляются подсети в формате CIDR, из которых DP выдаёт IP-адреса виртуальным машинам автоматически или по запросу. Указывайте начальный адрес подсети, выровненный по маске, например 192.168.1.192/27, а не произвольный адрес из диапазона.

Пример:

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

Первый и последний адреса каждой подсети зарезервированы и виртуальным машинам не выдаются. Например, в подсети 10.66.10.0/24 недоступны адреса 10.66.10.0 и 10.66.10.255.

Блок можно не задавать. Модуль в этом случае включится, но работать с адресами виртуальных машин уже нельзя, а именно:

• создать или использовать ресурс VirtualMachineIPAddress нельзя;
• виртуальная машина не может запросить сеть Main в параметре .spec.networks;
• параметр .spec.networks виртуальной машины не может быть пустым.

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

Образы виртуальных машин DP хранит во внутреннем хранилище образов контейнеров (DVCR), которое размещается на постоянном томе кластера. Оттуда образы попадают на диски виртуальных машин, поэтому от размера тома зависит, сколько образов поместится в кластер.

Размер и класс хранения

Размер тома и класс хранения задаются в блоке .spec.settings.dvcr.storage. Чтобы расширить хранилище, увеличьте размер тома.

Классы хранения для образов и дисков

Класс хранения для образа или диска выбирает владелец проекта. Вы можете ограничить этот выбор и задать класс, который применяется по умолчанию. За образы отвечает блок .spec.settings.virtualImages, за диски — блок .spec.settings.virtualDisks.

Пример:

spec:
  settings:
    virtualImages:
      allowedStorageClassSelector:
        matchNames:
          - sc-1
          - sc-2
      defaultStorageClassName: sc-1
    virtualDisks:
      allowedStorageClassSelector:
        matchNames:
          - sc-3
      defaultStorageClassName: sc-3

Оба блока устроены одинаково и оба необязательны. Параметр allowedStorageClassSelector.matchNames перечисляет классы, которые разрешено выбирать в спецификации VirtualImage и VirtualDisk, а defaultStorageClassName задаёт класс для тех ресурсов, где параметр .spec.persistentVolumeClaim.storageClassName не задан.

Очистка хранилища образов

Когда образы и диски удаляются из кластера, их данные какое-то время остаются в DVCR. Чтобы хранилище не заполнялось неактуальными данными, DP запускает сборку мусора по расписанию. По умолчанию она выполняется ежедневно в 02:00. Задать своё расписание можно параметром .spec.settings.dvcr.gc.schedule в ModuleConfig virtualization.

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

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: virtualization
spec:
  # ...
  settings:
    dvcr:
      gc:
        schedule: "0 20 * * *"
  # ...

d8 k -n d8-virtualization exec deploy/dvcr -- dvcr-cleaner gc check

Found 2 cvi, 5 vi, 1 vd manifests in registry
Found 1 cvi, 5 vi, 11 vd resources in cluster
  Total     Used    Avail     Use%
36.3GiB  13.1GiB  22.4GiB      39%
Images eligible for cleanup:
KIND                   NAMESPACE            NAME
ClusterVirtualImage                         debian-12
VirtualDisk            default              debian-10-root
VirtualImage           default              ubuntu-2404

Образы

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

Образ появляется в кластере в три шага:

1. Администратор создаёт ресурс ClusterVirtualImage и указывает в нём источник данных.
2. DP загружает образ из этого источника во внутреннее хранилище (DVCR).
3. Загруженный образ становится доступен для создания дисков.

Источником образа может быть HTTP-сервер с файлом образа, хранилище образов контейнеров или файл на вашем компьютере, который вы загружаете из командной строки. Кроме того, образ можно создать из другого образа, из диска виртуальной машины или из снимка диска.

Ход создания образа показывает колонка PHASE в выводе d8 k get cvi, её значения описаны в поле .status.phase. Следить за созданием в реальном времени помогает ключ -w, а если образ надолго остаётся не готов, причину подскажет блок .status.conditions и команда d8 k describe cvi.

Пока образ не перешёл в фазу Ready, блок .spec можно менять, и после изменения загрузка начнётся заново. У готового образа блок .spec изменить уже нельзя. Все параметры образа описаны в ClusterVirtualImage.

Типы и форматы образов

Образы бывают двух видов:

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

Готовые образы с предустановленной системой публикуют разработчики дистрибутивов. В таблице приведены страницы загрузки и имена пользователей, которые заданы в этих образах по умолчанию:

DP принимает файл образа в следующих форматах:

• qcow2;
• raw;
• vmdk;
• vdi;
• vhd;
• vhdx.

Образ можно передать сжатым алгоритмом gz, xz или zst, DP распакует его при загрузке.

Тип и размер образа DP определяет сам и записывает их в статус ресурса. Размеров два, и оба видны в выводе команды d8 k get cvi -o wide:

• STOREDSIZE — объём, который образ занимает в хранилище. Для образа, загруженного в сжатом виде, он меньше распакованного размера. По этой колонке удобно оценивать, сколько места образы занимают в DVCR.
• UNPACKEDSIZE — размер образа после распаковки. Он задаёт минимальный размер диска, который получится создать из этого образа.

Создание кластерного образа с HTTP-сервера

Проще всего создать образ, указав ссылку на файл, который лежит на HTTP-сервере.

Создание кластерного образа из хранилища образов контейнеров

DP умеет забирать образ из внешнего хранилища образов контейнеров, но файл диска должен лежать в образе контейнера по пути /disk. Ниже показано, как подготовить такой образ контейнера и создать из него кластерный образ.

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

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

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

Класс виртуальной машины (ВМ) задаёт то, что владелец проекта не настраивает сам, а именно модель виртуального процессора, допустимые сочетания ядер и памяти, а также узлы, на которых ВМ может работать. Описывает эти правила ресурс VirtualMachineClass, и через него вы управляете тем, как рабочие нагрузки проектов распределяются по узлам кластера.

При первичной установке модуль создаёт класс generic с моделью процессора Nehalem. Эта модель старая, но поддерживается любым современным процессором, поэтому ВМ такого класса запускаются на любом узле кластера и мигрируют между узлами без ограничений.

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

d8 k get virtualmachineclass

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

NAME      PHASE   ISDEFAULT   AGE
generic   Ready               6d1h

Изменить у любого класса можно всё, кроме блока .spec.cpu, потому что модель процессора фиксируется при создании ресурса. Класс generic разрешено и менять, и удалять, но заново он не создастся, потому что модуль добавляет его только при первичной установке.

Владелец проекта указывает класс в параметре .spec.virtualMachineClassName виртуальной машины:

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

VirtualMachineClass по умолчанию

Один из классов можно назначить классом по умолчанию. DP подставит его имя в параметр .spec.virtualMachineClassName, если владелец проекта не указал класс сам.

Класс по умолчанию помечается аннотацией virtualmachineclass.virtualization.deckhouse.io/is-default-class со значением true. Такой класс в кластере может быть только один, поэтому, чтобы назначить новый, сначала снимите аннотацию с текущего.

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

1. Посмотрите, какие классы есть в кластере:

   d8 k get vmclass

   Пример вывода, в котором класса по умолчанию нет:

   NAME                      PHASE   ISDEFAULT   AGE
   generic                   Ready               1d
   host-passthrough-custom   Ready               1d
   

2. Назначьте класс по умолчанию:

   d8 k annotate vmclass host-passthrough-custom virtualmachineclass.virtualization.deckhouse.io/is-default-class=true

3. Убедитесь, что аннотация проставлена:

   d8 k get vmclass

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

   NAME                      PHASE   ISDEFAULT   AGE
   generic                   Ready               1d
   host-passthrough-custom   Ready   true        1d
   

Теперь виртуальные машины, созданные без указания класса, получат класс host-passthrough-custom.

Настройки VirtualMachineClass

Класс состоит из трёх блоков, каждый из которых отвечает за свою группу настроек:

apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: <VMCLASS_NAME>
  # Аннотация назначает класс классом по умолчанию, её можно не указывать.
  # annotations:
  #   virtualmachineclass.virtualization.deckhouse.io/is-default-class: "true"
spec:
  # Параметры виртуального процессора. Блок обязателен и после создания ресурса не меняется.
  cpu: ...

  # Правила размещения виртуальных машин по узлам. Блок необязателен.
  # Изменения применяются ко всем машинам этого класса.
  nodeSelector: ...

  # Политика подбора ресурсов для виртуальных машин. Блок необязателен.
  # Изменения применяются ко всем машинам этого класса.
  sizingPolicies: ...

Дальше блоки разобраны по отдельности.

Виртуальный процессор

Блок .spec.cpu определяет, какой процессор увидит гостевая ОС. От него зависит и то, между какими узлами ВМ сможет мигрировать.

Ниже приведены примеры для каждого типа процессора.

• Набор процессорных инструкций, обязательных для ВМ. Задаётся типом Features:

  spec:
    cpu:
      features:
        - vmx
      type: Features

  Как настроить vCPU в веб-интерфейсе в форме создания классов ВМ:

  1. В блоке «Настройки ЦП» в поле «Тип» выберите Features.
  2. В поле «Обязательный набор поддерживаемых инструкций» выберите нужные инструкции.
  3. Нажмите кнопку «Создать».

• Универсальный процессор для заданного набора узлов. Задаётся типом Discovery:

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

  Как выполнить операцию в веб-интерфейсе в форме создания классов ВМ:

  1. В блоке «Настройки ЦП» в поле «Тип» выберите Discovery.
  2. Нажмите кнопку «Добавить» в блоке «Условия для создания универсального процессора» → «Лейблы и выражения».
  3. Задайте «Ключ», «Оператор» и «Значение», они соответствуют параметру .spec.cpu.discovery.nodeSelector.
  4. Нажмите клавишу «Enter», чтобы подтвердить параметры ключа.
  5. Нажмите кнопку «Создать».

• Процессор, близкий к процессору узла. Задаётся типом Host. Гостевая ОС получает почти полный набор инструкций узла, поэтому производительность выше, чем у фиксированной модели. ВМ такого класса мигрирует только между узлами со схожими процессорами. Например, между узлами с процессорами Intel и AMD миграция невозможна, как и между процессорами разных поколений, если их наборы инструкций различаются.

  spec:
    cpu:
      type: Host

  Как выполнить операцию в веб-интерфейсе в форме создания классов ВМ:

  1. В блоке «Настройки ЦП» в поле «Тип» выберите Host.
  2. Нажмите кнопку «Создать».

• Процессор узла без изменений. Задаётся типом HostPassthrough. ВМ такого класса мигрирует только на узел, процессор которого в точности совпадает с процессором исходного узла.

  spec:
    cpu:
      type: HostPassthrough

  Как выполнить операцию в веб-интерфейсе в форме создания классов ВМ:

  1. В блоке «Настройки ЦП» в поле «Тип» выберите HostPassthrough.
  2. Нажмите кнопку «Создать».

• Конкретная модель процессора с заранее известным набором инструкций. Задаётся типом Model. Сначала посмотрите, какие модели поддерживает нужный узел:

  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

  Здесь <NODE_NAME> — имя узла кластера.

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

  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
  

  Затем укажите выбранную модель в спецификации класса:

  spec:
    cpu:
      model: IvyBridge
      type: Model

  Как выполнить операцию в веб-интерфейсе в форме создания классов ВМ:

  1. В блоке «Настройки ЦП» в поле «Тип» выберите Model.
  2. В поле «Модель» выберите модель процессора.
  3. Нажмите кнопку «Создать».

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

Ниже показано, как подобрать типы процессора в кластере с разнородными узлами.

Ниже разобран кластер из четырёх узлов. Два узла с лейблом group=blue оснащены процессором «CPU X» с тремя наборами инструкций, два других с лейблом group=green — более новым процессором «CPU Y» с четырьмя наборами.

Такому кластеру подойдут три класса:

• universal — ВМ запускаются на любом узле и мигрируют между всеми четырьмя. DP возьмёт набор инструкций, общий для обоих процессоров, поэтому совместимость максимальная, а часть возможностей «CPU Y» останется неиспользованной;
• cpuX — ВМ запускаются только на узлах с «CPU X» и мигрируют между ними, используя все инструкции этого процессора;
• cpuY — то же самое для узлов с «CPU Y».

Классы для такого кластера выглядят так:

---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: universal
spec:
  cpu:
    # Пустой discovery означает, что учитываются все узлы кластера.
    discovery: {}
    type: Discovery
---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: cpuX
spec:
  cpu:
    discovery:
      nodeSelector:
        matchExpressions:
          - key: group
            operator: In
            values: ["blue"]
    type: Discovery
---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: cpuY
spec:
  cpu:
    discovery:
      nodeSelector:
        matchExpressions:
          - key: group
            operator: In
            values: ["green"]
    type: Discovery

Размещение по узлам

Необязательный блок .spec.nodeSelector ограничивает набор узлов, на которых работают виртуальные машины (ВМ) этого класса. Узлы отбираются по лейблам:

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

Как выполнить операцию в веб-интерфейсе в форме создания классов ВМ:

1. Нажмите кнопку «Добавить» в блоке «Условия планирования ВМ на узлах» → «Лейблы и выражения».
2. Задайте «Ключ», «Оператор» и «Значение», они соответствуют параметру .spec.nodeSelector.
3. Нажмите клавишу «Enter», чтобы подтвердить параметры ключа.
4. Нажмите кнопку «Создать».

Политика сайзинга

Блок .spec.sizingPolicies задаёт, какие сочетания ядер, доли ядра и памяти разрешены виртуальным машинам (ВМ) этого класса.

Политика состоит из списка правил, каждое из которых действует на свой диапазон ядер. Диапазон задаётся обязательным блоком cores, и диапазоны разных правил пересекаться не могут, иначе DP отклонит такой класс.

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

- cores:
    min: 1
    max: 4
  # ...
- cores:
    min: 5 # Начало следующего диапазона на единицу больше предыдущего max.
    max: 8

Недопустимая структура, где значение 4 попадает сразу в два диапазона:

- cores:
    min: 1
    max: 4
  # ...
- cores:
    min: 4
    max: 8

Оставлять разрывы между диапазонами DP не запрещает, но виртуальная машина, число ядер которой не попало ни в один диапазон, останется без политики. Поэтому начинайте очередной диапазон со значения, следующего за max предыдущего.

Внутри диапазона задаются требования к памяти и к доле ядра:

• memory — минимум и максимум памяти. Указывается либо на весь диапазон, либо на одно ядро через вложенный блок memory.perCore.
• coreFractions — список разрешённых долей ядра, например [25, 50, 100] для 25%, 50% и 100%. Если владелец проекта задал параметр coreFraction виртуальной машины явно, значение должно быть из этого списка.
• defaultCoreFraction — доля ядра, которую получит виртуальная машина, если coreFraction в ней не задан. Значение должно входить в список coreFractions. Когда параметр не указан, применяется 100%.

Правило, в котором нет ни memory, ни coreFractions, ничего не ограничивает, поэтому задавайте хотя бы одно из них.

В коммерческих редакциях DP параметру defaultCoreFraction можно задать значение Auto. Тогда долю ядра для ВМ без явного coreFraction подбирает вертикальное автомасштабирование. Auto — это режим, а не доля ядра, поэтому в списке coreFractions его быть не должно.

spec:
  sizingPolicies:
    - cores:
        min: 1
        max: 8
      coreFractions: [10, 25, 50, 100]
      defaultCoreFraction: Auto

Значение Auto принимается, только когда доступны обе возможности:

• вертикальное автомасштабирование виртуальных машин, которое включается само в коммерческих редакциях DP при включённом модуле vertical-pod-autoscaler;
• изменение числа ядер и объёма памяти без перезапуска, которое включается функцией HotplugCPUAndMemoryWithInPlaceResize в параметре .spec.settings.featureGates модуля.

Если хотя бы одна из них недоступна, DP отклонит создание такого класса.

Новое значение по умолчанию применяется только к виртуальным машинам, созданным после его изменения. У существующей машины прежнее значение уже записано в её спецификации и остаётся там, пока владелец проекта не задаст другое.

Примеры зависимости объёма памяти от числа ядер:

• Параметр memory задаёт границы, одинаковые для всего диапазона ядер:

  - cores:
      min: 1
      max: 4
    memory:
      min: 2Gi
      max: 8Gi

  Виртуальная машина с любым числом ядер от 1 до 4 получает от 2 до 8 ГиБ памяти, и число ядер на эти границы не влияет.

• Параметр memory.perCore задаёт границы в расчёте на одно ядро, а итоговые границы получаются умножением на число ядер:

  - cores:
      min: 1
      max: 4
    memory:
      perCore:
        min: 1Gi
        max: 2Gi

  Для такой политики допустимый объём памяти растёт вместе с числом ядер:

  • 1 ядро — от 1 до 2 ГиБ;
  • 2 ядра — от 2 до 4 ГиБ;
  • 3 ядра — от 3 до 6 ГиБ;
  • 4 ядра — от 4 до 8 ГиБ.

• Параметр memory.step ограничивает набор допустимых значений памяти шагом сетки, чтобы владелец проекта не выбирал произвольные объёмы.

  Вместе с memory.min и memory.max шаг отсчитывается от минимума:

  - cores:
      min: 1
      max: 4
    memory:
      min: 2Gi
      max: 8Gi
      step: 1Gi

  Допустимы только значения 2, 3, 4, 5, 6, 7 и 8 ГиБ, а 2,5 или 7,5 ГиБ задать нельзя.

  Вместе с memory.perCore шаг отсчитывается от памяти на одно ядро, и уже полученное значение умножается на число ядер:

  - cores:
      min: 1
      max: 4
    memory:
      perCore:
        min: 1Gi
        max: 2Gi
      step: 512Mi

  На одно ядро допустимы 1, 1,5 и 2 ГиБ, поэтому итоговый объём зависит от числа ядер:

  • 1 ядро — 1, 1,5 или 2 ГиБ;
  • 2 ядра — 2, 3 или 4 ГиБ;
  • 3 ядра — 3, 4,5 или 6 ГиБ;
  • 4 ядра — 4, 6 или 8 ГиБ.

Пример политики, которая покрывает диапазоны от 1 до 248 ядер:

spec:
  sizingPolicies:
    # Для 1-4 ядер доступно от 1 до 8 ГиБ памяти с шагом 512 МиБ,
    # то есть 1 ГиБ, 1,5 ГиБ, 2 ГиБ, 2,5 ГиБ и так далее.
    # Доступны все доли ядра.
    - cores:
        min: 1
        max: 4
      memory:
        min: 1Gi
        max: 8Gi
        step: 512Mi
      coreFractions: [5, 10, 20, 50, 100]
      defaultCoreFraction: 50 # Доля ядра по умолчанию для диапазона 1-4 ядра.
    # Для 5-8 ядер доступно от 5 до 16 ГиБ памяти с шагом 1 ГиБ,
    # то есть 5 ГиБ, 6 ГиБ, 7 ГиБ и так далее.
    # Доли ядра ограничены тремя значениями.
    - cores:
        min: 5
        max: 8
      memory:
        min: 5Gi
        max: 16Gi
        step: 1Gi
      coreFractions: [20, 50, 100]
      defaultCoreFraction: 100 # Доля ядра по умолчанию для диапазона 5-8 ядер.
    # Для 9-16 ядер доступно от 9 до 32 ГиБ памяти с шагом 1 ГиБ.
    # Доли ядра ограничены двумя значениями.
    - cores:
        min: 9
        max: 16
      memory:
        min: 9Gi
        max: 32Gi
        step: 1Gi
      coreFractions: [50, 100]
    # Для 17-248 ядер доступно от 1 до 2 ГиБ памяти на каждое ядро.
    # Доля ядра только 100%.
    - cores:
        min: 17
        max: 248
      memory:
        perCore:
          min: 1Gi
          max: 2Gi
      coreFractions: [100]

Как настроить политики сайзинга в веб-интерфейсе в форме создания классов ВМ:

1. Нажмите кнопку «Добавить» в блоке «Правила выделения ресурсов для виртуальных машин».
2. В блоке «ЦП» в поле «Мин» укажите 1, а в поле «Макс» — 4.
3. В блоке «ЦП» в поле «Разрешить задать доли ядра» выберите по порядку значения 5%, 10%, 20%, 50%, 100%.
4. В блоке «Память» установите переключатель в положение «Объём на 1 ядро».
5. В блоке «Память» в поле «Мин» укажите 1, а в поле «Макс» — 8.
6. В блоке «Память» в поле «Шаг дискретизации» укажите 1.
7. При необходимости добавьте другие диапазоны кнопкой «Добавить».
8. Нажмите кнопку «Создать».

Управление переподпиской на CPU

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

Степенью переподписки управляет параметр coreFraction виртуальной машины, а допустимые его значения вы задаёте в политике сайзинга класса. Параметр определяет долю мощности ядра, которая ВМ гарантирована. Например, при coreFraction: 20% ВМ всегда получит пятую часть ядра, а при наличии свободных ресурсов на узле сможет занять и всё ядро целиком.

Размещая ВМ на узле, DP складывает гарантированные доли всех ВМ узла по формуле Σ(cores × coreFraction / 100). Если сумма превысит число физических ядер, на этом узле ВМ не запустится.

Ниже разобран узел с 4 физическими ядрами и 5 ВМ, у каждой по 2 ядра и coreFraction: 20%. Гарантированная нагрузка составит 5 × 2 × 0,2 = 2 ядра при 10 виртуальных ядрах на 4 физических, то есть переподписка 2,5 к 1. Все пять ВМ разместятся на узле, потому что 2 ядра меньше доступных 4.

Переподписка, заданная жёстко

Список из одного значения не оставляет владельцу проекта выбора, и степень переподписки для всех ВМ класса определяете вы:

apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: oversubscribed
spec:
  sizingPolicies:
    - cores:
        min: 1
        max: 8
      memory:
        perCore:
          min: 1Gi
          max: 8Gi
      coreFractions: [20] # Единственное разрешённое значение.
      defaultCoreFraction: 20

Все ВМ этого класса получают по 20% ядра, что даёт переподписку 5 к 1.

Переподписка на выбор владельца проекта

Список из нескольких значений оставляет выбор за владельцем проекта:

apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
  name: standard
spec:
  sizingPolicies:
    - cores:
        min: 1
        max: 4
      memory:
        perCore:
          min: 1Gi
          max: 8Gi
      coreFractions: [5, 10, 20, 50, 100]
      defaultCoreFraction: 20

Владелец проекта выбирает coreFraction из списка, а если не выбрал, ВМ получает 20%.

Обслуживание узлов и отказоустойчивость ВМ

В этом разделе собраны средства, которые помогают виртуальным машинам (ВМ) пережить обслуживание и отказ узла. Часть из них работает сама, часть требует вашего вмешательства.

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

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

• при балансировке нагрузки, чтобы равномерно распределить ВМ по узлам;
• при выводе узла на обслуживание или обновление, чтобы освободить его от ВМ;
• при обновлении прошивки виртуальных машин, которое иначе потребовало бы их перезапуска.

Перемещение выбранной машины на другой узел

Ниже показано, как переместить выбранную ВМ на другой узел.

Выделенная сеть для миграции

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

Для этого нужно, чтобы модуль sdn был включён, а ресурс SystemNetwork создан и находился в состоянии Ready.

Чтобы направить трафик в выделенную сеть, задайте блок .spec.settings.liveMigration.network в ModuleConfig virtualization. Укажите в нём type: SystemNetwork и имя подготовленной сети в поле systemNetwork.name. После этого все миграции в кластере пойдут по VLAN указанной сети.

spec:
  settings:
    liveMigration:
      network:
        type: SystemNetwork
        systemNetwork:
          name: migration-net

Чтобы вернуть трафик миграции на основную сеть узла, удалите блок network (по умолчанию, если он не задан, используется сеть узла).

Как создать системную сеть в веб-интерфейсе:

1. Перейдите на вкладку «Система», далее в раздел «Сеть» → «SDN» → «Системные сети».
2. Нажмите кнопку «Создать».
3. В открывшемся окне «Создать ресурс» в поле «Имя» введите имя сети.
4. На вкладке «Конфигурация» в поле «Type» выберите тип (VLAN, Access или SRIOVVirtualFunction), в поле «Underlay-сеть» — underlay-сеть, в блоке «VLAN» — идентификатор VLAN. При необходимости задайте параметры блока «IPAM».
5. Нажмите кнопку «Применить».
6. Созданные сети отображаются в списке с колонками «Статус», «Тип», «Underlay-сеть», «VLAN ID» и «IP-пул».

Предварительно в разделах «Сеть» → «SDN» → «Network-классы» и «Underlay-сети» создаются Network-класс (диапазоны VLAN ID и родительские сетевые интерфейсы узлов) и underlay-сеть (участвующие сетевые интерфейсы узлов и режим «Dedicated» или «Shared»).

Проверка ВМ перед обслуживанием узла

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

d8 k get vm -o wide | grep <NODE_NAME>

ВМ со значением False в колонке MIGRATABLE при выводе узла придётся остановить. Живая миграция для них невозможна, и эвакуация завершится ошибкой.

Одного значения в колонке недостаточно. ВМ со значением True и причиной VirtualMachineWaitingForMigrationTarget тоже никуда не поедет, пока подходящий узел не вернётся в планирование, поэтому перед обслуживанием посмотрите причины всех ВМ на узле:

d8 k get vm -o json | jq -r '.items[] | [.metadata.name, (.status.conditions[] | select(.type=="Migratable") | .reason)] | @tsv'

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

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

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

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

d8 k uncordon <NODE_NAME>

Перезапуск виртуальных машин при обслуживании узла

Виртуальную машину не всегда можно перенести на другой узел живой миграцией. Она может быть закреплена за узлом правилами размещения или использовать проброшенное с узла устройство. Причину показывает условие Migratable в статусе ВМ. Такая ВМ продолжает работать и удерживает узел, поэтому обслуживание не завершится, пока её не перезапустят.

Обнаружив такую ВМ при переводе узла в режим обслуживания, DP добавляет на узел аннотацию virtualization.deckhouse.io/virtualmachines-restart-required. Чтобы разрешить перезапуск, добавьте на узел ответную аннотацию:

d8 k annotate node <NODE_NAME> virtualization.deckhouse.io/virtualmachines-restart-approved=""

Здесь <NODE_NAME> — имя узла, который переводится в режим обслуживания.

Перезапускаются только те ВМ, которые нельзя перенести живой миграцией. Гостевая ОС завершает работу штатно, после чего ВМ запускается в соответствии с политикой запуска .spec.runPolicy. Для каждого перезапуска создаётся ресурс VirtualMachineOperation с именем вида node-maintenance-restart-*. Перезапуск прерывает работу приложений внутри ВМ, поэтому согласуйте его с владельцами проектов.

Разрешение не распространяется на ВМ, которые можно перенести живой миграцией (в том числе на те, для которых сейчас нет подходящего узла). Такие ВМ будут перенесены живой миграцией, как только подходящий узел появится.

Разрешение можно дать заранее, при планировании работ. Пока узел не переводят в режим обслуживания, аннотация ни на что не влияет. Обе аннотации DP снимает после освобождения узла, поэтому одно разрешение действует только на одно обслуживание одного узла.

DP реагирует на вытеснение ВМ с узла. Если вытеснение прекратилось по тайм-ауту (параметр .spec.nodeDrainTimeoutSecond ресурса NodeGroup, по умолчанию 10 минут), повторное вытеснение не выполняется. Разрешение, данное после этого, перезапуска не вызовет, и узел придётся освобождать вручную.

Перезапуск освобождает узел, но не гарантирует, что ВМ сразу запустится на другом. Ограничение, из-за которого её нельзя перенести живой миграцией, чаще всего мешает и запуску на другом узле. В этом случае ВМ остаётся в фазе Pending, а в условии Running указывается причина, полученная от планировщика. Обслуживание при этом можно продолжать. ВМ запустится, как только появится подходящий узел, в том числе после возвращения узла в работу командой d8 k uncordon.

Владелец ВМ видит то же самое в условии EvictionRequired в статусе ВМ. Пока узел только готовят к обслуживанию, условие носит предупреждающий характер. После начала вытеснения условие показывает, что произойдёт с ВМ, а именно перенос живой миграцией, перезапуск силами DP или ожидание, если перезапуск не разрешён.

Выключение и перезагрузка узла с виртуальными машинами

Работающие виртуальные машины откладывают выключение и перезагрузку своего узла. DP сам помечает их рабочие нагрузки лейблом pod.deckhouse.io/inhibit-node-shutdown и по нему задерживает выключение узла. Механизм доступен в коммерческих редакциях DP, описан в документации модуля node-manager и включения не требует.

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

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

На узлах, где работает механизм задержки, условие GracefulShutdownPostpone присутствует постоянно. Пока механизм ждёт сигнала на выключение или удерживает узел, условие имеет статус True, а когда удерживать больше нечего, переходит в False. Что именно происходит с узлом, показывает причина в поле reason этого условия:

• WaitingForShutdownSignal — механизм активен и ожидает запроса на выключение узла;
• PodsWithLabelAreRunningOnNode — выключение узла запрошено и отложено, поскольку на узле ещё работают виртуальные машины;
• NoRunningPodsWithLabel — виртуальных машин на узле не осталось, удерживать выключение больше нечем, и оно продолжается.

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

d8 k get node <NODE_NAME> -o jsonpath='{range .status.conditions[?(@.type=="GracefulShutdownPostpone")]}{.reason}{"\n"}{end}'

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

• если ВМ можно мигрировать, то есть условие Migratable имеет статус True, переведите узел в режим обслуживания командой d8 k drain;

• если ВМ мигрировать нельзя, то есть условие Migratable имеет статус False из-за локальных дисков или проброшенных с узла устройств, остановите её командой d8 v stop <VM_NAME>, а после завершения работ запустите командой d8 v start <VM_NAME>.

  Остановка доступна только для политик запуска Manual и AlwaysOnUnlessStoppedManually. Проверьте политику ВМ:

  d8 k -n <NAMESPACE> get vm <VM_NAME> -o jsonpath='{.spec.runPolicy}'

  При политике AlwaysOn команда остановки будет отклонена с причиной NotApplicableForVirtualMachineRunPolicy. В этом случае сначала измените политику, а после завершения работ верните прежнее значение:

  d8 k -n <NAMESPACE> patch vm <VM_NAME> --type merge -p '{"spec":{"runPolicy":"AlwaysOnUnlessStoppedManually"}}'

  Здесь <NAMESPACE> — неймспейс проекта, а <VM_NAME> — имя виртуальной машины.

Вместо ручной остановки можно разрешить DP перезапустить такие ВМ на время обслуживания узла. Менять политику запуска при этом не требуется.

Если ничего из этого не сделать, узел не выключится. О такой ситуации сообщают два алерта. Алерт D8VirtualizationVirtualMachineHoldsNodeMaintenance перечисляет ВМ, которые удерживают узел и ждут решения администратора. Алерт D8VirtualizationNodeEvacuationStuck срабатывает, если ВМ вытеснили с узла, но в течение 15 минут она не мигрировала и не перезапустилась.

Перебалансировка ВМ

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

Перебалансировка решает две задачи:

• выравнивает нагрузку. DP следит за тем, сколько процессорных ресурсов зарезервировано на каждом узле, и, когда узел резервирует больше 80%, переносит часть ВМ на узлы, где зарезервировано меньше 50%;
• восстанавливает корректное размещение. DP проверяет, отвечает ли текущий узел требованиям ВМ и правилам взаимного расположения ВМ. Например, если правила запрещают держать определённые ВМ на одном узле, лишние будут перенесены.

Настройки перебалансировки DP задаёт сам: при включённом модуле descheduler он создаёт ресурс Descheduler с именем virtualization и отбирает в нём только те машины, которые можно перенести живой миграцией.

d8 k get descheduler virtualization -o yaml

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

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

ColdStandby

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

Чтобы механизм работал, выполните два требования:

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

Без Fencing механизм не работает. Недоступная ВМ в этом случае не переезжает, а остаётся на отказавшем узле и возобновляет работу вместе с ним.

Порядок восстановления на примере кластера из трёх узлов master, workerA и workerB, где Fencing включён на обоих worker-узлах, а ВМ linux-vm запущена на workerA:

1. Узел workerA отказывает, например из-за потери питания или сети.
2. Контроллер проверяет доступность узлов и обнаруживает, что workerA не отвечает.
3. Контроллер удаляет workerA из кластера.
4. ВМ linux-vm запускается на другом подходящем узле, в примере это workerB.

USB-устройства

За проброс USB-устройств к виртуальным машинам (ВМ) отвечает системный компонент virtualization-dra, которому на узле нужны три модуля ядра:

• usbip_core;
• usbip_host;
• vhci_hcd.

DP загружает их на узлах сам. Узел, где доступны все три модуля, получает лейбл virtualization.deckhouse.io/usbip=true, и только на таких узлах запускается компонент virtualization-dra. Если модули ядра перестают быть доступны, лейбл снимается, а компонент с узла удаляется.

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

d8 k get nodes -l virtualization.deckhouse.io/usbip=true

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

NAME     STATUS   ROLES    AGE   VERSION
node-1   Ready    worker   10d   v1.34.1

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

d8 k -n d8-virtualization get pods -l app=virtualization-dra -o wide

Узел, которого нет в выводе, загрузить модули ядра не смог, и USB-устройства этого узла не обнаруживаются. Установите модули ядра самостоятельно из пакета вашей операционной системы или соберите их для используемого ядра. DP обнаружит их сам и в течение нескольких минут назначит узлу лейбл.

Путь USB-устройства от узла до машины

Путь USB-устройства от узла до виртуальной машины состоит из четырёх шагов:

1. DRA-драйвер обнаруживает USB-устройства на узлах и публикует сведения о них в API Kubernetes как ResourceSlice. DP создаёт ресурсы NodeUSBDevice по этим данным.

2. Администратор назначает неймспейс ресурсу NodeUSBDevice, задав параметр .spec.assignedNamespace. Это делает устройство доступным в этом неймспейсе.

3. После назначения неймспейса DP создаёт в нём ресурс USBDevice.

4. Владелец проекта подключает устройство USBDevice к виртуальной машине, добавив его в параметр .spec.usbDevices ресурса VirtualMachine.

Обнаруженные устройства (NodeUSBDevice)

Ресурс NodeUSBDevice описывает физическое USB-устройство, обнаруженное на узле. Ресурс существует на уровне кластера, поэтому все обнаруженные устройства видны вам в одном списке:

d8 k get nodeusbdevice

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

NAME              NODE     READY   ASSIGNED   ATTACHED   NAMESPACE    AGE
usb-flash-drive   node-1   True    False      False                   10m
logitech-webcam   node-2   True    True       True       my-project   15m

Готовность устройства и его состояние отражают условия в блоке .status.conditions. Условия Ready и Attached совпадают с условиями USBDevice, а условие Assigned показывает, назначен ли устройству неймспейс:

• Available — неймспейс не назначен;
• InProgress — неймспейс назначен, и ресурс USBDevice создаётся;
• Assigned — ресурс USBDevice создан, устройство доступно в неймспейсе.

Назначение неймспейса USB-устройству

Пока устройству не назначен неймспейс, владелец проекта его не видит. Чтобы сделать устройство доступным в проекте, выполните следующие шаги.

1. Подключите USB-устройство к узлу, готовому к пробросу, и дождитесь появления ресурса NodeUSBDevice.

2. Назначьте неймспейс параметром .spec.assignedNamespace:

   d8 k apply -f - <<EOF
   apiVersion: virtualization.deckhouse.io/v1alpha2
   kind: NodeUSBDevice
   metadata:
     name: logitech-webcam
   spec:
     assignedNamespace: my-project
   EOF

3. Убедитесь, что в неймспейсе появился ресурс USBDevice:

   d8 k get usbdevice -n my-project

После этого владелец проекта подключает устройство к виртуальной машине.

Просмотр информации об USB-устройстве

Полные сведения об устройстве и его текущее состояние доступны в статусе ресурса.

d8 k get nodeusbdevice <DEVICE_NAME> -o yaml

d8 k get nodeusbdevice <DEVICE_NAME> \
  -o jsonpath='{.status.attributes.manufacturer}{" "}{.status.attributes.product}{" ("}{.status.attributes.vendorID}{":"}{.status.attributes.productID}{")\n"}'

Logitech Webcam C920 (046d:082d)

Устройства, назначенные проекту, его владелец видит в разделе «Виртуализация» → «USB-устройства» своего проекта.

Требования и ограничения

Планируя проброс USB-устройств, учитывайте следующие требования и ограничения:

• узел, на котором нужно обнаруживать USB-устройства, должен нести лейбл virtualization.deckhouse.io/usbip=true и работать на containerd версии 2, иначе компонент virtualization-dra там не запустится;
• устройство передаётся виртуальной машине по сети средствами USBIP, поэтому ВМ может работать на другом узле, а не на том, куда устройство подключено физически;
• пробросить можно только устройство, которое сообщает о себе скорость USB 2.0 (480 Мбит/с) или USB 3.x (от 5 Гбит/с). Устройство с меньшей скоростью, например мышь или клавиатуру на 1,5 или 12 Мбит/с, DP подключить к ВМ не даст;
• узел подключает не более 16 устройств, по 8 на концентратор USB 2.0 и USB 3.0;
• концентратор выбирается по скорости устройства, и вручную его не изменить. Устройство со скоростью USB 2.0 к концентратору USB 3.0 не подключится, как и наоборот;
• устройство можно подключать к работающей ВМ и отключать от неё, не останавливая ВМ.

GPU-устройства

DP подключает физические GPU-устройства к виртуальным машинам через DRA (Dynamic Resource Allocation). Владелец проекта запрашивает устройство по ссылке на GPUClass в блоке .spec.gpus своей машины, а кластер к этому готовите вы.

Чтобы проброс заработал, обеспечьте следующее:

• Kubernetes версии не ниже 1.34 с feature gates DRA, которые нужны конфигурации вашего кластера.
• Feature gate GPU в настройках модуля virtualization.
• Включённый модуль gpu в режиме DRA, который задаёт параметр dra.enabled.
• Ресурс GPUClass, отбирающий устройства нужной модели. Модуль gpu создаёт по нему ресурс DeviceClass с таким же именем, через который устройство и выделяется машине.

Чтобы включить feature gate, добавьте его в настройки модуля:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: virtualization
spec:
  settings:
    featureGates:
      - GPU

После этого сообщите владельцам проектов имена доступных ресурсов GPUClass. К одной машине подключается не более 16 устройств, а изменение блока .spec.gpus применяется только после её перезапуска.

PCI-устройства

Проброс PCI-устройств позволяет подключить к виртуальной машине (ВМ) физическое устройство узла, например промышленный контроллер, аппаратный модуль безопасности, плату видеозахвата, ПЛИС или сетевую карту целиком. В гостевой операционной системе такое устройство работает под её собственным драйвером, поэтому в ВМ можно использовать оборудование, которое DP не поддерживает напрямую.

Устройство попадает в машину в два шага. Сначала вы назначаете его неймспейсу проекта, а затем владелец проекта указывает устройство в спецификации своей машины. Устройство предоставляется в монопольное использование, поэтому доступно только в одном неймспейсе и только одной машине.

Драйверы устройства DP переключает сам, вручную настраивать их на узле не требуется. При запуске машины DP отвязывает устройство от штатного драйвера ядра и привязывает его к драйверу vfio-pci, а после остановки машины возвращает штатному драйверу. Пока машина работает, узел это устройство не использует.

Требования к узлам

За проброс PCI-устройств отвечает системный компонент virtualization-dra-pci. Он запускается только на узлах с containerd версии 2 и включённой аппаратной виртуализацией ввода-вывода. Узлы DP проверяет сам и назначает подходящим лейбл virtualization.deckhouse.io/vfio=true.

Чтобы включить аппаратную виртуализацию ввода-вывода, задайте в BIOS узла VT-d у Intel или AMD-Vi у AMD и добавьте в параметры ядра intel_iommu=on или amd_iommu=on.

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

d8 k get nodes -l virtualization.deckhouse.io/vfio=true,virtualization.deckhouse.io/containerd-version=v2

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

NAME     STATUS   ROLES    AGE   VERSION
node-1   Ready    worker   10d   v1.34.1

Узел, отсутствующий в выводе, лейбл не получил. Проверьте на нём каталог /sys/kernel/iommu_groups. Пустой каталог означает, что аппаратная виртуализация ввода-вывода выключена. Включите её и перезагрузите узел, и в течение нескольких минут лейбл будет назначен автоматически.

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

d8 k -n d8-virtualization get pods -l app=virtualization-dra-pci -o wide

Назначение неймспейса PCI-устройству

DP обнаруживает устройства на подходящих узлах и создаёт для каждого из них ресурс NodePCIDevice. Шину PCI компонент сканирует при запуске и далее каждые пять минут, поэтому только что установленное устройство появляется в списке через несколько минут.

Чтобы предоставить устройство проекту, выполните следующие шаги.

1. Найдите устройство среди обнаруженных:

   d8 k get nodepcidevice

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

   NAME                                            NODE     ADDRESS        READY   ASSIGNED   ATTACHED   NAMESPACE    AGE
   pci-4f2c0b1e8d9a3c5b7e1f0a2d4c6b8e0f1a3c5d7e    node-1   0000:3b:00.0   True    False      False                   10m
   pci-9a1b3c5d7e9f0a2b4c6d8e0f1a3b5c7d9e1f0a2b    node-2   0000:65:00.0   True    True       False      my-project   15m
   

   Имя ресурса формируется как хеш от параметров устройства и имени узла, поэтому ищите нужное устройство по колонкам NODE и ADDRESS. Проверить выбор помогает блок .status.attributes, где указаны адрес на шине PCI и идентификаторы производителя и модели. По ним то же устройство находится в выводе команды lspci -nn на узле.

2. Назначьте неймспейс параметром .spec.assignedNamespace:

   d8 k apply -f - <<EOF
   apiVersion: virtualization.deckhouse.io/v1alpha2
   kind: NodePCIDevice
   metadata:
     name: pci-4f2c0b1e8d9a3c5b7e1f0a2d4c6b8e0f1a3c5d7e
   spec:
     assignedNamespace: my-project
   EOF

3. Убедитесь, что в неймспейсе появился ресурс PCIDevice:

   d8 k get pcidevice -n my-project

После этого владелец проекта подключает устройство к своей машине, указав имя ресурса PCIDevice в параметре .spec.pciDevices ресурса VirtualMachine.

Чтобы сделать устройство недоступным проекту, очистите параметр .spec.assignedNamespace или укажите другой неймспейс. Ресурс PCIDevice в прежнем неймспейсе удаляется.

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

Требования и ограничения PCI-устройств

Планируя проброс PCI-устройств, учитывайте следующие требования и ограничения:

• проброс работает в кластере с Kubernetes версии не ниже 1.34 и containerd версии 2 на узлах, а в kube-apiserver должны быть включены feature gates DRAResourceClaimDeviceStatus, DRADeviceBindingConditions и DRAConsumableCapacity;
• DP обнаруживает не все устройства узла, потому что оборудование, от которого зависит работа самого узла, остаётся в его распоряжении. В списке не появятся:
  • видеоадаптеры, которые пробрасываются как GPU-устройства;
  • устройства, интегрированные в чипсет, мосты, контроллеры памяти и системная периферия;
  • сетевые контроллеры с активными интерфейсами;
  • контроллеры накопителей, диски которых использует узел;
  • устройства, попавшие с ними в одну IOMMU-группу, потому что в ВМ группа передаётся целиком;
• ВМ запускается только на том узле, где находится подключённое к ней устройство, поэтому все её PCI-устройства должны быть на одном узле, иначе спецификация будет отклонена;
• ВМ с PCI-устройством живой миграцией не переносится, а условие Migratable получает причину VirtualMachineHostDevicesNotMigratable, поэтому перед выводом узла на обслуживание такие машины нужно остановить;
• устройства подключаются при запуске ВМ, поэтому изменение параметра .spec.pciDevices требует её перезапуска;
• устройство подключается только к одной ВМ, а к каждой ВМ подключается не более восьми устройств;
• проброшенная сетевая карта работает в обход сетевой подсистемы кластера. Она не отражается в параметре .spec.networks, а адреса IP и MAC на ней DP не выдаёт и не учитывает.

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

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

Включение аудита

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

1. Включите модули log-shipper и runtime-audit-engine.

2. Включите аудит API Kubernetes, задав .spec.settings.apiserver.auditPolicyEnabled в значение true в модуле control-plane-manager.

3. Задайте .spec.settings.audit.enabled в значение true в модуле virtualization:

   spec:
     settings:
       audit:
         enabled: true

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

Состав событий

Тип события записан в поле type. Аудит различает следующие типы:

• Access to VM — подключение к ВМ по консоли, VNC или через проброс портов, фиксируются начало и завершение сеанса.
• Manage VM — создание, изменение или удаление ресурса VirtualMachine.
• Control VM — изменение состояния ВМ, в том числе запуск, остановка, перезапуск, миграция и вытеснение через ресурс VirtualMachineOperation, а также остановка или перезапуск из гостевой ОС и аварийное завершение работы.
• Module control — создание, изменение, выключение или удаление ModuleConfig.
• Virtualization control — создание или удаление системного компонента модуля в неймспейсе d8-virtualization.
• Integrity check — несовпадение контрольной суммы конфигурации ВМ с эталонной.
• Forbidden operation — попытка выполнить запрещённую операцию.

Независимо от типа каждое событие содержит одни и те же поля:

• name — описание произошедшего;
• datetime — время события;
• request_subject — имя пользователя или ServiceAccount, от имени которого выполнено действие;
• operation_result — результат операции;
• uid — идентификатор записи в аудите Kubernetes.

К ним добавляются уточняющие поля, состав которых зависит от типа события. Например, события с ВМ содержат поля virtual_machine_name и virtual_machine_namespace, а запрещённые операции описывают источник запроса в поле source_ip и причину отказа в поле forbid_reason.

Просмотр событий

События собирает системный компонент virtualization-audit в неймспейсе d8-virtualization. Чтобы перенаправить их в систему логирования кластера, например в Loki, создайте ClusterLoggingConfig:

apiVersion: deckhouse.io/v1alpha1
kind: ClusterLoggingConfig
metadata:
  name: virtualization-audit-logs
spec:
  destinationRefs:
    - d8-loki
  kubernetesPods:
    namespaceSelector:
      matchNames:
        - d8-virtualization
    labelSelector:
      matchLabels:
        app: virtualization-audit
  type: KubernetesPods

Чтобы посмотреть события в Grafana, используйте запрос к Loki:

{namespace="d8-virtualization", pod=~"virtualization-audit-.*"}