From c6e3078d90af900783ef94345ccbfd6534d3d9c1 Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Mon, 13 Oct 2025 08:35:28 +0300 Subject: [PATCH 1/8] docs: fix live migration --- docs/ADMIN_GUIDE.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/ADMIN_GUIDE.md b/docs/ADMIN_GUIDE.md index 9f7b55a4d3..4acb134956 100644 --- a/docs/ADMIN_GUIDE.md +++ b/docs/ADMIN_GUIDE.md @@ -863,7 +863,11 @@ Virtual machine migration is an important feature in virtualized infrastructure - Upgrading a virtual machine firmware: The migration allows you to upgrade the firmware of virtual machines without interrupting their operation. {{< alert level="warning" >}} +<<<<<<< HEAD Live migration has the following limitations: +======= +When performing live migration, the following limitations apply: +>>>>>>> 01257d90 (docs: fix live migration) - Only one virtual machine can migrate from each node simultaneously. - The total number of concurrent migrations in the cluster cannot exceed the number of nodes where running virtual machines is permitted. From 739bad6959f80fed91feab13df1929080a07f56f Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Mon, 13 Oct 2025 08:40:38 +0300 Subject: [PATCH 2/8] docs: fix rebalancing --- docs/ADMIN_GUIDE.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/ADMIN_GUIDE.md b/docs/ADMIN_GUIDE.md index 4acb134956..a3201f7f1a 100644 --- a/docs/ADMIN_GUIDE.md +++ b/docs/ADMIN_GUIDE.md @@ -977,8 +977,13 @@ Live migration of virtual machines between cluster nodes is used for rebalancing After the module is enabled, the system automatically monitors the distribution of virtual machines and maintains optimal node utilization. The main features of the module are: +<<<<<<< HEAD - Load balancing: The system monitors CPU reservation on each node. If more than 80% of CPU resources are reserved on a node, some virtual machines will be automatically migrated to less-loaded nodes. This helps avoid overloads and ensures stable VM operation. - Correct placement: The system checks whether the current node meets the mandatory requirements of the virtual machine's requests, as well as rules regarding their relative placement. For example, if rules prohibit placing certain VMs on the same node, the module will automatically move them to a suitable server. +======= +- Load balancing — the system monitors CPU reservation on each node. If more than 80% of CPU resources are reserved on a node, some virtual machines will be automatically migrated to less loaded nodes. This helps avoid overloads and ensures stable VM operation. +- Correct placement — the system checks whether the current node meets the mandatory requirements of the virtual machine's requests, as well as rules regarding their relative placement. For example, if rules prohibit placing certain VMs on the same node, the module will automatically move them to a suitable server. +>>>>>>> 6840c4e3 (docs: fix rebalancing) ### ColdStandby From bf10629991ea0bf8b9aea32062a634dc635f163e Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Mon, 13 Oct 2025 08:47:54 +0300 Subject: [PATCH 3/8] docs: fix guest agent --- docs/ADMIN_GUIDE.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/docs/ADMIN_GUIDE.md b/docs/ADMIN_GUIDE.md index a3201f7f1a..4fd32a3e56 100644 --- a/docs/ADMIN_GUIDE.md +++ b/docs/ADMIN_GUIDE.md @@ -863,11 +863,7 @@ Virtual machine migration is an important feature in virtualized infrastructure - Upgrading a virtual machine firmware: The migration allows you to upgrade the firmware of virtual machines without interrupting their operation. {{< alert level="warning" >}} -<<<<<<< HEAD -Live migration has the following limitations: -======= When performing live migration, the following limitations apply: ->>>>>>> 01257d90 (docs: fix live migration) - Only one virtual machine can migrate from each node simultaneously. - The total number of concurrent migrations in the cluster cannot exceed the number of nodes where running virtual machines is permitted. @@ -977,13 +973,8 @@ Live migration of virtual machines between cluster nodes is used for rebalancing After the module is enabled, the system automatically monitors the distribution of virtual machines and maintains optimal node utilization. The main features of the module are: -<<<<<<< HEAD - Load balancing: The system monitors CPU reservation on each node. If more than 80% of CPU resources are reserved on a node, some virtual machines will be automatically migrated to less-loaded nodes. This helps avoid overloads and ensures stable VM operation. - Correct placement: The system checks whether the current node meets the mandatory requirements of the virtual machine's requests, as well as rules regarding their relative placement. For example, if rules prohibit placing certain VMs on the same node, the module will automatically move them to a suitable server. -======= -- Load balancing — the system monitors CPU reservation on each node. If more than 80% of CPU resources are reserved on a node, some virtual machines will be automatically migrated to less loaded nodes. This helps avoid overloads and ensures stable VM operation. -- Correct placement — the system checks whether the current node meets the mandatory requirements of the virtual machine's requests, as well as rules regarding their relative placement. For example, if rules prohibit placing certain VMs on the same node, the module will automatically move them to a suitable server. ->>>>>>> 6840c4e3 (docs: fix rebalancing) ### ColdStandby From d44b7e4ee2203e90fb6df55177a1374af13b33c2 Mon Sep 17 00:00:00 2001 From: Dmitry Prytkov Date: Wed, 22 Oct 2025 10:04:23 +0300 Subject: [PATCH 4/8] Add info about ability to use tolerations Signed-off-by: Dmitry Prytkov --- docs/USER_GUIDE.md | 11 ++++++++++- docs/USER_GUIDE.ru.md | 11 ++++++++++- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/docs/USER_GUIDE.md b/docs/USER_GUIDE.md index 393cd0e473..aa27cbe6e3 100644 --- a/docs/USER_GUIDE.md +++ b/docs/USER_GUIDE.md @@ -1707,7 +1707,16 @@ All of the above parameters (including the `.spec.nodeSelector` parameter from V - Use combinations of labels instead of single restrictions. For example, instead of required for a single label (e.g. env=prod), use several preferred conditions. - Consider the order in which interdependent VMs are launched. When using Affinity between VMs (for example, the backend depends on the database), launch the VMs referenced by the rules first to avoid lockouts. - Plan backup nodes for critical workloads. For VMs with strict requirements (e.g., AntiAffinity), provide backup nodes to avoid downtime in case of failure or maintenance. -- Consider existing `taints` on nodes. +- Consider existing `taints` on nodes. If necessary, you can add appropriate `tolerations` to a VM. An example of using `tolerations` to restrict `key1=value1:NoSchedule` is provided below. + +```yaml +spec: + tolerations: + - effect: NoSchedule + key: key1 + operator: Equal + value: value1 +``` {{< alert level="info" >}} When changing placement parameters: diff --git a/docs/USER_GUIDE.ru.md b/docs/USER_GUIDE.ru.md index 66bc4a1e4f..c4806c0f39 100644 --- a/docs/USER_GUIDE.ru.md +++ b/docs/USER_GUIDE.ru.md @@ -1723,7 +1723,16 @@ spec: - Используйте комбинации меток вместо одиночных ограничений. Например, вместо required для одного лейбла (например, env=prod) используйте несколько preferred условий. - Учитывайте порядок запуска взаимозависимых ВМ. При использовании Affinity между ВМ (например, бэкенд зависит от базы данных) запускайте сначала ВМ, на которые ссылаются правила, чтобы избежать блокировок. - Планируйте резервные узлы для критических нагрузок. Для ВМ с жесткими требованиями (например, AntiAffinity) предусмотрите дополнительные узлы, чтобы избежать простоев при сбое или выводе узла в режим обслуживания. -- Учитывайте существующие ограничения (`taints`) на узлах. +- Учитывайте существующие ограничения (`taints`) на узлах. При необходимости можно добавить соответствующие `tolerations` на ВМ. Пример использования `tolerations` для ограничения `key1=value1:NoSchedule` + +```yaml +spec: + tolerations: + - effect: NoSchedule + key: key1 + operator: Equal + value: value1 +``` {{< alert level="info" >}} При изменении параметров размещения: From 36f0659dcdf8a36a752eb6e3c5fd4efe27435c13 Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Wed, 22 Oct 2025 11:28:27 +0300 Subject: [PATCH 5/8] update Signed-off-by: Pavel Tishkov --- docs/ADMIN_GUIDE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/ADMIN_GUIDE.md b/docs/ADMIN_GUIDE.md index 4fd32a3e56..afbb91ba83 100644 --- a/docs/ADMIN_GUIDE.md +++ b/docs/ADMIN_GUIDE.md @@ -863,7 +863,7 @@ Virtual machine migration is an important feature in virtualized infrastructure - Upgrading a virtual machine firmware: The migration allows you to upgrade the firmware of virtual machines without interrupting their operation. {{< alert level="warning" >}} -When performing live migration, the following limitations apply: +Live migration has the following limitations: - Only one virtual machine can migrate from each node simultaneously. - The total number of concurrent migrations in the cluster cannot exceed the number of nodes where running virtual machines is permitted. @@ -974,7 +974,7 @@ Live migration of virtual machines between cluster nodes is used for rebalancing After the module is enabled, the system automatically monitors the distribution of virtual machines and maintains optimal node utilization. The main features of the module are: - Load balancing: The system monitors CPU reservation on each node. If more than 80% of CPU resources are reserved on a node, some virtual machines will be automatically migrated to less-loaded nodes. This helps avoid overloads and ensures stable VM operation. -- Correct placement: The system checks whether the current node meets the mandatory requirements of the virtual machine's requests, as well as rules regarding their relative placement. For example, if rules prohibit placing certain VMs on the same node, the module will automatically move them to a suitable server. +- Correct placement: The system checks whether the current node meets the mandatory requirements of the virtual machine's requests, as well as rules regarding their relative placement. For example, if rules prohibit placing certain VMs on the same node, the module will automatically move them to a suitable server.ple, if rules prohibit placing certain VMs on the same node, the module will automatically move them to a suitable server. ### ColdStandby From bd70e1eaf93a6ac32497ca1126d2221804bec8ab Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Wed, 22 Oct 2025 11:40:15 +0300 Subject: [PATCH 6/8] update toleration example Signed-off-by: Pavel Tishkov --- docs/USER_GUIDE.md | 9 ++++----- docs/USER_GUIDE.ru.md | 9 ++++----- 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/docs/USER_GUIDE.md b/docs/USER_GUIDE.md index aa27cbe6e3..618af3e818 100644 --- a/docs/USER_GUIDE.md +++ b/docs/USER_GUIDE.md @@ -1707,15 +1707,14 @@ All of the above parameters (including the `.spec.nodeSelector` parameter from V - Use combinations of labels instead of single restrictions. For example, instead of required for a single label (e.g. env=prod), use several preferred conditions. - Consider the order in which interdependent VMs are launched. When using Affinity between VMs (for example, the backend depends on the database), launch the VMs referenced by the rules first to avoid lockouts. - Plan backup nodes for critical workloads. For VMs with strict requirements (e.g., AntiAffinity), provide backup nodes to avoid downtime in case of failure or maintenance. -- Consider existing `taints` on nodes. If necessary, you can add appropriate `tolerations` to a VM. An example of using `tolerations` to restrict `key1=value1:NoSchedule` is provided below. +- Consider existing `taints` on nodes. If necessary, you can add appropriate `tolerations` to a VM. An example of using `tolerations` to allow scheduling on nodes with the `node.deckhouse.io/group=:NoSchedule` taint is provided below. ```yaml spec: tolerations: - - effect: NoSchedule - key: key1 - operator: Equal - value: value1 + - key: "node.deckhouse.io/group" + operator: "Exists" + effect: "NoSchedule" ``` {{< alert level="info" >}} diff --git a/docs/USER_GUIDE.ru.md b/docs/USER_GUIDE.ru.md index c4806c0f39..fdd052488a 100644 --- a/docs/USER_GUIDE.ru.md +++ b/docs/USER_GUIDE.ru.md @@ -1723,15 +1723,14 @@ spec: - Используйте комбинации меток вместо одиночных ограничений. Например, вместо required для одного лейбла (например, env=prod) используйте несколько preferred условий. - Учитывайте порядок запуска взаимозависимых ВМ. При использовании Affinity между ВМ (например, бэкенд зависит от базы данных) запускайте сначала ВМ, на которые ссылаются правила, чтобы избежать блокировок. - Планируйте резервные узлы для критических нагрузок. Для ВМ с жесткими требованиями (например, AntiAffinity) предусмотрите дополнительные узлы, чтобы избежать простоев при сбое или выводе узла в режим обслуживания. -- Учитывайте существующие ограничения (`taints`) на узлах. При необходимости можно добавить соответствующие `tolerations` на ВМ. Пример использования `tolerations` для ограничения `key1=value1:NoSchedule` +- Учитывайте существующие ограничения (`taints`) на узлах. При необходимости можно добавить соответствующие `tolerations` на ВМ. Пример использования `tolerations` для разрешения запуска на узлах c установленным taint `node.deckhouse.io/group=:NoSchedule` ```yaml spec: tolerations: - - effect: NoSchedule - key: key1 - operator: Equal - value: value1 + - key: "node.deckhouse.io/group" + operator: "Exists" + effect: "NoSchedule" ``` {{< alert level="info" >}} From d6478892fd2a2105ff37eafb8c9adba360b6a701 Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Wed, 22 Oct 2025 11:47:19 +0300 Subject: [PATCH 7/8] update generic vmclass info Signed-off-by: Pavel Tishkov --- docs/ADMIN_GUIDE.md | 6 ++++++ docs/ADMIN_GUIDE.ru.md | 8 ++++++-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/docs/ADMIN_GUIDE.md b/docs/ADMIN_GUIDE.md index afbb91ba83..715e0dc005 100644 --- a/docs/ADMIN_GUIDE.md +++ b/docs/ADMIN_GUIDE.md @@ -422,7 +422,13 @@ How to perform the operation in the web interface: The VirtualMachineClass resource is designed for centralized configuration of preferred virtual machine settings. It allows you to define CPU instructions, configuration policies for CPU and memory resources for virtual machines, as well as define ratios of these resources. In addition, VirtualMachineClass provides management of virtual machine placement across platform nodes. This allows administrators to effectively manage virtualization platform resources and optimally place virtual machines on platform nodes. During installation, a single VirtualMachineClass `generic` resource is automatically created. It represents a universal CPU type based on the older, but widely supported, Nehalem architecture. This enables running VMs on any nodes in the cluster and allows live migration. + +The administrator can modify the parameters of the `generic` VirtualMachineClass resource (except for the `.spec.cpu` section) or delete this resource. + {{< alert level="info" >}} + +It is not recommended to use the VirtualMachineClass `generic` for running workloads in production environments, since this class corresponds to a processor with the least functionality. + It is recommended that you create at least one VirtualMachineClass resource in the cluster with the `Discovery` type immediately after all nodes are configured and added to the cluster. This allows virtual machines to utilize a generic CPU with the highest possible CPU performance considering the CPUs on the cluster nodes. This allows the virtual machines to utilize the maximum CPU capabilities and migrate seamlessly between cluster nodes if necessary. For a configuration example, see [vCPU Discovery configuration example](#vcpu-discovery-configuration-example) diff --git a/docs/ADMIN_GUIDE.ru.md b/docs/ADMIN_GUIDE.ru.md index c75dd09ffa..8d8c98c1c3 100644 --- a/docs/ADMIN_GUIDE.ru.md +++ b/docs/ADMIN_GUIDE.ru.md @@ -429,9 +429,13 @@ d8 k describe cvi ubuntu-22-04 Во время установки автоматически создаётся ресурс VirtualMachineClass с именем `generic`. Он представляет собой универсальный тип процессора на основе более старой, но широко поддерживаемой архитектуры Nehalem. Это позволяет запускать виртуальные машины на любых узлах кластера и поддерживает их живую миграцию. +Администратор может изменять параметры ресурса VirtualMachineClass `generic` (за исключением секции `.spec.cpu`) либо удалить данный ресурс. + {{< alert level="info" >}} -Рекомендуется создать как минимум один ресурс VirtualMachineClass в кластере с типом `Discovery` сразу после того, как все узлы будут настроены и добавлены в кластер. -Это позволит использовать в виртуальных машинах универсальный процессор с максимально возможными характеристиками с учетом CPU на узлах кластера, что позволит виртуальным машинам использовать максимум возможностей CPU и при необходимости беспрепятственно осуществлять миграцию между узлами кластера. + +Не рекомендуется использовать VirtualMachineClass `generic` для запуска рабочих нагрузок в production-средах, поскольку данный класс соответствует процессору с наименьшей функциональностью. + +Рекомендуется после добавления и настройки всех узлов в кластере создать хотя бы один ресурс VirtualMachineClass с типом `Discovery`. Это обеспечит выбор наилучшей доступной конфигурации процессора с учётом всех CPU в вашем кластере, позволит виртуальным машинам максимально эффективно использовать возможности процессоров и обеспечит беспрепятственную миграцию между узлами. Пример настройки смотрите в разделе [Пример конфигурации vCPU Discovery](#пример-конфигурации-vcpu-discovery) {{< /alert >}} From 158d428eee88dde25daf828959b48e7d351de14f Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Thu, 23 Oct 2025 10:58:05 +0300 Subject: [PATCH 8/8] simplify install doc Signed-off-by: Pavel Tishkov --- docs/INSTALL.md | 112 +++++++++--------------------------- docs/INSTALL.ru.md | 140 +++++++++++++-------------------------------- 2 files changed, 67 insertions(+), 185 deletions(-) diff --git a/docs/INSTALL.md b/docs/INSTALL.md index d8629328d3..57f6467490 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -16,89 +16,20 @@ The module supports the following configuration: - Maximum number of nodes: `1000`. - Maximum number of virtual machines: `50000`. -The module has no additional restrictions and is compatible with any hardware that is supported by [operating systems](#supported-os-for-platform-nodes) on which it can be installed. - -## Hardware requirements - -1. A dedicated **machine for installation**. - - This machine will run the Deckhouse installer. For example, it can be an administrator's laptop or any other computer that is not intended to be added to the cluster. Requirements for this machine: - - - OS: Windows 10+, macOS 10.15+, Linux (Ubuntu 18.04+, Fedora 35+). - - Installed Docker Engine or Docker Desktop (instructions for [Ubuntu](https://docs.docker.com/engine/install/ubuntu/), [macOS](https://docs.docker.com/desktop/mac/install/), [Windows](https://docs.docker.com/desktop/windows/install/)). - - HTTPS access to the container image registry at `registry.deckhouse.io`. - - SSH-key-based access to the node that will serve as the **master node** of the future cluster. - - SSH-key-based access to the node that will serve as the **worker node** of the future cluster (if the cluster will consist of more than one master node). - -1. **Server for the master node** - - There can be multiple servers running the cluster’s control plane components, but only one server is required for installation. The others can be added later via node management mechanisms. - - Requirements for a physical bare-metal server: - - - Resources: - - CPU: - - x86-64 architecture. - - Support for Intel-VT (VMX) or AMD-V (SVM) instructions. - - At least 4 cores. - - RAM: At least 8 GB. - - Disk space: - - At least 60 GB. - - High-speed disk (400+ IOPS). - - OS [from the list of supported ones](#supported-os-for-platform-nodes): - - Linux kernel version `5.7` or newer. - - **Unique hostname** across all servers in the future cluster. - - Network access: - - HTTPS access to the container image registry at `registry.deckhouse.io`. - - Access to the package repositories of the chosen OS. - - SSH key-based access from the **installation machine** (see item 1). - - Network access from the **installation machine** (see item 1) on port `22322/TCP`. - - Required software: - - The `cloud-utils` and `cloud-init` packages must be installed (package names may vary depending on the chosen OS). - - > The container runtime will be installed automatically, so there's no need to install any `containerd` or `docker` packages. - -1. **Servers for worker nodes** - - These nodes will run virtual machines, so the servers must have enough resources to handle the planned number of VMs. Additional disks may be required if you deploy a software-defined storage solution. - - Requirements for a physical bare-metal server: - - - Resources: - - CPU: - - x86-64 architecture. - - Support for Intel-VT (VMX) or AMD-V (SVM) instructions. - - At least 4 cores. - - RAM: At least 8 GB. - - Disk space: - - At least 60 GB. - - High-speed disk (400+ IOPS). - - Additional disks for software-defined storage. - - OS [from the list of supported ones](#supported-os-for-platform-nodes): - - Linux kernel version `5.7` or newer; - - **Unique hostname** across all servers in the future cluster. - - Network access: - - HTTPS access to the container image registry at `registry.deckhouse.io`. - - Access to the package repositories of the chosen OS. - - SSH key-based access from the **installation machine** (see item 1). - - Required software: - - The `cloud-utils` and `cloud-init` packages must be installed (package names may vary depending on the chosen OS). - - > The container runtime will be installed automatically, so there's no need to install any `containerd` or `docker` packages. - -1. **Storage hardware** - - Depending on the chosen storage solution, additional resources may be required. For details, refer to [Storage Management](/products/virtualization-platform/documentation/admin/platform-management/storage/sds/lvm-local.html). - -## Supported OS for platform nodes - -| Linux distribution | Supported versions | -| ------------------ | ------------------- | -| CentOS | 7, 8, 9 | -| Debian | 10, 11, 12 | -| Ubuntu | 20.04, 22.04, 24.04 | - -{{< alert level="warning">}} +The module has no additional restrictions and is compatible with any hardware that is supported by operating systems on which it can be installed. + +## Hardware and software requirements + +Hardware requirements for the virtualization module match the requirements for [Deckhouse Kubernetes Platform](https://deckhouse.io/products/kubernetes-platform/gs/), with the additional requirement for CPU virtualization support on hosts where virtual machines will be launched. + +### Additional requirements for virtualization support + +On all cluster nodes where virtual machines are planned to be launched, hardware virtualization support must be ensured: + +- Processor: support for Intel-VT (VMX) or AMD-V (SVM) instructions; +- BIOS/UEFI: hardware virtualization support enabled in BIOS/UEFI settings. + +{{< alert level="warning" >}} Ensuring stable operation of live migration mechanisms requires the use of an identical version of the Linux kernel on all cluster nodes. This is because differences in kernel versions can lead to incompatible interfaces, system calls, and resource handling, which can disrupt the virtual machine migration process. @@ -212,9 +143,13 @@ The distribution of components across cluster nodes depends on the cluster's con - master nodes, system nodes, and worker nodes; - other combinations (depending on the architecture). -The table lists the management plane components and the node types for their placement. Components are distributed by priority only if the corresponding nodes are available in the cluster configuration. +{{< alert level="warning" >}} +Worker nodes are understood as nodes that have no restrictions (taints) that prevent running regular workloads (pods, virtual machines). +{{< /alert >}} + +The table lists the main virtualization management plane components and the nodes where they can be placed. Components are distributed by priority — if there is a suitable node type in the cluster, the component will be placed on it. -| Name | Node group for running components | Comment | +| Component Name | Node group for running components | Comment | | ----------------------------- | --------------------------------- | -------------------------------------------- | | `cdi-operator-*` | system/worker | | | `cdi-apiserver-*` | master | | @@ -229,6 +164,13 @@ The table lists the management plane components and the node types for their pla | `virt-handler-*` | All cluster nodes | | | `vm-route-forge-*` | All cluster nodes | | +Components for creating and loading (importing) virtual machine images or disks (they run only during creation or loading): + +| Component Name | Node group for running components | Comment | +| ------------------------------ | --------------------------------- | -------------------------------------------- | +| `importer-*` | system/worker | | +| `uploader-*` | system/worker | | + ## Module update The `virtualization` module uses five update channels designed for use in different environments that have different requirements in terms of reliability: diff --git a/docs/INSTALL.ru.md b/docs/INSTALL.ru.md index e7b0ad5bc2..e247410c61 100644 --- a/docs/INSTALL.ru.md +++ b/docs/INSTALL.ru.md @@ -18,89 +18,16 @@ weight: 15 Модуль не имеет дополнительных ограничений и совместим с любым оборудованием, которое поддерживается [операционными системами](#поддерживаемые-ос-для-узлов-платформы), на которые он может быть установлен. -## Требования к аппаратному обеспечению - -1. Отдельная **машина для установки**. - - Здесь будет запускаться установщик Deckhouse. Это может быть ноутбук администратора или любой другой компьютер, который **не планируется** добавлять в кластер. Требования к этой машине: - - - ОС: Windows 10+, macOS 10.15+, Linux (Ubuntu 18.04+, Fedora 35+); - - установленный Docker Engine или Docker Desktop (инструкции [для Ubuntu](https://docs.docker.com/engine/install/ubuntu/), [macOS](https://docs.docker.com/desktop/mac/install/), [Windows](https://docs.docker.com/desktop/windows/install/)); - - HTTPS-доступ к хранилищу образов контейнеров `registry.deckhouse.ru`; - - SSH-доступ по ключу к узлу, который будет **master-узлом** будущего кластера; - - SSH-доступ по ключу к узлу, который будет **worker-узлом** будущего кластера (если кластер будет состоять не из одного master-узла). - -1. **Сервер для 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` устанавливать не нужно. - -1. **Серверы для 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` устанавливать не нужно. - -1. **Оборудование для хранилища**. - - В зависимости от выбранного хранилища могут потребоваться дополнительные ресурсы. Подробности смотрите в разделе [Управление хранилищами](/products/virtualization-platform/documentation/admin/platform-management/storage/sds/lvm-local.html). - -## Поддерживаемые ОС для узлов платформы - -| Дистрибутив 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 | +## Требования к программному и аппаратному обеспечению + +Требования к аппаратному обеспечению для модуля виртуализации совпадают с требованиями, предъявляемыми к [Deckhouse Kubernetes Platform](https://deckhouse.ru/gs/), с дополнительным требованием поддержки виртуализации CPU на хостах, где будут запускаться виртуальные машины. + +### Дополнительные требования для поддержки виртуализации + +На всех узлах кластера, где планируется запуск виртуальных машин, необходимо обеспечить поддержку аппаратной виртуализации: + +- Процессор: поддержка инструкций Intel-VT (VMX) или AMD-V (SVM); +- BIOS/UEFI: включена поддержка аппаратной виртуализации в настройках BIOS/UEFI. {{< alert level="warning" >}} Обеспечение стабильной работы механизмов живой миграции требует использования идентичной версии ядра Linux на всех узлах кластера. @@ -130,7 +57,7 @@ weight: 15 ## Поддерживаемые хранилища -Виртуальные машины используют ресурсы `PersistentVolume`. Для управления этими ресурсами и выделения дискового пространства в кластере должно быть установлено одно или несколько поддерживаемых хранилищ: +Для создания дисков виртуальных машин используются ресурсы `PersistentVolume`. Для управления этими ресурсами и выделения дискового пространства в кластере должно быть установлено одно или несколько поддерживаемых хранилищ: | Хранилище | Расположение дисков | | ------------------------- | ------------------------- | @@ -216,22 +143,35 @@ weight: 15 - master-узлы, system-узлы и worker-узлы; - другие комбинации (в зависимости от архитектуры). -В таблице указаны компоненты плоскости управления и типы узлов для их размещения. Компоненты распределяются по приоритету, только если соответствующие узлы доступны в конфигурации кластера. - -| Название | Группа узлов для запуска компонент | Комментарий | -| ----------------------------- | ---------------------------------- | --------------------------------------- | -| `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-*` | Все узлы кластера | | +{{< alert level="warning" >}} +Под worker-узлами понимаются узлы, на которых нет ограничений (taints), мешающих запуску обычной рабочей нагрузки (подов, виртуальных машин). +{{< /alert >}} + +В таблице приведены основные компоненты плоскости управления виртуализации и узлы, на которых они могут быть размещены. Компоненты распределяются по приоритету — если в кластере есть подходящий тип узлов, компонент будет размещён на нём. + +| Название компонента | Группа узлов для запуска | Комментарий | +|-------------------------------|------------------------------------|-----------------------------------------------| +| `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 | | + + ## Обновление модуля