Ресурс 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 для виртуальных машин.
Блок cores
обязательный и задает диапазоны ядер, на которые распространяется правило, описанное в этом же блоке.
Диапазоны [min; max] для параметра cores
должны быть строго последовательными и непересекающимися.
Правильная структура (диапазоны идут друг за другом без пересечений):
- cores:
min: 1
max: 4
...
- cores:
min: 5 # Начало следующего диапазона = (предыдущий max + 1)
max: 8
Недопустимый вариант (пересечение значений):
- cores:
min: 1
max: 4
...
- cores:
min: 4 # Ошибка: Значение 4 уже входит в предыдущий диапазон
max: 8
Правило: Каждый новый диапазон должен начинаться со значения, непосредственно следующего за max предыдущего диапазона.
Для каждого диапазона ядер cores
можно задать дополнительные требования:
-
Память (
memory
) — указывается:- Либо минимум и максимум памяти для всех ядер в диапазоне,
- Либо минимум и максимум памяти на одно ядро (
memoryPerCore
).
-
Допустимые доли ядер (
coreFractions
) — список разрешенных значений (например, [25, 50, 100] для 25%, 50% или 100% использования ядра).
Для каждого диапазона ядер обязательно укажите:
- либо
memory
(илиmemoryPerCore
), - либо
coreFractions
, - либо оба параметра одновременно.
Пример политики с подобными настройками:
spec:
sizingPolicies:
# Для диапазона от 1 до 4 ядер возможно использовать от 1 до 8 ГБ оперативной памяти с шагом 512Mi,
# т.е 1 ГБ, 1,5 ГБ, 2 ГБ, 2,5 ГБ и т. д.
# Запрещено использовать выделенные ядра.
# Доступны все варианты параметра `corefraction`.
- cores:
min: 1
max: 4
memory:
min: 1Gi
max: 8Gi
step: 512Mi
coreFractions: [5, 10, 20, 50, 100]
# Для диапазона от 5 до 8 ядер возможно использовать от 5 до 16 ГБ оперативной памяти с шагом 1 ГБ,
# т.е. 5 ГБ, 6 ГБ, 7 ГБ и т. д.
# Запрещено использовать выделенные ядра.
# Доступны некоторые варианты параметра `corefraction`.
- cores:
min: 5
max: 8
memory:
min: 5Gi
max: 16Gi
step: 1Gi
coreFractions: [20, 50, 100]
# Для диапазона от 9 до 16 ядер возможно использовать от 9 до 32 ГБ оперативной памяти с шагом 1 ГБ.
# При необходимости можно использовать выделенные ядра.
# Доступны некоторые варианты параметра `corefraction`.
- cores:
min: 9
max: 16
memory:
min: 9Gi
max: 32Gi
step: 1Gi
coreFractions: [50, 100]
# Для диапазона от 17 до 248 ядер возможно использовать от 1 до 2 ГБ оперативной памяти из расчёта на одно ядро.
# Доступны для использования только выделенные ядра.
# Единственный доступный параметр `corefraction` = 100%.
- cores:
min: 17
max: 248
memory:
perCore:
min: 1Gi
max: 2Gi
coreFractions: [100]
Пример конфигурации vCPU Discovery
Представим, что у нас есть кластер из четырех узлов. Два из этих узлов с лейблом group=blue
оснащены процессором «CPU X» с тремя наборами инструкций, а остальные два узла с лейблом group=green
имеют более новый процессор «CPU Y» с четырьмя наборами инструкций.
Для оптимального использования ресурсов данного кластера рекомендуется создать три дополнительных класса виртуальных машин (VirtualMachineClass):
universal
— этот класс позволит виртуальным машинам запускаться на всех узлах платформы и мигрировать между ними. При этом будет использоваться набор инструкций для самой младшей модели CPU, что обеспечит наибольшую совместимость;cpuX
— этот класс будет предназначен для виртуальных машин, которые должны запускаться только на узлах с процессором «CPU X». ВМ смогут мигрировать между этими узлами, используя доступные наборы инструкций «CPU X»;cpuY
— этот класс предназначен для виртуальных машин, которые должны запускаться только на узлах с процессором «CPU Y». ВМ смогут мигрировать между этими узлами, используя доступные наборы инструкций «CPU Y».
Набор инструкций для процессора — это набор всех команд, которые процессор может выполнять, таких как сложение, вычитание или работа с памятью. Они определяют, какие операции возможны, влияют на совместимость программ и производительность, а также могут меняться от одного поколения процессоров к другому.
Примерные конфигурации ресурсов для данного кластера:
---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
name: universal
spec:
cpu:
discovery: {}
type: Discovery
sizingPolicies: { ... }
---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
name: cpuX
spec:
cpu:
discovery: {}
type: Discovery
nodeSelector:
matchExpressions:
- key: group
operator: In
values: ["blue"]
sizingPolicies: { ... }
---
apiVersion: virtualization.deckhouse.io/v1alpha2
kind: VirtualMachineClass
metadata:
name: cpuY
spec:
cpu:
discovery:
nodeSelector:
matchExpressions:
- key: group
operator: In
values: ["green"]
type: Discovery
sizingPolicies: { ... }