diff --git a/docs/ADMIN_GUIDE.md b/docs/ADMIN_GUIDE.md index 5618ed8359..6cd57d7fac 100644 --- a/docs/ADMIN_GUIDE.md +++ b/docs/ADMIN_GUIDE.md @@ -9,27 +9,165 @@ This guide is intended for administrators of Deckhouse Virtualization Platform ( The administrator also has rights to manage project resources, which are described in the [User guide](./user_guide.html). +## Module parameters + +The configuration of the `virtualization` module is specified via the ModuleConfig resource in YAML format. The following is an example of a basic configuration: + +```yaml +apiVersion: deckhouse.io/v1alpha1 +kind: ModuleConfig +metadata: + name: virtualization +spec: + enabled: true + version: 1 + settings: + dvcr: + storage: + persistentVolumeClaim: + size: 50G + storageClassName: sds-replicated-thin-r1 + type: PersistentVolumeClaim + virtualMachineCIDRs: + - 10.66.10.0/24 +``` + +### Parameter description + +**Enable the module** + +The module state is controlled through the `.spec.enabled` field. Specify: + +- `true`: To enable the module. +- `false`: To disable the module. + +**Configuration version** + +The `.spec.version` parameter defines the version of the configuration schema. The parameter structure may change between versions. The current values are given in the settings section. + +**Deckhouse Virtualization Container Registry (DVCR)** + +The `.spec.settings.dvcr.storage` block configures a persistent volume for storing images: + +- `.spec.settings.dvcr.storage.persistentVolumeClaim.size`: Volume size (for example, `50G`). To expand the storage, increase the value of the parameter. +- `.spec.settings.dvcr.storage.persistentVolumeClaim.storageClassName`: StorageClass name (for example, `sds-replicated-thin-r1`). + +**Network settings** + +The `.spec.settings.virtualMachineCIDRs` block specifies subnets in CIDR format (for example, `10.66.10.0/24`). IP addresses for virtual machines are allocated from these ranges automatically or on request. + +Example: + +```yaml +spec: + settings: + virtualMachineCIDRs: + - 10.66.10.0/24 + - 10.66.20.0/24 + - 10.77.20.0/16 +``` + +The first and the last subnet address are reserved and not available for use. + +{{< alert level="warning">}} +The subnets in the `.spec.settings.virtualMachineCIDRs` block must not overlap with cluster node subnets, services subnet, or pods subnet (`podCIDR`). + +It is forbidden to delete subnets if addresses from them have already been issued to virtual machines. +{{< /alert >}} + +**Storage class settings for images** + +The storage class settings for images are defined in the `.spec.settings.virtualImages` parameter of the module settings. + +Example: + +```yaml +spec: + ... + settings: + virtualImages: + allowedStorageClassNames: + - sc-1 + - sc-2 + defaultStorageClassName: sc-1 +``` + +Where: + +- `allowedStorageClassNames` (optional): A list of the allowed StorageClasses for creating a VirtualImage that can be explicitly specified in the resource specification. +- `defaultStorageClassName` (optional): The StorageClass used by default when creating a VirtualImage if the `.spec.persistentVolumeClaim.storageClassName` parameter is not set. + +**Storage class settings for disks** + +The storage class settings for disks are defined in the `.spec.settings.virtualDisks` parameter of the module settings. + +Example: + +```yaml +spec: + ... + settings: + virtualDisks: + allowedStorageClassNames: + - sc-1 + - sc-2 + defaultStorageClassName: sc-1 +``` + +Where: + +- `allowedStorageClassNames` (optional): A list of the allowed StorageClass for creating a VirtualDisk that can be explicitly specified in the resource specification. +- `defaultStorageClassName` (optional): The StorageClass used by default when creating a VirtualDisk if the `.spec.persistentVolumeClaim.storageClassName` parameter is not specified. + +{{< alert level="info" >}} +For a complete list of configuration options, see [Configuration](./configuration.html). +{{< /alert >}} + ## Images The ClusterVirtualImage resource is used to load virtual machine images into the intra-cluster storage. After that it can be used to create virtual machine disks. It is available in all cluster namespaces and projects. The image creation process includes the following steps: -- The user creates a ClusterVirtualImage resource. -- Once created, the image is automatically uploaded from the source specified in the specification to the storage (DVCR). -- Once the upload is complete, the resource becomes available for disk creation. +1. The user creates a ClusterVirtualImage resource. +1. Once created, the image is automatically uploaded from the source specified in the specification to the storage (DVCR). +1. Once the upload is complete, the resource becomes available for disk creation. There are different types of images: -- **ISO image**: An installation image used for the initial installation of an operating system. Such images are released by OS vendors and are used for installation on physical and virtual servers. -- **Preinstalled disk image**: Contains an already installed and configured operating system ready for use after the virtual machine is created. These images are offered by several vendors and can be provided in formats such as qcow2, raw, vmdk, and others. +- **ISO image**: An installation image used for the initial installation of an operating system (OS). Such images are released by OS vendors and are used for installation on physical and virtual servers. +- **Preinstalled disk image**: contains an already installed and configured operating system ready for use after the virtual machine is created. You can obtain pre-configured images from the distribution developers' resources or create them manually. Examples of resources for obtaining virtual machine images: -- [Ubuntu](https://cloud-images.ubuntu.com) -- [Debian](https://cdimage.debian.org/images/cloud/) -- [RockyLinux](https://download.rockylinux.org/pub/rocky/9.5/images/x86_64/) -- [CentOS](https://cloud.centos.org/centos/7/images/) +- Ubuntu + - [24.04 LTS (Noble Numbat)](https://cloud-images.ubuntu.com/noble/current/) + - [22.04 LTS (Jammy Jellyfish)](https://cloud-images.ubuntu.com/jammy/current/) + - [20.04 LTS (Focal Fossa)](https://cloud-images.ubuntu.com/focal/current/) + - [Minimal images](https://cloud-images.ubuntu.com/minimal/releases/) +- Debian + - [12 bookworm](https://cdimage.debian.org/images/cloud/bookworm/latest/) + - [11 bullseye](https://cdimage.debian.org/images/cloud/bullseye/latest/) +- AlmaLinux + - [9](https://repo.almalinux.org/almalinux/9/cloud/x86_64/images/) + - [8](https://repo.almalinux.org/almalinux/8/cloud/x86_64/images/) +- RockyLinux + - [9.5](https://download.rockylinux.org/pub/rocky/9.5/images/x86_64/) + - [8.10](https://download.rockylinux.org/pub/rocky/8.10/images/x86_64/) +- CentOS + - [10 Stream](https://cloud.centos.org/centos/10-stream/x86_64/images/) + - [9 Stream](https://cloud.centos.org/centos/9-stream/x86_64/images/) + - [8 Stream](https://cloud.centos.org/centos/8-stream/x86_64/) + - [8](https://cloud.centos.org/centos/8/x86_64/images/) + +The following preinstalled image formats are supported: + +- `qcow2` +- `raw` +- `vmdk` +- `vdi` + +Image files can also be compressed with one of the following compression algorithms: `gz`, `xz`. Once a resource is created, the image type and size are automatically determined, and this information is reflected in the resource status. @@ -43,37 +181,38 @@ For a full description of the ClusterVirtualImage resource configuration paramet In this example, let's create a cluster image. -Run the following command to create a ClusterVirtualImage resource: +1. To create a ClusterVirtualImage resource, run the following command: -```yaml -d8 k apply -f - <}} +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) +{{< /alert >}} + +To list all VirtualMachineClass resources, run the following command: + +```bash +d8 k get virtualmachineclass +``` + +Example output: + +```console +NAME PHASE AGE +generic Ready 6d1h +``` + +Make sure to specify the VirtualMachineClass resource in the virtual machine configuration. +The following is an example of specifying a class in the VM specification: + +```yaml +apiVersion: virtualization.deckhouse.io/v1alpha2 +kind: VirtualMachine +metadata: + name: linux-vm +spec: + virtualMachineClassName: generic # VirtualMachineClass resource name. + ... +``` + +### VirtualMachineClass settings + The VirtualMachineClass resource structure is as follows: ```yaml @@ -243,139 +425,124 @@ spec: sizingPolicies: ... ``` -{{< alert level="warning" >}} -Since changing the `.spec.nodeSelector` parameter affects all virtual machines using this `VirtualMachineClass`, consider the following: +Next, let's take a closer look at the setting blocks. -- For the Enterprise edition, this may cause virtual machines to be migrated to new destination nodes if the current nodes do not meet placement requirements. -- For the Community edition, this may cause virtual machines to restart according to the automatic change application policy set in the `.spec.disruptions.restartApprovalMode` parameter. +#### vCPU settings + +The `.spec.cpu` block allows you to specify or configure the vCPU for the VM. + +{{< alert level="warning">}} +Settings in the `.spec.cpu` block cannot be changed after the VirtualMachineClass resource is created. {{< /alert >}} -DVP provides three predefined VirtualMachineClass resources. -To get information on these resources, run the following command: +Examples of the `.spec.cpu` block settings: -```bash -d8 k get virtualmachineclass -``` +- A class with a vCPU with the required set of processor instructions. In this case, use `type: Features` to specify the required set of supported instructions for the processor: -Example output: + ```yaml + spec: + cpu: + features: + - vmx + type: Features + ``` -```console -NAME PHASE AGE -host Ready 6d1h -host-passthrough Ready 6d1h -generic Ready 6d1h -``` +- A class with a universal vCPU for a given set of nodes. In this case, use `type: Discovery`: -- `host`: This class uses a virtual CPU with an instruction set that is closely matching the platform node's CPU. This provides high performance and functionality, as well as compatibility with "live" migration for nodes with similar processor types. For example, you can't migrate a VM from an Intel-based node to an AMD-based node. This is also true for different generations of processors, as their instruction set is different. -- `host-passthrough`: Uses a physical CPU of the platform node directly, without any modifications. When using this class, a guest VM can only be migrated to a target node that has a CPU exactly matching the CPU of the source node. -- `generic`: A universal CPU model that uses the Nehalem microarchitecture, which is fairly old but still supported by the most modern CPUs. This allows running VMs on any node within a cluster with the "live" migration capability. + ```yaml + spec: + cpu: + discovery: + nodeSelector: + matchExpressions: + - key: node-role.kubernetes.io/control-plane + operator: DoesNotExist + type: Discovery + ``` -Make sure to specify the VirtualMachineClass resource in the virtual machine configuration. -The following is an example of specifying a class in the VM specification: +- The vmclass with `type: Host` uses a virtual vCPU that matches the platform node's vCPU instruction set as closely as possible, ensuring high performance and functionality. It also guarantees compatibility with live migration for nodes with similar vCPU types. For example, it is not possible to migrate a virtual machine between nodes with Intel and AMD processors. This also applies to processors of different generations, as their instruction sets may differ. -```yaml -apiVersion: virtualization.deckhouse.io/v1alpha2 -kind: VirtualMachine -metadata: - name: linux-vm -spec: - virtualMachineClassName: generic # VirtualMachineClass resource name. - ... -``` + ```yaml + spec: + cpu: + type: Host + ``` -{{< alert level="info" >}} -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. -{{< /alert >}} +- A vmclass with `type: HostPassthrough` uses a physical CPU of the platform node without modification. A virtual machine using this class can only be migrated to a node that has a CPU that exactly matches the CPU of the source node. -DVP administrators can create the required classes of virtual machines according to their needs, but a general recommendation is to at least create the required minimum. Consider examples from the following sections. + ```yaml + spec: + cpu: + type: HostPassthrough + ``` -### VirtualMachineClass configuration example +- To create a vCPU of a specific CPU with a predefined instruction set, use `type: Model`. To get a list of supported CPU names for the cluster node, run the command in advance: -![VirtualMachineClass configuration example](./images/vmclass-examples.png) + ```bash + d8 k get nodes -o json | jq '.metadata.labels | to_entries[] | select(.key | test("cpu-model.node.virtualization.deckhouse.io")) | .key | split("/")[1]' -r + ``` -Let's imagine that we have a cluster of four nodes. Two of these nodes labeled `group=blue` have a "CPU X" processor with three instruction sets, and the other two nodes labeled `group=green` have a newer "CPU Y" processor with four instruction sets. + Example output: -To optimally utilize the resources of this cluster, it is recommended that you create three additional virtual machine classes (VirtualMachineClass): + ```console + 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 + ``` -- `universal`: This class will allow virtual machines to run on all nodes in the platform and migrate between them. It will use the instruction set for the lowest CPU model to ensure the greatest compatibility. -- `cpuX`: This class will be for virtual machines that should only run on nodes with a "CPU X" processor. VMs will be able to migrate between these nodes using the available "CPU X" instruction sets. -- `cpuY`: This class is for VMs that should only run on nodes with a "CPU Y" processor. VMs will be able to migrate between these nodes using the available "CPU Y" instruction sets. + After that specify the following in the VirtualMachineClass resource specification: -{{< alert level="info" >}} -A CPU instruction set is a list of all the instructions that a processor can execute, such as addition, subtraction, or memory operations. They determine what operations are possible, affect program compatibility and performance, and can vary from one generation of processors to the next. -{{< /alert >}} + ```yaml + spec: + cpu: + model: IvyBridge + type: Model + ``` + +#### Placement settings -Sample resource configurations for a given cluster: +The `.spec.nodeSelector` block is optional. It allows you to specify the nodes that will host VMs using this vmclass: ```yaml ---- -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: { ... } + spec: + nodeSelector: + matchExpressions: + - key: node.deckhouse.io/group + operator: In + values: + - green ``` -### Other configuration options +{{< alert level="warning" >}} +Since changing the `.spec.nodeSelector` parameter affects all virtual machines using this `VirtualMachineClass`, consider the following: + +- For the Enterprise edition, this may cause virtual machines to be migrated to new destination nodes if the current nodes do not meet placement requirements. +- For the Community edition, this may cause virtual machines to restart according to the automatic change application policy set in the `.spec.disruptions.restartApprovalMode` parameter. +{{< /alert >}} -Example of the VirtualMachineClass resource configuration: +#### Sizing policy settings + +The `.spec.sizingPolicy` block allows you to set sizing policies for virtual machine resources that use vmclass. + +{{< alert level="warning" >}} +Changes in the `.spec.sizingPolicy` block can also affect virtual machines. For virtual machines whose sizing policy will not meet the new policy requirements, the `SizingPolicyMatched` condition in the `.status.conditions` block will be false (`status: False`). + +When configuring `sizingPolicy`, be sure to consider the [CPU topology](./user_guide.html#automatic-cpu-topology-configuration) for virtual machines. +{{< /alert >}} ```yaml -apiVersion: virtualization.deckhouse.io/v1alpha2 -kind: VirtualMachineClass -metadata: - name: discovery spec: - cpu: - # Configure a generic vCPU for a given set of nodes. - discovery: - nodeSelector: - matchExpressions: - - key: node-role.kubernetes.io/control-plane - operator: DoesNotExist - type: Discovery - # Allow VMs with this class to run only on nodes in the `worker` group. - nodeSelector: - matchExpressions: - - key: node.deckhouse.io/group - operator: In - values: - - worker - # Resource configuration policy. sizingPolicies: # For a range of 1–4 cores, it is possible to use 1–8 GB of RAM in 512Mi increments, # i.e., 1 GB, 1.5 GB, 2 GB, 2.5 GB, etc. @@ -415,12 +582,12 @@ spec: step: 1Gi dedicatedCores: [true, false] coreFractions: [50, 100] - # For the range of 17–1024 cores, it is possible to use 1–2 GB of RAM per core. + # For the range of 17–248 cores, it is possible to use 1–2 GB of RAM per core. # Only the dedicated cores are available for use. # The only available `corefraction` parameter is 100%. - cores: min: 17 - max: 1024 + max: 248 memory: perCore: min: 1Gi @@ -429,56 +596,66 @@ spec: coreFractions: [100] ``` -The following are fragments of the VirtualMachineClass configurations for different tasks: +### vCPU Discovery configuration example -- A class with a vCPU with the required set of processor instructions. In this case, we use `type: Features` to specify the required set of supported instructions for the processor: - - ```yaml - spec: - cpu: - features: - - vmx - type: Features - ``` - -- A class with a universal vCPU for a given set of nodes. In this case, we use `type: Discovery`: - - ```yaml - spec: - cpu: - discovery: - nodeSelector: - matchExpressions: - - key: node-role.kubernetes.io/control-plane - operator: DoesNotExist - type: Discovery - ``` +![VirtualMachineClass configuration example](./images/vmclass-examples.png) -- To create a vCPU of a specific CPU with a predefined instruction set, we use `type: Model`. To get a list of supported CPU names for the cluster node, run the command in advance: +Let's imagine that we have a cluster of four nodes. Two of these nodes labeled `group=blue` have a "CPU X" processor with three instruction sets, and the other two nodes labeled `group=green` have a newer "CPU Y" processor with four instruction sets. - ```bash - d8 k get nodes -o json | jq '.metadata.labels | to_entries[] | select(.key | test("cpu-model")) | .key | split("/")[1]'' -r - ``` +To optimally utilize the resources of this cluster, it is recommended that you create three additional virtual machine classes (VirtualMachineClass): - Example output: +- `universal`: This class will allow virtual machines to run on all nodes in the platform and migrate between them. It will use the instruction set for the lowest CPU model to ensure the greatest compatibility. +- `cpuX`: This class will be for virtual machines that should only run on nodes with a "CPU X" processor. VMs will be able to migrate between these nodes using the available "CPU X" instruction sets. +- `cpuY`: This class is for VMs that should only run on nodes with a "CPU Y" processor. VMs will be able to migrate between these nodes using the available "CPU Y" instruction sets. - ```console - IvyBridge - Nehalem - Opteron_G1 - Penryn - SandyBridge - Westmere - ``` +{{< alert level="info" >}} +A CPU instruction set is a list of all the instructions that a processor can execute, such as addition, subtraction, or memory operations. They determine what operations are possible, affect program compatibility and performance, and can vary from one generation of processors to the next. +{{< /alert >}} - After that specify the following in the VirtualMachineClass resource specification: +Resource configuration examples for a given cluster: - ```yaml - spec: - cpu: - model: IvyBridge - type: Model - ``` +```yaml +--- +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: { ... } +``` ## Reliability mechanisms @@ -486,9 +663,9 @@ The following are fragments of the VirtualMachineClass configurations for differ Virtual machine migration is an important feature in virtualized infrastructure management. It allows you to move running virtual machines from one physical node to another without shutting them down. Virtual machine migration is required for a number of tasks and scenarios: -- Load balancing. Moving virtual machines between nodes allows you to evenly distribute the load on servers, ensuring that resources are utilized in the best possible way. -- Node maintenance. Virtual machines can be moved from nodes that need to be taken out of service to perform routine maintenance or software upgrade. -- Upgrading a virtual machine firmware. The migration allows you to upgrade the firmware of virtual machines without interrupting their operation. +- **Load balancing**. Moving virtual machines between nodes allows you to evenly distribute the load on servers, ensuring that resources are utilized in the best possible way. +- **Node maintenance**. Virtual machines can be moved from nodes that need to be taken out of service to perform routine maintenance or software upgrade. +- **Upgrading a virtual machine firmware**. The migration allows you to upgrade the firmware of virtual machines without interrupting their operation. #### Start migration of an arbitrary machine @@ -541,6 +718,8 @@ The following is an example of migrating a selected virtual machine. linux-vm Running virtlab-pt-2 10.66.10.14 79m ``` +1. If you need to abort the migration, delete the corresponding `vmop` resource while it is in the `Pending` or `InProgress` phase. + #### Maintenance mode When working on nodes with virtual machines running, there is a risk of disrupting their performance. To avoid this, you can put a node into the maintenance mode and migrate the virtual machines to other free nodes. @@ -548,7 +727,7 @@ When working on nodes with virtual machines running, there is a risk of disrupti To do this, run the following command: ```bash -d8 k drain --ignore-daemonsets --delete-emptydir-dat +d8 k drain --ignore-daemonsets --delete-emptydir-data ``` Where `` is a node scheduled for maintenance, which needs to be freed from all resources (including system resources). @@ -559,7 +738,9 @@ If you need to evict only virtual machines off the node, run the following comma d8 k drain --pod-selector vm.kubevirt.internal.virtualization.deckhouse.io/name --delete-emptydir-data ``` -After running the `d8 k drain` command, the node will go into the maintenance mode and no virtual machines will be able to start on it. To take it out of the maintenance mode, run the following command: +After running the `d8 k drain` command, the node will enter maintenance mode and no virtual machines will be able to start on it. + +To take it out of maintenance mode, stop the `drain` command (Ctrl+C), then execute: ```bash d8 k uncordon @@ -574,95 +755,14 @@ ColdStandby provides a mechanism to recover a virtual machine from a failure on The following requirements must be met for this mechanism to work: - The virtual machine startup policy (`.spec.runPolicy`) must be set to one of the following values: `AlwaysOnUnlessStoppedManually`, `AlwaysOn`. -- The [fencing mechanism](https://deckhouse.io/products/kubernetes-platform/documentation/v1/modules/040-node-manager/cr.html#nodegroup-v1-spec-fencing-mode) must be enabled on nodes running the virtual machines. +- The [Fencing mechanism](https://deckhouse.io/products/kubernetes-platform/documentation/v1/modules/040-node-manager/cr.html#nodegroup-v1-spec-fencing-mode) must be enabled on nodes running the virtual machines. Let's see how it works on the example: -- A cluster consists of three nodes: master, workerA, and workerB. The worker nodes have the fencing mechanism enabled. -- The `linux-vm` virtual machine is running on the workerA node. -- A problem occurs on the workerA node (power outage, no network connection, etc.) -- The controller checks the node availability and finds that workerA is unavailable. -- The controller removes the workerA node from the cluster. -- The `linux-vm` virtual machine is started on another suitable node (workerB). +1. A cluster consists of three nodes: `master`, `workerA`, and `workerB`. The worker nodes have the Fencing mechanism enabled. The `linux-vm` virtual machine is running on the `workerA` node. +1. A problem occurs on the `workerA` node (power outage, no network connection, etc.). +1. The controller checks the node availability and finds that `workerA` is unavailable. +1. The controller removes the `workerA` node from the cluster. +1. The `linux-vm` virtual machine is started on another suitable node (`workerB`). ![ColdStandBy mechanism diagram](./images/coldstandby.png) - -## Disk and image storage settings - -For storing disks (VirtualDisk) and images (VirtualImage) with the `PersistentVolumeClaim` type, the storage provided by the platform is used. - -To check the list of storage supported by the platform, use the command for viewing storage classes (StorageClass): - -```bash -d8 k get storageclass -``` - -Example of the executed command: - -```console -NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -ceph-pool-r2-csi-rbd rbd.csi.ceph.com Delete WaitForFirstConsumer true 49d -ceph-pool-r2-csi-rbd-immediate (default) rbd.csi.ceph.com Delete Immediate true 49d -linstor-thin-r1 replicated.csi.storage.deckhouse.io Delete WaitForFirstConsumer true 28d -linstor-thin-r2 replicated.csi.storage.deckhouse.io Delete WaitForFirstConsumer true 78d -nfs-4-1-wffc nfs.csi.k8s.io Delete WaitForFirstConsumer true 49d -``` - -The `(default)` marker next to the class name indicates that this StorageClass will be used by default in case the user has not specified the class name explicitly in the created resource. - -If the default StorageClass is not present in the cluster, the user must specify the required StorageClass explicitly in the resource specification. - -In addition, the virtualization module allows you to specify individual settings for disk and image storage. - -### Storage class settings for images - -The storage class settings for images are defined in the `.spec.settings.virtualImages` parameter of the module settings. - -Example: - -```yaml -spec: - ... - settings: - virtualImages: - allowedStorageClassNames: - - sc-1 - - sc-2 - defaultStorageClassName: sc-1 -``` - -- `allowedStorageClassNames` (optional): A list of the allowed StorageClass for creating a `VirtualImage` that can be explicitly specified in the resource specification. -- `defaultStorageClassName`(optional): The StorageClass used by default when creating a `VirtualImage` if the `.spec.persistentVolumeClaim.storageClassName` parameter is not set. - -### Storage class settings for disks - -The storage class settings for disks are defined in the `.spec.settings.virtualDisks` parameter of the module settings. - -Example: - -```yaml -spec: - ... - settings: - virtualDisks: - allowedStorageClassNames: - - sc-1 - - sc-2 - defaultStorageClassName: sc-1 -``` - -- `allowedStorageClassNames` (optional): A list of the allowed StorageClass for creating a `VirtualDisk` that can be explicitly specified in the resource specification. -- `defaultStorageClassName` (optional): The StorageClass used by default when creating a `VirtualDisk` if the `.spec.persistentVolumeClaim.storageClassName` parameter is not specified. - -### Fine-tuning the storage classes for disks - -When you create a disk, the controller will automatically select the most optimal parameters supported by the storage based on the known data. - -The following are the priorities of the `PersistentVolumeClaim` parameter settings when creating a disk by automatically defining the storage features: - -- `RWX + Block` -- `RWX + FileSystem` -- `RWO + Block` -- `RWO + FileSystem` - -If the storage is unknown and it is impossible to automatically define its parameters, then `RWO + FileSystem` is used. diff --git a/docs/ADMIN_GUIDE_RU.md b/docs/ADMIN_GUIDE.ru.md similarity index 51% rename from docs/ADMIN_GUIDE_RU.md rename to docs/ADMIN_GUIDE.ru.md index c7e832ecea..09064ec19b 100644 --- a/docs/ADMIN_GUIDE_RU.md +++ b/docs/ADMIN_GUIDE.ru.md @@ -9,31 +9,171 @@ weight: 40 Также администратор обладает правами на управление проектными ресурсами, описание которых содержится [в Руководстве пользователя](./user_guide.html). +## Параметры модуля + +Конфигурация модуля `virtualization` задаётся через ресурс ModuleConfig в формате YAML. Ниже приведен пример базовой настройки: + +```yaml +apiVersion: deckhouse.io/v1alpha1 +kind: ModuleConfig +metadata: + name: virtualization +spec: + enabled: true + version: 1 + settings: + dvcr: + storage: + persistentVolumeClaim: + size: 50G + storageClassName: sds-replicated-thin-r1 + type: PersistentVolumeClaim + virtualMachineCIDRs: + - 10.66.10.0/24 +``` + +### Описание параметров + +**Включение модуля** + +Управление состоянием модуля осуществляется через поле `.spec.enabled`. Укажите: + +- `true` — чтобы включить модуль; +- `false` — чтобы выключить модуль. + +**Версия конфигурации** + +Параметр `.spec.version` определяет версию схемы настроек. Структура параметров может меняться между версиями. Актуальные значения приведены в разделе настроек. + +**Хранилище образов виртуальных машин (DVCR)** + +Блок `.spec.settings.dvcr.storage` настраивает постоянный том для хранения образов: + +- `.spec.settings.dvcr.storage.persistentVolumeClaim.size` — размер тома (например, `50G`). Для расширения хранилища увеличьте значение параметра; +- `.spec.settings.dvcr.storage.persistentVolumeClaim.storageClassName` — класс хранения (например, `sds-replicated-thin-r1`). + +**Сетевые настройки** + +В блоке `.spec.settings.virtualMachineCIDRs` указываются подсети в формате CIDR (например, `10.66.10.0/24`). IP-адреса для виртуальных машин распределяются из этих - диапазонов автоматически или по запросу. + +Пример: + +```yaml +spec: + settings: + virtualMachineCIDRs: + - 10.66.10.0/24 + - 10.66.20.0/24 + - 10.77.20.0/16 +``` + +Первый и последний адреса подсети зарезервированы и недоступны для использования. + +{{< alert level="warning" >}} +Подсети блока `.spec.settings.virtualMachineCIDRs` не должны пересекаться с подсетями узлов кластера, подсетью сервисов или подсетью подов (`podCIDR`). + +Запрещено удалять подсети, если адреса из них уже выданы виртуальным машинам. +{{< /alert >}} + +**Настройки классов хранения для образов** + +Настройки классов хранения для образов определяются в параметре `.spec.settings.virtualImages` настроек модуля. + +Пример: + +```yaml +spec: + ... + settings: + virtualImages: + allowedStorageClassNames: + - sc-1 + - sc-2 + defaultStorageClassName: sc-1 +``` + +Здесь: + +- `allowedStorageClassNames` (опционально) — это список допустимых StorageClass для создания VirtualImage, которые можно явно указать в спецификации ресурса; +- `defaultStorageClassName` (опционально) — это StorageClass, используемый по умолчанию при создании VirtualImage, если параметр `.spec.persistentVolumeClaim.storageClassName` не задан. + +**Настройки классов хранения для дисков** + +Настройки классов хранения для дисков определяются в параметре `.spec.settings.virtualDisks` настроек модуля. + +Пример: + +```yaml +spec: + ... + settings: + virtualDisks: + allowedStorageClassNames: + - sc-1 + - sc-2 + defaultStorageClassName: sc-1 +``` + +Здесь: + +- `allowedStorageClassNames` (опционально) — это список допустимых StorageClass для создания VirtualDisk, которые можно явно указать в спецификации ресурса; +- `defaultStorageClassName` (опционально) — это StorageClass, используемый по умолчанию при создании VirtualDisk, если параметр `.spec.persistentVolumeClaim.storageClassName` не задан. + +{{< alert level="info" >}} +Полный перечень параметров конфигурации приведен в разделе [Настройки](./configuration.html). +{{< /alert >}} + ## Образы Ресурс ClusterVirtualImage служит для загрузки образов виртуальных машин во внутрикластерное хранилище, после чего с его помощью можно создавать диски виртуальных машин. Он доступен во всех пространствах имен и проектах кластера. Процесс создания образа включает следующие шаги: -- Пользователь создаёт ресурс ClusterVirtualImage. -- После создания образ автоматически загружается из указанного в спецификации источника в хранилище (DVCR). -- После завершения загрузки ресурс становится доступным для создания дисков. +1. Пользователь создаёт ресурс ClusterVirtualImage. +1. После создания образ автоматически загружается из указанного в спецификации источника в хранилище (DVCR). +1. После завершения загрузки ресурс становится доступным для создания дисков. Существуют различные типы образов: -- **ISO-образ** — установочный образ, используемый для начальной установки операционной системы. Такие образы выпускаются производителями ОС и используются для установки на физические и виртуальные серверы. -- **Образ диска с предустановленной системой** — содержит уже установленную и настроенную операционную систему, готовую к использованию после создания виртуальной машины. Эти образы предлагаются несколькими производителями и могут быть представлены в таких форматах, как qcow2, raw, vmdk и другие. +- **ISO-образ** — установочный образ, используемый для начальной установки операционной системы (ОС). Такие образы выпускаются производителями ОС и используются для установки на физические и виртуальные серверы. +- **Образ диска с предустановленной системой** — содержит уже установленную и настроенную операционную систему, готовую к использованию после создания виртуальной машины. Готовые образы можно получить на ресурсах разработчиков дистрибутива, либо создать самостоятельно. Примеры ресурсов для получения образов виртуальной машины: -- [Ubuntu](https://cloud-images.ubuntu.com) -- [Debian](https://cdimage.debian.org/images/cloud/) -- [RockyLinux](https://download.rockylinux.org/pub/rocky/9.5/images/x86_64/) -- [CentOS](https://cloud.centos.org/centos/7/images/) -- [Alt Linux](https://ftp.altlinux.ru/pub/distributions/ALTLinux/platform/images/cloud/x86_64) +- Ubuntu + - [24.04 LTS (Noble Numbat)](https://cloud-images.ubuntu.com/noble/current/) + - [22.04 LTS (Jammy Jellyfish)](https://cloud-images.ubuntu.com/jammy/current/) + - [20.04 LTS (Focal Fossa)](https://cloud-images.ubuntu.com/focal/current/) + - [Minimal images](https://cloud-images.ubuntu.com/minimal/releases/) +- Debian + - [12 bookworm](https://cdimage.debian.org/images/cloud/bookworm/latest/) + - [11 bullseye](https://cdimage.debian.org/images/cloud/bullseye/latest/) +- AlmaLinux + - [9](https://repo.almalinux.org/almalinux/9/cloud/x86_64/images/) + - [8](https://repo.almalinux.org/almalinux/8/cloud/x86_64/images/) +- RockyLinux + - [9.5](https://download.rockylinux.org/pub/rocky/9.5/images/x86_64/) + - [8.10](https://download.rockylinux.org/pub/rocky/8.10/images/x86_64/) +- CentOS + - [10 Stream](https://cloud.centos.org/centos/10-stream/x86_64/images/) + - [9 Stream](https://cloud.centos.org/centos/9-stream/x86_64/images/) + - [8 Stream](https://cloud.centos.org/centos/8-stream/x86_64/) + - [8](https://cloud.centos.org/centos/8/x86_64/images/) +- Alt Linux + - [p10](https://ftp.altlinux.ru/pub/distributions/ALTLinux/p10/images/cloud/x86_64/) + - [p9](https://ftp.altlinux.ru/pub/distributions/ALTLinux/p9/images/cloud/x86_64/) - [Astra Linux](https://download.astralinux.ru/ui/native/mg-generic/alse/cloudinit) -После создания ресурса тип и размер образа определяются автоматически, и эта информация отражается в статусе ресурса. +Поддерживаются следующие форматы образов с предустановленной системой: + +- `qcow2`; +- `raw`; +- `vmdk`; +- `vdi`. + +Образы могут быть сжаты одним из следующих алгоритмов сжатия: `gz`, `xz`. + +После создания ресурса ClusterVirtualImage тип и размер образа определяются автоматически, и эта информация отражается в статусе ресурса. Образы могут быть загружены из различных источников, таких как HTTP-серверы, где расположены файлы образов, или контейнерные реестры. Также доступна возможность загрузки образов напрямую из командной строки с использованием утилиты `curl`. @@ -45,78 +185,81 @@ weight: 40 Рассмотрим вариант создания кластерного образа. -Выполните следующую команду для создания ресурса ClusterVirtualImage: +1. Чтобы создать ресурс ClusterVirtualImage, выполните следующую команду: -```yaml -d8 k apply -f - </ubuntu2204:latest @@ -178,7 +321,7 @@ d8 k describe cvi ubuntu-22.04 EOF ``` - После создания ресурс перейдет в фазу `WaitForUserUpload`, а это значит, что он готов для загрузки образа. + После создания ресурс перейдёт в фазу `WaitForUserUpload`, что говорит о готовности к загрузке образа. 1. Доступно два варианта загрузки — с узла кластера и с произвольного узла за пределами кластера: @@ -195,19 +338,24 @@ d8 k describe cvi ubuntu-22.04 } ``` + Здесь: + + - `inCluster` — URL-адрес, который используется, если необходимо выполнить загрузку образа с одного из узлов кластера; + - `external` — URL-адрес, который используется во всех остальных случаях. + 1. В качестве примера загрузите образ Cirros: ```bash curl -L http://download.cirros-cloud.net/0.5.1/cirros-0.5.1-x86_64-disk.img -o cirros.img ``` -1. Выполните загрузку образа с использование следующей команды: +1. Выполните загрузку образа с использованием следующей команды: ```bash curl https://virtualization.example.com/upload/g2OuLgRhdAWqlJsCMyNvcdt4o5ERIwmm --progress-bar -T cirros.img | cat ``` -1. После завершения загрузки образ должен быть создан и перейти в фазу `Ready`. +1. После завершения загрузки образ должен быть создан и переведён в фазу `Ready`. Чтобы проверить это, выполните следующую команду: ```bash @@ -223,7 +371,47 @@ d8 k describe cvi ubuntu-22.04 ## Классы виртуальных машин -Ресурс VirtualMachineClass предназначен для централизованной конфигурации предпочтительных параметров виртуальных машин. Он позволяет определять инструкции CPU, политики конфигурации ресурсов CPU и памяти для виртуальных машин, а также определять соотношения этих ресурсов. Помимо этого, VirtualMachineClass обеспечивает управление размещением виртуальных машин по узлам платформы. Это позволяет администраторам эффективно управлять ресурсами платформы виртуализации и оптимально размещать виртуальные машины на узлах платформы. +Ресурс VirtualMachineClass предназначен для централизованной конфигурации предпочтительных параметров виртуальных машин. +Он позволяет определять инструкции CPU, политики конфигурации ресурсов CPU и памяти для виртуальных машин, а также определять соотношения этих ресурсов. +Помимо этого, VirtualMachineClass обеспечивает управление размещением виртуальных машин по узлам платформы. +Это позволяет администраторам эффективно управлять ресурсами платформы виртуализации и оптимально размещать виртуальные машины на узлах платформы. + +По умолчанию автоматически создается один ресурс VirtualMachineClass `generic`, который представляет универсальную модель CPU, использующую достаточно старую, но поддерживаемую большинством современных процессоров модель Nehalem. Это позволяет запускать ВМ на любых узлах кластера с возможностью «живой» миграции. + +{{< alert level="info" >}} +Рекомендуется создать как минимум один ресурс VirtualMachineClass в кластере с типом `Discovery` сразу после того, как все узлы будут настроены и добавлены в кластер. +Это позволит использовать в виртуальных машинах универсальный процессор с максимально возможными характеристиками с учетом CPU на узлах кластера, что позволит виртуальным машинам использовать максимум возможностей CPU и при необходимости беспрепятственно осуществлять миграцию между узлами кластера. + +Пример настройки смотрите в разделе [Пример конфигурации vCPU Discovery](#пример-конфигурации-vcpu-discovery) +{{< /alert >}} + +Чтобы вывести список ресурсов VirtualMachineClass, выполните следующую команду: + +```bash +d8 k get virtualmachineclass +``` + +Пример вывода: + +```console +NAME PHASE AGE +generic Ready 6d1h +``` + +Обязательно указывайте ресурс VirtualMachineClass в конфигурации виртуальной машины. +Пример указания класса в спецификации ВМ: + +```yaml +apiVersion: virtualization.deckhouse.io/v1alpha2 +kind: VirtualMachine +metadata: + name: linux-vm +spec: + virtualMachineClassName: generic # Название ресурса VirtualMachineClass. + ... +``` + +### Настройки VirtualMachineClass Структура ресурса VirtualMachineClass выглядит следующим образом: @@ -246,139 +434,129 @@ spec: sizingPolicies: ... ``` -{{< alert level="warning" >}} -Поскольку изменение параметра `.spec.nodeSelector` влияет на все виртуальные машины, использующие данный ресурс VirtualMachineClass, следует учитывать следующее: +Далее рассмотрим настройки блоков более детально. -- Для Enterprise-редакции: это может привести к миграции виртуальных машин на новые узлы назначения, если текущие узлы не соответствуют требованиям размещения. -- Для Community-редакции: это может вызвать перезапуск виртуальных машин в соответствии с автоматической политикой применения изменений, установленной в параметре `.spec.disruptions.restartApprovalMode`. +#### Настройки vCPU + +Блок `.spec.cpu` позволяет задать или настроить vCPU для ВМ. + +{{< alert level="warning" >}} +Настройки блока `.spec.cpu` после создания ресурса VirtualMachineClass изменять нельзя. {{< /alert >}} -Платформа виртуализации предоставляет три предустановленных ресурса VirtualMachineClass. -Чтобы получить информацию об этих ресурсах, выполните следующую команду: +Примеры настройки блока `.spec.cpu`: -```bash -d8 k get virtualmachineclass -``` +- Класс с vCPU с требуемым набором процессорных инструкций. Для этого используйте `type: Features`, чтобы задать необходимый набор поддерживаемых инструкций для процессора: -Пример вывода: + ```yaml + spec: + cpu: + features: + - vmx + type: Features + ``` -```console -NAME PHASE AGE -host Ready 6d1h -host-passthrough Ready 6d1h -generic Ready 6d1h -``` +- Класс c универсальным vCPU для заданного набора узлов. Для этого используйте `type: Discovery`: -- `host` — данный класс использует виртуальный CPU, максимально близкий к CPU узла платформы по набору инструкций. Это обеспечивает высокую производительность и функциональность, а также совместимость с «живой» миграцией для узлов с похожими типами процессоров. Например, миграция ВМ между узлами с процессорами Intel и AMD не будет работать. Это также справедливо для процессоров разных поколений, так как набор инструкций у них отличается. -- `host-passthrough` - используется физический CPU узла платформы напрямую без каких-либо изменений. При использовании данного класса, гостевая ВМ может быть мигрирована только на целевой узел, у которого CPU точно соответствует CPU исходного узла. -- `generic` — универсальная модель CPU, использующая достаточно старую, но поддерживаемую большинством современных процессоров модель Nehalem. Это позволяет запускать ВМ на любых узлах кластера с возможностью «живой» миграции. + ```yaml + spec: + cpu: + discovery: + nodeSelector: + matchExpressions: + - key: node-role.kubernetes.io/control-plane + operator: DoesNotExist + type: Discovery + ``` -Обязательно указывайте ресурс VirtualMachineClass в конфигурации виртуальной машины. -Пример указания класса в спецификации ВМ: +- Класс c `type: Host` использует виртуальный vCPU, максимально соответствующий набору инструкций vCPU узла платформы, что обеспечивает высокую производительность и функциональность. + Он также гарантирует совместимость с живой миграцией для узлов с похожими типами процессоров. + Например, миграция виртуальной машины между узлами с процессорами Intel и AMD невозможна. Это также относится к процессорам разных поколений, так как их наборы инструкций могут отличаться. -```yaml -apiVersion: virtualization.deckhouse.io/v1alpha2 -kind: VirtualMachine -metadata: - name: linux-vm -spec: - virtualMachineClassName: generic # Название ресурса VirtualMachineClass. - ... -``` + ```yaml + spec: + cpu: + type: Host + ``` -{{< alert level="info" >}} -Рекомендуется создать как минимум один ресурс VirtualMachineClass в кластере с типом `Discovery` сразу после того как все узлы будут настроены и добавлены в кластер. Это позволит использовать в виртуальных машинах универсальный процессор с максимально возможными характеристиками с учетом CPU на узлах кластера, что позволит виртуальным машинам использовать максимум возможностей CPU и при необходимости беспрепятственно осуществлять миграцию между узлами кластера. -{{< /alert >}} +- Класс с `type: HostPassthrough` использует физический CPU узла платформы без изменений. + Виртуальная машина, использующая этот класс, может быть мигрирована только на узел, у которого CPU точно совпадает с CPU исходного узла. -Администраторы платформы могут создавать требуемые классы виртуальных машин по своим потребностям, но рекомендуется создавать необходимый минимум. Рассмотрим на примере в следующем разделе. + ```yaml + spec: + cpu: + type: HostPassthrough + ``` -### Пример конфигурации VirtualMachineClass +- Чтобы создать vCPU конкретного процессора с предварительно определённым набором инструкций, используйте тип `type: Model`. + Предварительно, чтобы получить перечень названий поддерживаемых CPU для узла кластера, выполните команду: -![Пример конфигурации VirtualMachineClass](./images/vmclass-examples.ru.png) + ```bash + d8 k get nodes -o json | jq '.metadata.labels | to_entries[] | select(.key | test("cpu-model.node.virtualization.deckhouse.io")) | .key | split("/")[1]' -r + ``` -Представим, что у нас есть кластер из четырех узлов. Два из этих узлов с лейблом `group=blue` оснащены процессором «CPU X» с тремя наборами инструкций, а остальные два узла с лейблом `group=green` имеют более новый процессор «CPU Y» с четырьмя наборами инструкций. + Пример вывода: -Для оптимального использования ресурсов данного кластера рекомендуется создать три дополнительных класса виртуальных машин (VirtualMachineClass): + ```console + 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 + ``` -- `universal` — этот класс позволит виртуальным машинам запускаться на всех узлах платформы и мигрировать между ними. При этом будет использоваться набор инструкций для самой младшей модели CPU, что обеспечит наибольшую совместимость. -- `cpuX` — этот класс будет предназначен для виртуальных машин, которые должны запускаться только на узлах с процессором «CPU X». ВМ смогут мигрировать между этими узлами, используя доступные наборы инструкций «CPU X». -- `cpuY` — этот класс предназначен для виртуальных машин, которые должны запускаться только на узлах с процессором «CPU Y». ВМ смогут мигрировать между этими узлами, используя доступные наборы инструкций «CPU Y». + Далее укажите в спецификации ресурса VirtualMachineClass следующее: -{{< alert level="info" >}} -Набор инструкций для процессора — это список всех команд, которые процессор может выполнять, таких как сложение, вычитание или работа с памятью. Они определяют, какие операции возможны, влияют на совместимость программ и производительность, а также могут меняться от одного поколения процессоров к другому. -{{< /alert >}} + ```yaml + spec: + cpu: + model: IvyBridge + type: Model + ``` -Примерные конфигурации ресурсов для данного кластера: +#### Настройки размещения + +Блок `.spec.nodeSelector` опционален. Он позволяет задать узлы, на которых будут размещаться ВМ, использующие данный vmclass: ```yaml ---- -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: { ... } + spec: + nodeSelector: + matchExpressions: + - key: node.deckhouse.io/group + operator: In + values: + - green ``` -### Прочие варианты конфигурации +{{< alert level="warning" >}} +Поскольку изменение параметра `.spec.nodeSelector` влияет на все виртуальные машины, использующие данный ресурс VirtualMachineClass, следует учитывать следующее: + +- в Enterprise-редакции это может привести к миграции виртуальных машин на новые узлы назначения, если текущие узлы не соответствуют требованиям размещения; +- в Community-редакции это может вызвать перезапуск виртуальных машин в соответствии с автоматической политикой применения изменений, установленной в параметре `.spec.disruptions.restartApprovalMode`. +{{< /alert >}} + +#### Настройки политики сайзинга -Пример конфигурации ресурса VirtualMachineClass: +Блок `.spec.sizingPolicy` позволяет задать политики сайзинга ресурсов виртуальных машин, которые используют vmclass. + +{{< alert level="warning" >}} +Изменения в блоке `.spec.sizingPolicy` также могут повлиять на виртуальные машины. +Для виртуальных машин, чья политика сайзинга не будет соответствовать новым требованиям политики, условие `SizingPolicyMatched` в блоке `.status.conditions` будет ложным (`status: False`). + +При настройке `sizingPolicy` будьте внимательны и учитывайте [топологию CPU](./user_guide.html#автоматическая-конфигурация-топологии-cpu) для виртуальных машин. +{{< /alert >}} ```yaml -apiVersion: virtualization.deckhouse.io/v1alpha2 -kind: VirtualMachineClass -metadata: - name: discovery spec: - cpu: - # Сконфигурировать универсальный vCPU для заданного набора узлов. - discovery: - nodeSelector: - matchExpressions: - - key: node-role.kubernetes.io/control-plane - operator: DoesNotExist - type: Discovery - # Разрешать запуск ВМ с данным классом только на узлах группы `worker`. - nodeSelector: - matchExpressions: - - key: node.deckhouse.io/group - operator: In - values: - - worker - # Политика конфигурации ресурсов. sizingPolicies: # Для диапазона от 1 до 4 ядер возможно использовать от 1 до 8 ГБ оперативной памяти с шагом 512Mi, # т.е 1 ГБ, 1,5 ГБ, 2 ГБ, 2,5 ГБ и т. д. @@ -418,12 +596,12 @@ spec: step: 1Gi dedicatedCores: [true, false] coreFractions: [50, 100] - # Для диапазона от 17 до 1024 ядер возможно использовать от 1 до 2 ГБ оперативной памяти из расчета на одно ядро. + # Для диапазона от 17 до 248 ядер возможно использовать от 1 до 2 ГБ оперативной памяти из расчёта на одно ядро. # Доступны для использования только выделенные ядра. # Единственный доступный параметр `corefraction` = 100%. - cores: min: 17 - max: 1024 + max: 248 memory: perCore: min: 1Gi @@ -432,55 +610,66 @@ spec: coreFractions: [100] ``` -Далее приведены фрагменты конфигураций VirtualMachineClass для решения различных задач: - -- Класс с vCPU с требуемым набором процессорных инструкций. Для этого используем `type: Features`, чтобы задать необходимый набор поддерживаемых инструкций для процессора: - - ```yaml - spec: - cpu: - features: - - vmx - type: Features - ``` - -- Класс c универсальным vCPU для заданного набора узлов. Для этого используем `type: Discovery`: +### Пример конфигурации vCPU Discovery - ```yaml - spec: - cpu: - discovery: - nodeSelector: - matchExpressions: - - key: node-role.kubernetes.io/control-plane - operator: DoesNotExist - type: Discovery - ``` +![Пример конфигурации VirtualMachineClass](./images/vmclass-examples.ru.png) -- Чтобы создать vCPU конкретного процессора с предварительно определённым набором инструкций, используем тип `type: Model`. Предварительно, чтобы получить перечень названий поддерживаемых CPU для узла кластера, выполните команду: +Представим, что у нас есть кластер из четырех узлов. Два из этих узлов с лейблом `group=blue` оснащены процессором «CPU X» с тремя наборами инструкций, а остальные два узла с лейблом `group=green` имеют более новый процессор «CPU Y» с четырьмя наборами инструкций. - ```bash - d8 k get nodes -o json | jq '.metadata.labels | to_entries[] | select(.key | test("cpu-model")) | .key | split("/")[1]' -r +Для оптимального использования ресурсов данного кластера рекомендуется создать три дополнительных класса виртуальных машин (VirtualMachineClass): - Пример вывода: +- `universal` — этот класс позволит виртуальным машинам запускаться на всех узлах платформы и мигрировать между ними. При этом будет использоваться набор инструкций для самой младшей модели CPU, что обеспечит наибольшую совместимость; +- `cpuX` — этот класс будет предназначен для виртуальных машин, которые должны запускаться только на узлах с процессором «CPU X». ВМ смогут мигрировать между этими узлами, используя доступные наборы инструкций «CPU X»; +- `cpuY` — этот класс предназначен для виртуальных машин, которые должны запускаться только на узлах с процессором «CPU Y». ВМ смогут мигрировать между этими узлами, используя доступные наборы инструкций «CPU Y». - ```console - IvyBridge - Nehalem - Opteron_G1 - Penryn - SandyBridge - Westmere - ``` +{{< alert level="info" >}} +Набор инструкций для процессора — это набор всех команд, которые процессор может выполнять, таких как сложение, вычитание или работа с памятью. Они определяют, какие операции возможны, влияют на совместимость программ и производительность, а также могут меняться от одного поколения процессоров к другому. +{{< /alert >}} - Далее укажите в спецификации ресурса VirtualMachineClass следующее: +Примерные конфигурации ресурсов для данного кластера: - ```yaml - spec: - cpu: - model: IvyBridge - type: Model - ``` +```yaml +--- +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: { ... } +``` ## Механизмы обеспечения надежности @@ -488,9 +677,9 @@ spec: Миграция виртуальных машин является важной функцией в управлении виртуализированной инфраструктурой. Она позволяет перемещать работающие виртуальные машины с одного физического узла на другой без их отключения. Миграция виртуальных машин необходима для ряда задач и сценариев: -- Балансировка нагрузки. Перемещение виртуальных машин между узлами позволяет равномерно распределять нагрузку на серверы, обеспечивая использование ресурсов наилучшим образом. -- Перевод узла в режим обслуживания. Виртуальные машины могут быть перемещены с узлов, которые нужно вывести из эксплуатации для выполнения планового обслуживания или обновления программного обеспечения. -- Обновление «прошивки» виртуальных машин. Миграция позволяет обновить «прошивку» виртуальных машины, не прерывая их работу. +- **Балансировка нагрузки**. Перемещение виртуальных машин между узлами позволяет равномерно распределять нагрузку на серверы, обеспечивая использование ресурсов наилучшим образом. +- **Перевод узла в режим обслуживания**. Виртуальные машины могут быть перемещены с узлов, которые нужно вывести из эксплуатации для выполнения планового обслуживания или обновления программного обеспечения. +- **Обновление «прошивки» виртуальных машин**. Миграция позволяет обновить «прошивку» виртуальных машины, не прерывая их работу. #### Запуск миграции произвольной машины @@ -543,25 +732,29 @@ spec: linux-vm Running virtlab-pt-2 10.66.10.14 79m ``` +1. Если необходимо прервать миграцию, удалите соответствующий ресурс `vmop`, пока он находится в фазе `Pending` или `InProgress`. + #### Режим обслуживания При выполнении работ на узлах с запущенными виртуальными машинами существует риск нарушения их работоспособности. Чтобы этого избежать, узел можно перевести в режим обслуживания и мигрировать виртуальные машины на другие свободные узлы. -Для этого необходимо выполнить следующую команду: +Для этого выполните следующую команду: ```bash -d8 k drain --ignore-daemonsets --delete-emptydir-dat +d8 k drain --ignore-daemonsets --delete-emptydir-data ``` -где `` - узел, на котором предполагается выполнить работы и который должен быть освобожден от всех ресурсов (в том числе и от системных). +где `` — узел, на котором предполагается выполнить работы и который должен быть освобождён от всех ресурсов (в том числе от системных). -Если есть необходимость вытеснить с узла только виртуальные машины, выполните следующую команду: +Если необходимо вытеснить с узла только виртуальные машины, выполните следующую команду: ```bash d8 k drain --pod-selector vm.kubevirt.internal.virtualization.deckhouse.io/name --delete-emptydir-data ``` -После выполнения команды `d8 k drain` узел перейдёт в режим обслуживания, и виртуальные машины на нём запускаться не смогут. Чтобы вывести его из режима обслуживания, выполните следующую команду: +После выполнения команды `d8 k drain` узел перейдёт в режим обслуживания, и виртуальные машины на нём запускаться не смогут. + +Чтобы вывести его из режима обслуживания, остановите выполнение команды `drain` (Ctrl+C), затем выполните: ```bash d8 k uncordon @@ -575,96 +768,17 @@ ColdStandby обеспечивает механизм восстановлени Для работы данного механизма необходимо выполнить следующие требования: -- Для политики запуска виртуальной машины (`.spec.runPolicy`) должно быть установлено одно из следующих значений: `AlwaysOnUnlessStoppedManually`, `AlwaysOn`. -- На узлах, где запущены виртуальные машины, должен быть включён механизм [fencing](https://deckhouse.ru/products/kubernetes-platform/documentation/v1/modules/040-node-manager/cr.html#nodegroup-v1-spec-fencing-mode). +- для политики запуска виртуальной машины (`.spec.runPolicy`) должно быть установлено одно из следующих значений: `AlwaysOnUnlessStoppedManually`, `AlwaysOn`; +- на узлах, где запущены виртуальные машины, должен быть включён механизм [Fencing](https://deckhouse.ru/products/kubernetes-platform/documentation/v1/modules/040-node-manager/cr.html#nodegroup-v1-spec-fencing-mode). Рассмотрим как это работает на примере: -- Кластер состоит из трех узлов: master, workerA и workerB. На worker-узлах включён механизм Fencing. -- Виртуальная машина `linux-vm` запущена на узле workerA. -- На узле workerA возникает проблема (выключилось питание, пропала сеть, и т. д.) -- Контроллер проверяет доступность узлов и обнаруживает, что workerA недоступен. -- Контроллер удаляет узел workerA из кластера. -- Виртуальная машина `linux-vm` запускается на другом подходящем узле (workerB). +1. Кластер состоит из трех узлов: `master`, `workerA` и `workerB`. + На worker-узлах включён механизм Fencing. + Виртуальная машина `linux-vm` запущена на узле `workerA`. +1. На узле `workerA` возникает проблема (выключилось питание, пропала сеть, и т. д.). +1. Контроллер проверяет доступность узлов и обнаруживает, что `workerA` недоступен. +1. Контроллер удаляет узел `workerA` из кластера. +1. Виртуальная машина `linux-vm` запускается на другом подходящем узле (`workerB`). ![Схема работы механизма ColdStandBy](./images/coldstandby.ru.png) - -## Настройки хранения дисков и образов - -Для хранения дисков (VirtualDisk) и образов (VirtualImage) с типом `PersistentVolumeClaim` используются хранилища, предоставляемые платформой. - -Перечень поддерживаемых платформой хранилищ можно посмотреть, выполнив команду для просмотра классов хранилищ (StorageClass): - -```bash -d8 k get storageclass -``` - -Пример вывода команды: - -```console -NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -ceph-pool-r2-csi-rbd rbd.csi.ceph.com Delete WaitForFirstConsumer true 49d -ceph-pool-r2-csi-rbd-immediate (default) rbd.csi.ceph.com Delete Immediate true 49d -linstor-thin-r1 replicated.csi.storage.deckhouse.io Delete WaitForFirstConsumer true 28d -linstor-thin-r2 replicated.csi.storage.deckhouse.io Delete WaitForFirstConsumer true 78d -nfs-4-1-wffc nfs.csi.k8s.io Delete WaitForFirstConsumer true 49d -``` - -Маркер `(default)` рядом с названием класса показывает, что данный StorageClass будет использоваться по умолчанию в случае, если пользователь не указал название класса явно в создаваемом ресурсе. - -Если StorageClass по умолчанию в кластере отсутствует, то пользователь должен явно указать требуемый StorageClass в спецификации ресурса. - -Также модуль `virtualization` позволяет задать индивидуальные настройки для хранения дисков и образов. - -### Настройки классов хранения для образов - -Настройки классов хранения для образов определяется в параметре `.spec.settings.virtualImages` настроек модуля. - -Пример: - -```yaml -spec: - ... - settings: - virtualImages: - allowedStorageClassNames: - - sc-1 - - sc-2 - defaultStorageClassName: sc-1 -``` - -- `allowedStorageClassNames` (опционально) — это список допустимых StorageClass для создания `VirtualImage`, которые можно явно указать в спецификации ресурса. -- `defaultStorageClassName` (опционально) — это StorageClass, используемый по умолчанию при создании `VirtualImage`, если параметр `.spec.persistentVolumeClaim.storageClassName` не задан. - -### Настройки классов хранения для дисков - -Настройки классов хранения для дисков определяются в параметре `.spec.settings.virtualDisks` настроек модуля. - -Пример: - -```yaml -spec: - ... - settings: - virtualDisks: - allowedStorageClassNames: - - sc-1 - - sc-2 - defaultStorageClassName: sc-1 -``` - -- `allowedStorageClassNames` (опционально) — это список допустимых StorageClass для создания `VirtualDisk`, которые можно явно указать в спецификации ресурса. -- `defaultStorageClassName` (опционально) — это StorageClass, используемый по умолчанию при создании `VirtualDisk`, если параметр `.spec.persistentVolumeClaim.storageClassName` не задан. - -### Тонкая настройка классов хранения для дисков - -При создании диска контроллер автоматически выберет наиболее оптимальные параметры, поддерживаемые хранилищем, на основании известных ему данных. - -Приоритеты настройки параметров `PersistentVolumeClaim` при создании диска посредством автоматического определения характеристик хранилища: - -- `RWX + Block`; -- `RWX + FileSystem`; -- `RWO + Block`; -- `RWO + FileSystem`. - -Если хранилище неизвестно и определить его параметры автоматически невозможно, используется режим `RWO + FileSystem`. diff --git a/docs/CHARACTERISTICS_DESCRIPTION_RU.md b/docs/CHARACTERISTICS_DESCRIPTION.ru.md similarity index 100% rename from docs/CHARACTERISTICS_DESCRIPTION_RU.md rename to docs/CHARACTERISTICS_DESCRIPTION.ru.md diff --git a/docs/CONFIGURATION_RU.md b/docs/CONFIGURATION.ru.md similarity index 100% rename from docs/CONFIGURATION_RU.md rename to docs/CONFIGURATION.ru.md diff --git a/docs/CR_RU.md b/docs/CR.ru.md similarity index 100% rename from docs/CR_RU.md rename to docs/CR.ru.md diff --git a/docs/FAQ.md b/docs/FAQ.md index 7809aff84d..128e9633bc 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -310,8 +310,7 @@ d8 k create secret generic sysprep-config --type="provisioning.virtualization.de Then you can create a virtual machine that will use an answer file during installation. To provide the Windows virtual machine with the answer file, you need to specify provisioning with the type SysprepRef. -You can also specify here other files in base64 format (customize.ps1, id_rsa.pub, ...) -that you need to successfully execute scripts inside the answer file. +You can also specify here other files in base64 format, that you need to successfully execute scripts inside the answer file. ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -362,7 +361,7 @@ Ansible inventory file example: --- all: vars: - ansible_ssh_common_args: '-o ProxyCommand=“d8 v port-forward --stdio=true %h %h %p”' + ansible_ssh_common_args: '-o ProxyCommand="d8 v port-forward --stdio=true %h %h %p"' # Default user for SSH access. ansible_user: cloud # Path to private key. @@ -374,7 +373,7 @@ all: To check the virtual machine's uptime value, use the following command: ```bash -ansible -m shell -a “uptime” -i inventory.yaml all +ansible -m shell -a "uptime" -i inventory.yaml all # frontend.demo-app | CHANGED | rc=0 >> # 12:01:20 up 2 days, 4:59, 0 users, load average: 0.00, 0.00, 0.00 ``` @@ -382,11 +381,11 @@ ansible -m shell -a “uptime” -i inventory.yaml all If you prefer not to use the inventory file, you can specify and pass all the parameters directly in the command line: ```bash -ansible -m shell -a “uptime” \ - -i “frontend.demo-app,” \ - -e “ansible_ssh_common_args='-o ProxyCommand=\”d8 v port-forward --stdio=true %h %p %p\'"” \ - -e “ansible_user=cloud” \ - -e “ansible_ssh_private_key_file=./tmp/demo” \ +ansible -m shell -a "uptime" \ + -i "frontend.demo-app," \ + -e "ansible_ssh_common_args='-o ProxyCommand=\"d8 v port-forward --stdio=true %h %p %p\"'" \ + -e "ansible_user=cloud" \ + -e "ansible_ssh_private_key_file=./tmp/demo" \ all ``` @@ -465,14 +464,14 @@ To increase the disk size for DVCR, you must set a larger size in the `virtualiz Example output: ```console - {“size”:“58G”,“storageClass”:“linstor-thick-data-r1”} + {"size":"58G","storageClass":"linstor-thick-data-r1"} ``` 1. Set the size: ```shell d8 k patch mc virtualization \ - --type merge -p '{“spec”: { “settings”: { “dvcr”: { “storage”: { “persistentVolumeClaim”: {“size”: “59G”}}}}}}'' + --type merge -p '{"spec": { "settings": { "dvcr": { "storage": { "persistentVolumeClaim": {"size": "59G"}}}}}}' ``` Example output: @@ -490,7 +489,7 @@ To increase the disk size for DVCR, you must set a larger size in the `virtualiz Example output: ```console - {“size”:“59G”,“storageClass”:“linstor-thick-data-r1”} + {"size":"59G","storageClass":"linstor-thick-data-r1"} 1. Check the current status of the DVCR: diff --git a/docs/FAQ_RU.md b/docs/FAQ.ru.md similarity index 98% rename from docs/FAQ_RU.md rename to docs/FAQ.ru.md index 17455ce260..96e05c130d 100644 --- a/docs/FAQ_RU.md +++ b/docs/FAQ.ru.md @@ -309,8 +309,7 @@ d8 k create secret generic sysprep-config --type="provisioning.virtualization.de Затем можно создать виртуальную машину, которая в процессе установки будет использовать файл ответов. Чтобы предоставить виртуальной машине Windows файл ответов, необходимо указать provisioning с типом SysprepRef. -Вы также можете указать здесь другие файлы в формате base64 (customize.ps1, id_rsa.pub,...), -необходимые для успешного выполнения скриптов внутри файла ответов. +Вы также можете указать здесь другие файлы в формате base64, необходимые для успешного выполнения скриптов внутри файла ответов. ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -428,7 +427,7 @@ ansible -m shell -a "uptime" \ ``` Можно изменять метки виртуальной машины без необходимости перезапуска, что позволяет настраивать перенаправление сетевого трафика между различными сервисами в реальном времени. - + Предположим, что был создан новый сервис и требуется перенаправить трафик на виртуальную машину от этого сервиса: ```yaml diff --git a/docs/INSTALL.md b/docs/INSTALL.md index e5d44a517a..4c61e6465c 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -3,57 +3,60 @@ title: "Installation" weight: 15 --- -> **Warning.** The platform components must be deployed on physical servers (bare-metal servers). -> -> Installation on virtual machines is allowed for demonstration purposes only, but nested virtualization must be enabled. If the platform is deployed on virtual machines, technical support will not be provided. +{{< alert level="warning" >}} +Module components must be deployed on physical servers (bare-metal). + +Installation on virtual machines is allowed for demonstration purposes only, but nested virtualization must be enabled. If the module is deployed on virtual machines, technical support is not provided. +{{< /alert >}} -## Platform scalability +## Scaling options -The platform supports the following configuration: +The module supports the following configuration: -- Maximum number of nodes: 1000. -- Maximum number of virtual machines: 50000. +- Maximum number of nodes: `1000`. +- Maximum number of virtual machines: `50000`. -The platform has no other restrictions and is compatible with any hardware that is supported by [operating systems](#supported-os-for-platform-nodes) on which it can be installed. +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 +## 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). + - 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 at installation time. The others can be added later via node management mechanisms. + 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; + - 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; + - 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; + - **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 p.1); - - Network access from the **installation machine** (see p.1) on port `22322/TCP`. + - 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). - > **Warning.** The container runtime will be installed automatically, so do not pre-install any `containerd` or `docker` packages. + + > The container runtime will be installed automatically, so there's no need to install any `containerd` or `docker` packages. 1. **Servers for worker nodes** @@ -63,28 +66,29 @@ The platform has no other restrictions and is compatible with any hardware that - Resources: - CPU: - - x86_64 architecture; - - Support for Intel-VT (VMX) or AMD-V (SVM) instructions; - - At least 4 cores; - - RAM: At least 8 GB; + - 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); + - 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; + - **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 p.1); + - 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). - > **Important.** The container runtime will be installed automatically, so do not pre-install any `containerd` or `docker` packages. + + > 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 the section [Storage Management](/products/virtualization-platform/documentation/admin/platform-management/storage/sds/lvm-local.html). + 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 @@ -94,44 +98,52 @@ The platform has no other restrictions and is compatible with any hardware that | Debian | 10, 11, 12 | | Ubuntu | 20.04, 22.04, 24.04 | +{{< 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. +{{< /alert >}} + ## Supported guest operating systems The virtualization platform supports operating systems running on `x86` and `x86_64` architectures as guest operating systems. For correct operation in paravirtualization mode, `VirtIO` drivers must be installed to ensure efficient interaction between the virtual machine and the hypervisor. Successful startup of the operating system is determined by the following criteria: - * correct installation and booting of the OS; - * uninterrupted operation of key components such as networking and storage; - * no crashes or errors during operation. +* Correct installation and booting of the OS. +* Uninterrupted operation of key components such as networking and storage. +* No crashes or errors during operation. -For Linux family operating systems it is recommended to use guest OS images with `cloud-init` support, which allows initializing virtual machines after their creation. +For Linux family operating systems, it is recommended to use guest OS images with `cloud-init` support, which allows initializing virtual machines after their creation. -For Windows operating systems, the platform supports initialization using the built-in sysprep utility. +For Windows family operating systems, the platform supports initialization with [autounattend](https://learn.microsoft.com/ru-ru/windows-hardware/manufacture/desktop/windows-setup-automation-overview) installation. ## Supported virtual machine configurations -Maximum number of cores supported: `254` -Maximum amount of RAM: `1024 GB` +- Maximum number of cores supported: `248`. +- Maximum amount of RAM: `1024 GB`. -## Supported Storage Systems +## Supported storage systems Virtual machines use `PersistentVolume` resources. To manage these resources and allocate disk space within the cluster, one or more supported storage systems must be installed: | Storage System | Disk Location | |---------------------------------------------|----------------------------| -| LVM (Logical Volume Manager) | Local | -| DRBD (Distributed Replicated Block Device) | Replicas on cluster nodes | -| Ceph Cluster | External storage | -| NFS (Network File System) | External storage | -| TATLIN.UNIFIED (Yadro) | External storage | +| sds-local-volume | Local | +| sds-replicated-volume | Replicas on cluster nodes | +| Ceph Cluster | External storage | +| NFS (Network File System) | External storage | +| TATLIN.UNIFIED (Yadro) | External storage | +| Huawei Dorado | External storage | +| HPE 3par | External storage | ## Installation -1. Deploy the Deckhouse Kubernetes Platform cluster by [instruction](https://deckhouse.io/products/kubernetes-platform/gs/). +1. Deploy the Deckhouse Kubernetes Platform cluster following the [instructions](https://deckhouse.io/products/kubernetes-platform/gs/). -2. To store virtual machine data (virtual disks and images), you must enable one or more supported [storage](#supported-storage-systems). +2. To store virtual machine data (virtual disks and images), enable one or multiple [supported storages](#supported-storage-systems). -3. Set default `StorageClass`. +3. Set the default `StorageClass`: ```shell # Specify the name of your StorageClass object. @@ -139,62 +151,71 @@ Virtual machines use `PersistentVolume` resources. To manage these resources and sudo -i d8 k patch mc global --type='json' -p='[{"op": "replace", "path": "/spec/settings/defaultClusterStorageClass", "value": "'"$DEFAULT_STORAGE_CLASS"'"}]' ``` -4. Turn on the [console](https://deckhouse.io/modules/console/stable/) module, which will allow you to manage virtualization components through via UI (This feature is available only to users of the EE edition). +4. Turn on the [`console`](https://deckhouse.io/modules/console/stable/) module, which will allow you to manage virtualization components through the Deckhouse web UI (available only for users of the Enterprise Edition). 5. Enable the `virtualization` module: -{{< alert level="warning" >}} -Attention! Enabling the `virtualization` module involves restarting kubelet/containerd on all nodes where virtual machines are supposed to start. This is necessary to configure the connectivity of containerd and DVCR. -{{< /alert >}} - -To enable the `virtualization` module, you need to create a `ModuleConfig` resource containing the module settings. + {{< alert level="warning" >}} + Enabling the `virtualization` module involves restarting kubelet/containerd and cilium agents on all nodes where virtual machines are supposed to start. This is necessary to configure the connectivity of containerd and DVCR. + {{< /alert >}} + + To enable the `virtualization` module, create a `ModuleConfig` resource with the module settings. + + {{< alert level="info" >}} + Detailed settings are described in the [Administrator guide](./admin_guide.html#module-parameters). + {{< /alert >}} + + Example of module configuration: + + ```yaml + d8 k apply -f - <}} -For a complete list of configuration options, see ["Settings"](./configuration.html) -{{< /alert >}} + Where: -Example of module configuration: + - The `.spec.settings.dvcr` block describes the settings for the repository for storing virtual machine images. It specifies the size of the storage provided for storing images `.spec.settings.dvcr.storage.persistentVolumeClaim.size` and the storage class `.spec.settings.dvcr.storage.persistentVolumeClaim.storageClassName`. + - The `.spec.settings.virtualMachineCIDRs` block specifies the list of subnets. Virtual machine addresses will be allocated automatically or on request from the specified subnet ranges in order. -```yaml -d8 k apply -f - <}} + Subnets of `.spec.settings.virtualMachineCIDRs` block must not overlap with subnets of nodes, subnet of services, and pods. -The `.spec.settings.dvcr` block describes the settings for the repository for storing virtual machine images, this block specifies the size of the storage provided for storing images `.spec.settings.dvcr.storage.persistentVolumeClaim.size`. The `.spec.settings.virtualMachineCIDRs` block specifies the list of subnets. Virtual machine addresses will be allocated automatically or on request from the specified subnet ranges in order. + It is forbidden to delete subnets if addresses from them have already been given to virtual machines. + {{< /alert >}} -You can track the readiness of the module using the following command: + To check if the module is ready, use the following command: -```bash -d8 k get modules virtualization -``` + ```bash + d8 k get modules virtualization + ``` -Example output: + Example output: -```txt -# NAME WEIGHT STATE SOURCE STAGE STATUS -# virtualization 900 Enabled Embedded Ready -``` + ```txt + NAME WEIGHT SOURCE PHASE ENABLED READY + virtualization 900 deckhouse Ready True True + ``` -The module status should be `Ready`. + The module phase should be `Ready`. -## Platform Update +## Module update -Deckhouse Virtualization Platform uses five update channels designed for use in different environments that have different requirements in terms of reliability: +The `virtualization` module uses five update channels designed for use in different environments that have different requirements in terms of reliability: | Update Channel | Description | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | @@ -204,15 +225,18 @@ Deckhouse Virtualization Platform uses five update channels designed for use in | Stable | Stable update channel for clusters where active work is finished and mostly operational. Functionality updates to this update channel do not reach this update channel until two weeks after they appear in the release. | | Rock Solid | The most stable update channel. Suitable for clusters that need a higher level of stability. Feature updates do not reach this channel until one month after they are released. | +The `virtualization` module components can be updated automatically or with manual confirmation, as updates are released in update channels. + {{< alert level="warning" >}} -In platform upgrades, the components can be divided into two categories: +When considering updates, the module components can be divided into two categories: -- Virtualization resource management components (control plane) +- Virtualization resource management components (control plane). - Virtualization resource management components ("firmware"). -Updating the control plane components does not affect the operation of virtual machines that are already running. However, changes to the "firmware" during a platform upgrade may require virtual machines to be migrated to the new "firmware" version. -{{< /alert >}} +Updating control plane components does not affect the operation of already running virtual machines, but may cause a brief interruption of established VNC/serial port connections while the control plane component is restarted. -Deckhouse Virtualization Platform components can be updated automatically, or with manual confirmation as updates are released in the update channels. +Updates to virtual machine firmware during a platform upgrade may require virtual machines to be migrated to the new "firmware" version. +Migration during the upgrade is performed once, if the migration was unsuccessful, the virtual machine owner will need to perform it themselves by either evict the virtual machine or reboot it. +{{< /alert >}} -For information on the versions available on the update channels, visit the site at https://releases.deckhouse.io/. +For information on versions available at the update channels, visit https://releases.deckhouse.io/. diff --git a/docs/INSTALL.ru.md b/docs/INSTALL.ru.md new file mode 100644 index 0000000000..fbbda419c0 --- /dev/null +++ b/docs/INSTALL.ru.md @@ -0,0 +1,247 @@ +--- +title: "Установка" +weight: 15 +--- + +{{< alert level="warning" >}} +Компоненты модуля необходимо развёртывать на физических серверах (bare-metal). + +Установка на виртуальные машины допустима только в демонстрационных целях, но при этом должна быть включена вложенная виртуализация (nested virtualization). Если модуль развёрнут на виртуальных машинах, техническая поддержка не предоставляется. +{{< /alert >}} + +## Возможности масштабирования + +Модуль поддерживает следующую конфигурацию: + +- максимальное количество узлов: `1000`; +- максимальное количество виртуальных машин: `50000`. + +Модуль не имеет дополнительных ограничений и совместим с любым оборудованием, которое поддерживается [операционными системами](#поддерживаемые-ос-для-узлов-платформы), на которые он может быть установлен. + +## Требования к аппаратному обеспечению + +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 | + +{{< alert level="warning" >}} +Обеспечение стабильной работы механизмов живой миграции требует использования идентичной версии ядра Linux на всех узлах кластера. + +Это связано с тем, что различия в версиях ядра могут привести к несовместимости интерфейсов, системных вызовов и особенностей работы с ресурсами, что может нарушить процесс миграции виртуальных машин. +{{< /alert >}} + +## Поддерживаемые гостевые ОС + +Модуль виртуализации поддерживает операционные системы, работающие на архитектурах `x86` и `x86-64`, в качестве гостевых ОС. Для корректной работы в режиме паравиртуализации необходимо установить драйверы `VirtIO`, обеспечивающие эффективное взаимодействие между виртуальной машиной и гипервизором. + +Успешный запуск операционной системы определяется следующими критериями: + +* корректная установка и загрузка ОС; +* бесперебойная работа основных компонентов, таких как сеть и хранилище; +* отсутствие сбоев или ошибок в процессе работы. + +Для операционных систем семейства Linux рекомендуется использовать образы гостевых ОС с поддержкой `cloud-init`, что позволяет выполнять инициализацию виртуальных машин после их создания. + +Для операционных систем семейства Windows платформа поддерживает инициализацию с помощью [autounattend](https://learn.microsoft.com/ru-ru/windows-hardware/manufacture/desktop/windows-setup-automation-overview) установки. + +## Поддерживаемые конфигурации виртуальных машин + +- Максимальное число поддерживаемых ядер: `248`. +- Максимальный объем оперативной памяти: `1024 ГБ`. + +## Поддерживаемые хранилища + +Виртуальные машины используют ресурсы `PersistentVolume`. Для управления этими ресурсами и выделения дискового пространства в кластере должно быть установлено одно или несколько поддерживаемых хранилищ: + +| Хранилище | Расположение дисков | +|--------------------------------------------|----------------------------| +| sds-local-volume | Локальное | +| sds-replicated-volume | Реплики на узлах кластера | +| Ceph-кластер | Внешнее хранилище | +| NFS (Network File System) | Внешнее хранилище | +| TATLIN.UNIFIED (Yadro) | Внешнее хранилище | +| Huawei Dorado | Внешнее хранилище | +| HPE 3par | Внешнее хранилище | + +## Порядок установки + +1. Разверните кластер Deckhouse Kubernetes Platform [по инструкции](https://deckhouse.ru/gs/). + +2. Для хранения данных виртуальных машин (виртуальные диски и образы) включите одно или несколько [поддерживаемых хранилищ](#поддерживаемые-хранилища). + +3. Установите `StorageClass` по умолчанию. + + ```shell + # Укажите имя своего объекта StorageClass. + DEFAULT_STORAGE_CLASS=replicated-storage-class + sudo -i d8 k patch mc global --type='json' -p='[{"op": "replace", "path": "/spec/settings/defaultClusterStorageClass", "value": "'"$DEFAULT_STORAGE_CLASS"'"}]' + ``` + +4. Включите модуль [`console`](https://deckhouse.ru/modules/console/stable/), который позволит управлять компонентами виртуализации через веб-интерфейс Deckhouse (данная возможность доступна только пользователям EE-редакции). + +5. Включите модуль `virtualization`: + + {{< alert level="warning" >}} + Включение модуля `virtualization` предполагает рестарт kubelet/containerd и агентов cilium на всех узлах, где предполагается запуск виртуальных машин. Это необходимо для настройки связности containerd и DVCR. + {{< /alert >}} + + Для включения модуля `virtualization` создайте ресурс ModuleConfig с настройками модуля. + + {{< alert level="info" >}} + Подробные настройки описаны в [Руководстве администратора](./admin_guide.html#параметры-модуля). + {{< /alert >}} + + Пример конфигурации модуля: + + ```yaml + d8 k apply -f - <}} + Подсети блока `.spec.settings.virtualMachineCIDRs` не должны пересекаться с подсетями узлов, подсетью сервисов и подов. + + Запрещено удалять подсети, если адреса из них уже выданы виртуальным машинам. + {{< /alert >}} + + Отследить готовность модуля можно с использованием следующей команды: + + ```bash + d8 k get modules virtualization + ``` + + Пример вывода: + + ```txt + NAME WEIGHT SOURCE PHASE ENABLED READY + virtualization 900 deckhouse Ready True True + ``` + + Фаза модуля должна быть `Ready`. + +## Обновление модуля + +Модуль `virtualization` использует пять каналов обновлений, предназначенных для использования в разных окружениях, к которым с точки зрения надежности применяются разные требования: + +| Канал обновлений | Описание | +| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Alpha | Наименее стабильный канал обновлений с наиболее частым появлением новых версий. Ориентирован на кластеры разработки с небольшим количеством разработчиков. | +| Beta | Ориентирован на кластеры разработки, как и канал обновлений Alpha. Получает версии, предварительно опробованные на канале обновлений Alpha. | +| Early Access | Рекомендуемый канал обновлений, если вы не уверены в выборе. Подойдет для кластеров, в которых идет активная работа (запускаются, дорабатываются новые приложения и т. п.). Обновления функционала до этого канала обновлений доходят не ранее чем через одну неделю после их появления в релизе. | +| Stable | Стабильный канал обновлений для кластеров, в которых закончена активная работа и преимущественно осуществляется эксплуатация. Обновления функционала до этого канала обновлений доходят не ранее чем через две недели после их появления в релизе. | +| Rock Solid | Наиболее стабильный канал обновлений. Подойдет для кластеров, которым необходимо обеспечить повышенный уровень стабильности. Обновления функционала до этого канала доходят не ранее чем через месяц после их появления в релизе. | + +Компоненты модуля `virtualization` могут обновляться автоматически, либо с ручным подтверждением по мере выхода обновлений в каналах обновления. + +{{< alert level="warning" >}} +При обновлении модуля компоненты можно разделить на две категории: + +- компоненты управления ресурсами виртуализации (управляющий слой); +- компоненты запуска виртуальных машин ("прошивка"). + +Обновление компонентов управляющего слоя не влияет на работу уже запущенных виртуальных машин, но может привести к кратковременному разрыву установленных соединений по VNC/последовательному порту на время рестарта компонента управляющего слоя. + +Обновления в прошивке виртуальных машин в процессе обновления платформы могут потребовать миграции виртуальных машин для перехода на новую версию "прошивки". +Миграция при обновлении осуществляется один раз. Если она проходит неуспешно, владельцу виртуальной машины потребуется выполнить её самостоятельно, выполнив evict, либо перезагрузку виртуальной машины. +{{< /alert >}} + +Информацию по версиям, доступным на каналах обновления, можно получить на сайте https://releases.deckhouse.ru/. diff --git a/docs/INSTALL_RU.md b/docs/INSTALL_RU.md deleted file mode 100644 index dfdf86a6f6..0000000000 --- a/docs/INSTALL_RU.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -title: "Установка" -weight: 15 ---- - -> **Внимание.** Компоненты платформы необходимо развертывать на физических серверах (bare-metal). -> -> Установка на виртуальные машины допустима только в демонстрационных целях, но при этом должна быть включена вложенная виртуализация (nested virtualization). Если платформа развернута на виртуальных машинах, техническая поддержка не предоставляется. - -## Возможности масштабирования платформы - -Платформа поддерживает следующую конфигурацию: - -- Максимальное количество узлов: 1000. -- Максимальное количество виртуальных машин: 50000. - -Платформа не имеет дополнительных ограничений и совместима с любым оборудованием, которое поддерживается [операционными системами](#поддерживаемые-ос-для-узлов-платформы), на которые она может быть установлена. - -## Требования к аппаратному обеспечению - -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 | - -## Поддерживаемые гостевые ОС - -Платформа виртуализации поддерживает операционные системы, работающие на архитектурах `x86` и `x86_64`, в качестве гостевых ОС. Для корректной работы в режиме паравиртуализации необходимо установить драйверы `VirtIO`, обеспечивающие эффективное взаимодействие между виртуальной машиной и гипервизором. - -Успешный запуск операционной системы определяется следующими критериями: - - * корректная установка и загрузка ОС; - * бесперебойная работа основных компонентов, таких как сеть и хранилище; - * отсутствие сбоев или ошибок в процессе работы. - -Для операционных систем семейства Linux рекомендуется использовать образы гостевых ОС с поддержкой `cloud-init`, что позволяет выполнять инициализацию виртуальных машин после их создания. - -Для операционных систем семейства Windows платформа поддерживает инициализацию с помощью встроенной утилиты sysprep. - -## Поддерживаемые конфигурации виртуальных машин - -Максимальное число поддерживаемых ядер: `254` -Максимальный объем оперативной памяти: `1024 Гб` - -## Поддерживаемые хранилища - -Виртуальные машины используют ресурсы `PersistentVolume`. Для управления этими ресурсами и выделения дискового пространства в кластере должно быть установлено одно или несколько поддерживаемых хранилищ: - -| Хранилище | Расположение дисков | -|--------------------------------------------|----------------------------| -| LVM (Logical Volume Manager) | Локальное | -| DRBD (Distributed Replicated Block Device) | Реплики на узлах кластера | -| Ceph-кластер | Внешнее хранилище | -| NFS (Network File System) | Внешнее хранилище | -| TATLIN.UNIFIED (Yadro) | Внешнее хранилище | - -## Порядок установки - -1. Разверните кластер Deckhouse Kubernetes Platform [по инструкции](https://deckhouse.ru/gs/). - -2. Для хранения данных виртуальных машин (виртуальные диски и образы) необходимо включить один или несколько поддерживаемых [хранилищ](#поддерживаемые-хранилища). - -3. Установите `StorageClass` по умолчанию. - - ```shell - # Укажите имя своего объекта StorageClass. - DEFAULT_STORAGE_CLASS=replicated-storage-class - sudo -i d8 k patch mc global --type='json' -p='[{"op": "replace", "path": "/spec/settings/defaultClusterStorageClass", "value": "'"$DEFAULT_STORAGE_CLASS"'"}]' - ``` - -4. Включите модуль [console](https://deckhouse.ru/modules/console/stable/), который позволит управлять компонентами виртуализации через графический интерфейс (данная возможность доступна только пользователям EE-редакции). - -5. Включите модуль `virtualization`: - -{{< alert level="warning" >}} -Внимание! Включение модуля `virtualization` предполагает рестарт kubelet/containerd на всех узлах, где предполагается запуск виртуальных машин. Это необходимо для настройки связности containerd и DVCR. -{{< /alert >}} - -Для включения модуля `virtualization`, необходимо создать ресурс `ModuleConfig` содержащий настройки модуля. - -{{< alert level="info" >}} -Полный перечень параметров конфигурации приведен в разделе [Настройки](./configuration.html) -{{< /alert >}} - -Пример конфигурации модуля: - -```yaml -d8 k apply -f - <}} -При обновлении платформы компоненты можно разделить на две категории: - -- Компоненты управления ресурсами виртуализации (плоскость управления) -- Компоненты запуска виртуальных машин ("прошивка") - -Обновление компонентов плоскости управления не влияет на работу уже запущенных виртуальных машин. Однако изменения в "прошивке" во время обновления платформы могут потребовать миграции виртуальных машин для перехода на новую версию "прошивки". -{{< /alert >}} - -Информацию по версиям, доступных на каналах обновления, можно получить на сайте https://releases.deckhouse.ru/ diff --git a/docs/README.md b/docs/README.md index dc90555f0d..620c1a1919 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,35 +1,41 @@ --- -title: "Deckhouse Virtualization Platform" -menuTitle: "Deckhouse Virtualization Platform" +title: "Virtualization" +menuTitle: "Virtualization" moduleStatus: preview weight: 10 --- ## Description -Deckhouse Virtualization Platform (DVP) allows you to declaratively create, run, and manage virtual machines and their resources. -DVP is powered by [Deckhouse Kubernetes Platform](https://deckhouse.io/products/kubernetes-platform/). The [d8](https://deckhouse.io/documentation/v1/deckhouse-cli/) command line utility is used to manage DKP/DVP resources. +The `virtualization` module allows you to declaratively create, start, and manage virtual machines and associated resources. -Scenarios of using the module: +The command line utility [`d8`](https://deckhouse.ru/documentation/v1/deckhouse-cli/) is used to manage cluster resources. + +## Usage scenarios + +- Running virtual machines with an x86-64-compatible OS. + + ![](./images/cases-vms.png) -- Running virtual machines with x86_64 compatible OS. - Running virtual machines and containerized applications in the same environment. -![](./images/cases-vms.png) + ![](./images/cases-pods-and-vms.png) + +- Creation of DKP clusters. -![](./images/cases-pods-and-vms.png) + ![](./images/cases.dkp.png) {{< alert level="info" >}} -If you plan to use Deckhouse Virtualization Platform in a production environment, it is recommended to deploy it on physical servers. Deploying Deckhouse Virtualization Platform on virtual machines is also possible, but in this case you must enable nested virtualization. +If you plan to use `virtualization` in a production environment, it is recommended to use a cluster deployed on physical (bare-metal) servers. For testing purposes, it is allowed to use the module in a cluster deployed on virtual machines but with nested virtualization enabled on them. {{< /alert >}} ## Architecture -The platform includes the following components: +The module includes the following components: -- The platform core (CORE) is based on the KubeVirt project and uses QEMU/KVM + libvirtd to run virtual machines. -- Deckhouse Virtualization Container Registry (DVCR) - repository for storing and caching virtual machine images. -- Virtualization API (API) - A controller that implements a user API for creating and managing virtual machine resources. +- A module core (CORE) that is based on the KubeVirt project and uses QEMU/KVM + libvirtd to run virtual machines. +- Deckhouse Virtualization Container Registry (DVCR), a repository for storing and caching virtual machine images. +- Virtualization API (API), a controller that implements a user API for creating and managing virtual machine resources. ![](images/arch.png) @@ -46,8 +52,8 @@ List of controllers and operators deployed in the `d8-virtualization` namespace | `virt-exportproxy-*` | CORE | Virtualization core component for disk and image management. | | `virt-handler-*` | CORE | Virtualization core component for disk and image management. Must be present on all cluster nodes where VMs will be started. | | `virt-operator-*` | CORE | Virtualization core component for disk and image management. | -| `virtualization-api-*` | API | API for creating and managing module resources (images, disks, VMs, ...) | -| `virtualization-controller-*` | API | API for creating and managing module resources (images, disks, VMs, ...) | +| `virtualization-api-*` | API | API for creating and managing module resources (images, disks, VMs, etc.). | +| `virtualization-controller-*` | API | API for creating and managing module resources (images, disks, VMs, etc.). | | `vm-route-forge-*` | CORE | Router for configuring routes to VMs. Must be present on all cluster nodes where VMs will be started. | The virtual machine runs inside the pod, which allows you to manage virtual machines as regular Kubernetes resources and utilize all the platform features, including load balancers, network policies, automation tools, etc. @@ -56,6 +62,6 @@ The virtual machine runs inside the pod, which allows you to manage virtual mach The API provides the ability to declaratively create, modify, and delete the following underlying resources: -- virtual machine images and boot images; -- virtual machine disks; -- virtual machines; +- Virtual machine images and boot images. +- Virtual machine disks. +- Virtual machines. diff --git a/docs/README_RU.md b/docs/README.ru.md similarity index 71% rename from docs/README_RU.md rename to docs/README.ru.md index b9f4418c77..22ecea5d32 100644 --- a/docs/README_RU.md +++ b/docs/README.ru.md @@ -1,37 +1,43 @@ --- -title: "Deckhouse Virtualization Platform" -menuTitle: "Deckhouse Virtualization Platform" +title: "Виртуализация" +menuTitle: "Виртуализация" moduleStatus: preview weight: 10 --- -Deckhouse Virtualization Platform (DVP) позволяет декларативно создавать, запускать и управлять виртуальными машинами и их ресурсами. -DVP функционирует на базе [Deckhouse Kubernetes Platform](https://deckhouse.ru/products/kubernetes-platform/). Для управления ресурсами DKP/DVP используется утилита командной строки [d8](https://deckhouse.ru/documentation/v1/deckhouse-cli/). +Модуль `virtualization` позволяет декларативно создавать, запускать и управлять виртуальными машинами и их ресурсами. + +Для управления ресурсами кластера используется утилита командной строки [`d8`](https://deckhouse.ru/documentation/v1/deckhouse-cli/). ## Сценарии использования -- Запуск виртуальных машин с x86_64 совместимой ОС. -- Запуск виртуальных машин и контейнеризованных приложений в одном окружении. +- Запуск виртуальных машин с x86-64-совместимой ОС. ![](./images/cases-vms.ru.png) +- Запуск виртуальных машин и контейнеризованных приложений в одном окружении. + ![](./images/cases-pods-and-vms.ru.png) +- Создание кластеров DKP. + + ![](./images/cases.dkp.ru.png) + {{< alert level="warning" >}} -Если вы планируете использовать Deckhouse Virtualization Platform в production-среде, рекомендуется разворачивать её на физических серверах. Развертывание Deckhouse Virtualization Platform на виртуальных машинах также возможно, но в этом случае необходимо включить nested-виртуализацию. +Если вы планируете использовать `virtualization` в production-среде, рекомендуется использовать кластер, развёрнутый на физических (bare-metal) серверах. Допускается в целях тестирования использовать модуль в кластере, развёрнутом на виртуальных машинах, но при этом на них должна быть включена вложенная виртуализация (nested virtualization). {{< /alert >}} ## Архитектура -Платформа включает в себя следующие компоненты: +Модуль включает в себя следующие компоненты: -- Ядро платформы (CORE) — основано на проекте KubeVirt и использует QEMU/KVM + libvirtd для запуска виртуальных машин. -- Deckhouse Virtualization Container Registry (DVCR) — репозиторий для хранения и кэширования образов виртуальных машин. +- ядро модуля (CORE) — основано на проекте KubeVirt и использует QEMU/KVM + libvirtd для запуска виртуальных машин; +- Deckhouse Virtualization Container Registry (DVCR) — репозиторий для хранения и кэширования образов виртуальных машин; - Virtualization API (API) — контроллер, реализующий API пользователя для создания и управления ресурсами виртуальных машин. ![](images/arch.ru.png) -Перечень контроллеров и операторов, разворачивающихся в пространстве имен `d8-virtualization` после включения модуля: +Перечень контроллеров и операторов, которые развёртываются в пространстве имён `d8-virtualization` после включения модуля: | Название | Компонент | Комментарий | | ----------------------------- | --------- |-----------------------------------------------------------------------------------------------------------------------------------------| @@ -44,8 +50,8 @@ DVP функционирует на базе [Deckhouse Kubernetes Platform](htt | `virt-exportproxy-*` | CORE | Компонент ядра виртуализации для управления дисками и образами. | | `virt-handler-*` | CORE | Компонент ядра виртуализации для управления дисками и образами. Должен присутствовать на всех узлах кластера, где будут запускаться ВМ. | | `virt-operator-*` | CORE | Компонент ядра виртуализации для управления дисками и образами. | -| `virtualization-api-*` | API | API для создания и управления ресурсами модуля (образы, диски, ВМ и т.д.) | -| `virtualization-controller-*` | API | API для создания и управления ресурсами модуля (образы, диски, ВМ и т.д.) | +| `virtualization-api-*` | API | API для создания и управления ресурсами модуля (образы, диски, ВМ и т. д.) | +| `virtualization-controller-*` | API | API для создания и управления ресурсами модуля (образы, диски, ВМ и т. д.) | | `vm-route-forge-*` | CORE | Маршрутизатор для настройки маршрутов до ВМ. Должен присутствовать на всех узлах кластера, где будут запускаться ВМ. | Виртуальная машина запускается внутри пода, что позволяет управлять виртуальными машинами как обычными ресурсами Kubernetes и использовать все возможности платформы, включая балансировщики нагрузки, сетевые политики, средства автоматизации и т. д. diff --git a/docs/USER_GUIDE.md b/docs/USER_GUIDE.md index 5133113a61..82d4ab5f59 100644 --- a/docs/USER_GUIDE.md +++ b/docs/USER_GUIDE.md @@ -25,7 +25,7 @@ Example of creating a virtual machine with Ubuntu 22.04. dataSource: type: HTTP http: - url: "https://cloud-images.ubuntu.com/minimal/releases/jammy/release/ubuntu-22.04-minimal-cloudimg-amd64.img" + url: https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img EOF ``` @@ -107,14 +107,14 @@ Example of creating a virtual machine with Ubuntu 22.04. Example output: ```txt - # NAME PHASE CDROM PROGRESS AGE - # virtualimage.virtualization.deckhouse.io/ubuntu Ready false 100% + NAME PHASE CDROM PROGRESS AGE + virtualimage.virtualization.deckhouse.io/ubuntu Ready false 100% # - # NAME PHASE CAPACITY AGE - # virtualdisk.virtualization.deckhouse.io/linux-disk Ready 300Mi 7h40m + NAME PHASE CAPACITY AGE + virtualdisk.virtualization.deckhouse.io/linux-disk Ready 300Mi 7h40m # - # NAME PHASE NODE IPADDRESS AGE - # virtualmachine.virtualization.deckhouse.io/linux-vm Running virtlab-pt-2 10.66.10.2 7h46m + NAME PHASE NODE IPADDRESS AGE + virtualmachine.virtualization.deckhouse.io/linux-vm Running virtlab-pt-2 10.66.10.2 7h46m ``` 1. Connect to the virtual machine using the console (press `Ctrl+]` to exit the console): @@ -126,12 +126,12 @@ Example of creating a virtual machine with Ubuntu 22.04. Example output: ```txt - # Successfully connected to linux-vm console. The escape sequence is ^] + Successfully connected to linux-vm console. The escape sequence is ^] # - # linux-vm login: cloud - # Password: cloud - # ... - # cloud@linux-vm:~$ + linux-vm login: cloud + Password: cloud + ... + cloud@linux-vm:~$ ``` 1. Use the following commands to delete previously created resources: @@ -146,6 +146,8 @@ Example of creating a virtual machine with Ubuntu 22.04. The `VirtualImage` resource is designed to load virtual machine images and then use them to create virtual machine disks. This resource is available only in the nymspace or project in which it was created. +When connected to a virtual machine, the image is accessed in read-only mode. + The image creation process includes the following steps: - The user creates a `VirtualImage` resource. @@ -154,10 +156,39 @@ The image creation process includes the following steps: There are different types of images: -- ISO image - an installation image used for the initial installation of an operating system. Such images are released by OS vendors and are used for installation on physical and virtual servers. -- Preinstalled disk image - contains an already installed and configured operating system ready for use after the virtual machine is created. These images are offered by several vendors and can be provided in formats such as qcow2, raw, vmdk, and others. - -Example of resource for obtaining virtual machine images [Ubuntu](https://cloud-images.ubuntu.com) +- **ISO image**: an installation image used for the initial installation of an operating system. Such images are released by OS vendors and are used for installation on physical and virtual servers. +- **Preinstalled disk image**: contains an already installed and configured operating system ready for use after the virtual machine is created. Ready images can be obtained from the distribution developers' resources or created by yourself. + +Examples of resources for obtaining virtual machine images: + +- Ubuntu + - [24.04 LTS (Noble Numbat)](https://cloud-images.ubuntu.com/noble/current/) + - [22.04 LTS (Jammy Jellyfish)](https://cloud-images.ubuntu.com/jammy/current/) + - [20.04 LTS (Focal Fossa)](https://cloud-images.ubuntu.com/focal/current/) + - [Minimal images](https://cloud-images.ubuntu.com/minimal/releases/) +- Debian + - [12 bookworm](https://cdimage.debian.org/images/cloud/bookworm/latest/) + - [11 bullseye](https://cdimage.debian.org/images/cloud/bullseye/latest/) +- AlmaLinux + - [9](https://repo.almalinux.org/almalinux/9/cloud/x86_64/images/) + - [8](https://repo.almalinux.org/almalinux/8/cloud/x86_64/images/) +- RockyLinux + - [9.5](https://download.rockylinux.org/pub/rocky/9.5/images/x86_64/) + - [8.10](https://download.rockylinux.org/pub/rocky/8.10/images/x86_64/) +- CentOS + - [10 Stream](https://cloud.centos.org/centos/10-stream/x86_64/images/) + - [9 Stream](https://cloud.centos.org/centos/9-stream/x86_64/images/) + - [8 Stream](https://cloud.centos.org/centos/8-stream/x86_64/) + - [8](https://cloud.centos.org/centos/8/x86_64/images/) + +The following preinstalled image formats are supported: + +- qcow2 +- raw +- vmdk +- vdi + +Image files can also be compressed with one of the following compression algorithms: gz, xz. Once a share is created, the image type and size are automatically determined, and this information is reflected in the share status. @@ -181,7 +212,7 @@ d8 k apply -f - < -o json | jq '.status.conditions[] | select(.type | test(".*Ready"))' + ``` + +- `Starting` - starting the virtual machine + + All dependent VM resources are ready and the system is attempting to start the VM on one of the cluster nodes. + - Possible problems: + - There is no suitable node to start. + - There is not enough CPU or memory on suitable nodes. + - Neumspace or project quotas have been exceeded. + - Diagnostics: + - If the startup is delayed, check `.status.conditions`, the `type: Running` condition + + ``` bash + d8 k get vm -o json | jq '.status.conditions[] | select(.type=="Running")' + ``` + +- `Running` - the virtual machine is running + + The VM is successfully started and running. + - Features: + - When qemu-guest-agent is installed in the guest system, the `AgentReady` condition will be true and `.status.guestOSInfo` will display information about the running guest OS. + - The `type: FirmwareUpToDate, status: False` condition informs that the VM firmware needs to be updated. + - Condition `type: ConfigurationApplied, status: False` informs that the VM configuration is not applied to the running VM. + - The `type: AwaitingRestartToApplyConfiguration, status: True` condition displays information about the need to manually reboot the VM because some configuration changes cannot be applied without rebooting the VM. + - Possible problems: + - An internal failure in the VM or hypervisor. + - Diagnosis: + - Check `.status.conditions`, condition `type: Running`. + + ``` bash + d8 k get vm -o json | jq '.status.conditions[] | select(.type=="Running")' + ``` + +- `Stopping` - The VM is stopped or rebooted. + +- `Stopped` - The VM is stopped and is not consuming computational resources + +- `Terminating` - the VM is deleted. + + This phase is irreversible. All resources associated with the VM are released, but are not automatically deleted. + +- `Migrating` - live migration of a VM + + The VM is migrated to another node in the cluster (live migration). + - Features: + - VM migration is supported only for non-local disks, the `type: Migratable` condition displays information about whether the VM can migrate or not. + - Possible issues: + - Incompatibility of processor instructions (when using host or host-passthrough processor types). + - Difference in kernel versions on hypervisor nodes. + - Not enough CPU or memory on eligible nodes. + - Neumspace or project quotas have been exceeded. + - Diagnostics: + - Check the `.status.conditions` condition `type: Migrating` as well as the `.status.migrationState` block + + ```bash + d8 k get vm -o json | jq '.status | {condition: .conditions[] | select(.type=="Migrating"), migrationState}' + ``` + +The `type: SizingPolicyMatched, status: False` condition indicates that the resource configuration does not comply with the sizing policy of the VirtualMachineClass being used. If the policy is violated, it is impossible to save VM parameters without making the resources conform to the policy. + +Conditions display information about the state of the VM, as well as on problems that arise. You can understand what is wrong with the VM by analyzing them: + +```bash +d8 k get vm fedora -o json | jq '.status.conditions[] | select(.message != "")' +``` + +### Guest OS Agent + +To improve VM management efficiency, it is recommended to install the QEMU Guest Agent, a tool that enables communication between the hypervisor and the operating system inside the VM. + +How will the agent help? + +- It will provide consistent snapshots of disks and VMs. +- Will provide information about the running OS, which will be reflected in the status of the VM. + Example: -The number of sockets is calculated automatically and depends on the number of cores. + ```yaml + status: + guestOSInfo: + id: fedora + kernelRelease: 6.11.4-301.fc41.x86_64 + kernelVersion: '#1 SMP PREEMPT_DYNAMIC Sun Oct 20 15:02:33 UTC 2024' + machine: x86_64 + name: Fedora Linux + prettyName: Fedora Linux 41 (Cloud Edition) + version: 41 (Cloud Edition) + versionId: “41” + ``` -For .spec.cpu.cores <= 16: +- Will allow tracking that the OS has actually booted: -- One socket is created with the number of cores equal to the specified value. -- Core increment step: 1 -- Allowed values: any number from 1 to 16 inclusive. + ```bash + d8 k get vm -o wide + ``` -For 16 < .spec.cpu.cores <= 32: + Sample output (`AGENT` column): + ```console + NAME PHASE CORES COREFRACTION MEMORY NEED RESTART AGENT MIGRATABLE NODE IPADDRESS AGE + fedora Running 6 5% 8000Mi False True True virtlab-pt-1 10.66.10.1 5d21h + ``` -- Two sockets are created with the same number of cores in each. -- Core increment step: 2 -- Allowed values: 18, 20, 22, ..., 32. -- Minimum cores per socket: 9 -- Maximum cores per socket: 16 +How to install QEMU Guest Agent: -For 32 < .spec.cpu.cores <= 64: +For Debian-based OS: -- Four sockets are created with the same number of cores in each. -- Core increment step: 4 -- Allowed values: 36, 40, 44, ..., 64. -- Minimum cores per socket: 9 -- Maximum cores per socket: 16 +```bash +sudo apt install qemu-guest-agent +``` + +For Centos-based OS: + +```bash +sudo yum install qemu-guest-agent +``` + +Starting the agent service: + +```bash +sudo systemctl enable --now qemu-guest-agent +``` -For .spec.cpu.cores > 64: +### Automatic CPU Topology Configuration -- Eight sockets are created with the same number of cores in each. -- Core increment step: 8 -- Allowed values: 72, 80, ... -- Minimum cores per socket: 8 +The CPU topology of a virtual machine (VM) determines how the CPU cores are allocated across sockets. This is important to ensure optimal performance and compatibility with applications that may depend on the CPU configuration. In the VM configuration, you specify only the total number of processor cores, and the topology (the number of sockets and cores in each socket) is automatically calculated based on this value. -The current VM topology (actual number of sockets and cores) is displayed in the VM status in the following format: +The number of processor cores is specified in the VM configuration as follows: + +```yaml +spec: + cpu: + cores: 1 +``` + + +Next, the system automatically determines the topology depending on the specified number of cores. The calculation rules depend on the range of the number of cores and are described below. + +- If the number of cores is between 1 and 16 (1 ≤ `.spec.cpu.cores` ≤ 16): + - 1 socket is used. + - The number of cores in the socket is equal to the specified value. + - Change step: 1 (you can increase or decrease the number of cores one at a time). + - Valid values: any integer from 1 to 16 inclusive. + - Example: If `.spec.cpu.cores` = 8, topology: 1 socket with 8 cores. +- If the number of cores is from 17 to 32 (16 < `.spec.cpu.cores` ≤ 32): + - 2 sockets are used. + - Cores are evenly distributed between sockets (the number of cores in each socket is the same). + - Change step: 2 (total number of cores must be even). + - Allowed values: 18, 20, 22, 24, 26, 28, 30, 32. + - Limitations: minimum 9 cores per socket, maximum 16 cores per socket. + - Example: If `.spec.cpu.cores` = 20, topology: 2 sockets with 10 cores each. +- If the number of cores is between 33 and 64 (32 < `.spec.cpu.cores` ≤ 64): + - 4 sockets are used. + - Cores are evenly distributed among the sockets. + - Step change: 4 (the total number of cores must be a multiple of 4). + - Allowed values: 36, 40, 44, 48, 52, 56, 60, 64. + - Limitations: minimum 9 cores per socket, maximum 16 cores per socket. + - Example: If `.spec.cpu.cores` = 40, topology: 4 sockets with 10 cores each. +- If the number of cores is greater than 64 (`.spec.cpu.cores` > 64): + - 8 sockets are used. + - Cores are evenly distributed among the sockets. + - Step change: 8 (the total number of cores must be a multiple of 8). + - Valid values: 72, 80, 88, 88, 96, and so on up to 248 + - Limitations: minimum 9 cores per socket. + - Example: If `.spec.cpu.cores` = 80, topology: 8 sockets with 10 cores each. + +The change step indicates by how much the total number of cores can be increased or decreased so that they are evenly distributed across the sockets. + +The maximum possible number of cores is 248. + +The current VM topology (number of sockets and cores in each socket) is displayed in the VM status in the following format: ```yaml status: resources: cpu: - coreFraction: 100% - cores: 18 - requestedCores: "18" + coreFraction: 10% + cores: 1 + requestedCores: "1" runtimeOverhead: "0" topology: - sockets: 2 - coresPerSocket: 9 + sockets: 1 + coresPerSocket: 1 ``` ### Connecting to a virtual machine @@ -807,10 +984,10 @@ d8 v console linux-vm Example output: ```txt -# Successfully connected to linux-vm console. The escape sequence is ^] +Successfully connected to linux-vm console. The escape sequence is ^] # -# linux-vm login: cloud -# Password: cloud +linux-vm login: cloud +Password: cloud ``` Press `Ctrl+]` to finalize the serial console. @@ -894,15 +1071,15 @@ If the virtual machine is in a shutdown state (`.status.phase: Stopped`), the ch If the virtual machine is running (`.status.phase: Running`), the way the changes are applied depends on the type of change: -| Configuration block | How changes are applied | -| --------------------------------------- | -------------------------------------------------- | -| `.metadata.labels` | Applies immediately | -| `.metadata.annotations` | Applies immediately | -| `.spec.runPolicy` | Applies immediately | -| `.spec.disruptions.restartApprovalMode` | Applies immediately | -| `.spec.affinity` | EE: Applies immediately, CE: Only after VM restart | -| `.spec.nodeSelector` | EE: Applies immediately, CE: Only after VM restart | -| `.spec.*` | Only after VM restart | +| Configuration block | How changes are applied | +| --------------------------------------- | --------------------------------------------------------| +| `.metadata.annotations` | Applies immediately | +| `.spec.liveMigrationPolicy` | Applies immediately | +| `.spec.runPolicy` | Applies immediately | +| `.spec.disruptions.restartApprovalMode` | Applies immediately | +| `.spec.affinity` | EE, SE+: Applies immediately, CE: Only after VM restart | +| `.spec.nodeSelector` | EE, SE+: Applies immediately, CE: Only after VM restart | +| `.spec.*` | Only after VM restart | Let's consider an example of changing the configuration of a virtual machine: @@ -915,7 +1092,7 @@ d8 v ssh cloud@linux-vm --local-ssh --command "nproc" Example output: ```txt -# 1 +1 ``` Apply the following patch to the virtual machine to change the number of cores from 1 to 2. @@ -939,7 +1116,7 @@ d8 v ssh cloud@linux-vm --local-ssh --command "nproc" Example output: ```txt -# 1 +1 ``` A restart of the virtual machine is required to apply this change. Run the following command to see the changes waiting to be applied (requiring a restart): @@ -950,15 +1127,15 @@ d8 k get vm linux-vm -o jsonpath="{.status.restartAwaitingChanges}" | jq . Example output: -```txt -# [ -# { -# "currentValue": 1, -# "desiredValue": 2, -# "operation": "replace", -# "path": "cpu.cores" -# } -# ] +```json +[ + { + "currentValue": 1, + "desiredValue": 2, + "operation": "replace", + "path": "cpu.cores" + } +] ``` Run the command: @@ -970,8 +1147,8 @@ d8 k get vm linux-vm -o wide Example output: ```txt -# NAME PHASE CORES COREFRACTION MEMORY NEED RESTART AGENT MIGRATABLE NODE IPADDRESS AGE -# linux-vm Running 2 100% 1Gi True True True virtlab-pt-1 10.66.10.13 5m16s +NAME PHASE CORES COREFRACTION MEMORY NEED RESTART AGENT MIGRATABLE NODE IPADDRESS AGE +linux-vm Running 2 100% 1Gi True True True virtlab-pt-1 10.66.10.13 5m16s ``` In the `NEED RESTART` column we see the value `True`, which means that a reboot is required to apply the changes. @@ -993,10 +1170,10 @@ d8 v ssh cloud@linux-vm --local-ssh --command "nproc" Example output: ```txt -# 2 +2 ``` -The default behavior is to apply changes to the virtual machine through a “manual” restart. If you want to apply the changes immediately and automatically, you need to change the change application policy: +The default behavior is to apply changes to the virtual machine through a "manual" restart. If you want to apply the changes immediately and automatically, you need to change the change application policy: ```yaml spec: @@ -1229,6 +1406,8 @@ After creation, `VirtualMachineBlockDeviceAttachment` can be in the following st - `InProgress` - the process of device connection is in progress. - `Attached` - the device is connected. +Diagnosing problems with a resource is done by analyzing the information in the `.status.conditions` block + Check the state of your resource:: ```bash @@ -1238,8 +1417,8 @@ d8 k get vmbda attach-blank-disk Example output: ```txt -# NAME PHASE VIRTUAL MACHINE NAME AGE -# attach-blank-disk Attached linux-vm 3m7s +NAME PHASE VIRTUAL MACHINE NAME AGE +attach-blank-disk Attached linux-vm 3m7s ``` Connect to the virtual machine and make sure the disk is connected: @@ -1251,13 +1430,13 @@ d8 v ssh cloud@linux-vm --local-ssh --command "lsblk" Example output: ```txt -# NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS -# sda 8:0 0 10G 0 disk <--- statically mounted linux-vm-root disk -# |-sda1 8:1 0 9.9G 0 part / -# |-sda14 8:14 0 4M 0 part -# `-sda15 8:15 0 106M 0 part /boot/efi -# sdb 8:16 0 1M 0 disk <--- cloudinit -# sdc 8:32 0 95.9M 0 disk <--- dynamically mounted disk blank-disk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS +sda 8:0 0 10G 0 disk <--- statically mounted linux-vm-root disk +|-sda1 8:1 0 9.9G 0 part / +|-sda14 8:14 0 4M 0 part +`-sda15 8:15 0 106M 0 part /boot/efi +sdb 8:16 0 1M 0 disk <--- cloudinit +sdc 8:32 0 95.9M 0 disk <--- dynamically mounted disk blank-disk ``` To detach the disk from the virtual machine, delete the previously created resource: @@ -1279,7 +1458,7 @@ d8 k label vm linux-vm app=nginx Example output: ```txt -# virtualmachine.virtualization.deckhouse.io/linux-vm labeled +virtualmachine.virtualization.deckhouse.io/linux-vm labeled ``` Attaching images is done by analogy. To do this, specify `VirtualImage` or `ClusterVirtualImage` and the image name as `kind`: @@ -1403,18 +1582,92 @@ EOF ### Live Virtual Machine Migration -Virtual machine migration is an important feature in managing virtualized infrastructure. It allows you to move running virtual machines from one physical host to another without shutting them down. +Live virtual machine (VM) migration is the process of moving a running VM from one physical host to another without shutting it down. This feature plays a key role in the management of virtualized infrastructure, ensuring application continuity during maintenance, load balancing, or upgrades. + +#### How live migration works + +The live migration process involves several steps: + +1. **Creation of a new VM instance** + + A new VM is created on the target host in a suspended state. Its configuration (CPU, disks, network) is copied from the source node. + +2. **Primary Memory Transfer** + + The entire RAM of the VM is copied to the target node over the network. This is called primary transfer. + +3. **Change Tracking (Dirty Pages)** + + While memory is being transferred, the VM continues to run on the source node and may change some memory pages. These pages are called dirty pages and the hypervisor marks them. + +4. **Iterative synchronization**. + + After the initial transfer, only the modified pages are resent. This process is repeated in several cycles: + - The higher the load on the VM, the more "dirty" pages appear, and the longer the migration takes. + - With good network bandwidth, the amount of unsynchronized data gradually decreases. + +5. **Final synchronization and switching**. + + When the number of dirty pages becomes minimal, the VM on the source node is suspended (typically for 100 milliseconds): + - The remaining memory changes are transferred to the target node. + - The state of the CPU, devices, and open connections are synchronized. + - The VM is started on the new node and the source copy is deleted. + +![](./images/migration.png) + +{{< alert level="warning">}} +Network speed plays an important role. If bandwidth is low, there are more iterations and VM downtime can increase. In the worst case, the migration may not complete at all. +{{{< /alert >}} -Migration can be performed automatically when: -- Updating the “firmware” of a virtual machine. -- Rebalancing the load on the cluster nodes. -- Transferring nodes to maintenance mode for work. -- When you change [VM placement settings](#placement-of-vms-by-nodes) (available in Enterprise edition only). +#### Migration Types -Virtual machine migration can also be performed at the user's request. Let's take an example: +Migration can be performed manually by the user, or automatically by the following system events: + +- Updating the "firmware" of a virtual machine. +- Redistribution of load in the cluster. +- Transferring a node into maintenance mode (Node drain). +- When you change [VM placement settings](#placement-of-vms-by-nodes) (not available in Community edition). + +The trigger for live migration is the appearance of the `VirtualMachineOperations` resource with the `Evict` type. + +The table shows the `VirtualMachineOperations` resource name prefixes with the `Evict` type that are created for live migrations caused by system events: + +| Type of system event | Resource name prefix | +|----------------------------------|------------------------| +| Firmware-update-* | firmware-update-* | +| Load shifting | evacuation-* | +| Drain node | evacuation-* | +| Modify placement parameters | nodeplacement-update-* | + +This resource can be in the following states: + +- `Pending` - the operation is pending. +- `InProgress` - live migration is in progress. +- `Completed` - live migration of the virtual machine has been completed successfully. +- `Failed` - the live migration of the virtual machine has failed. + +Diagnosing problems with a resource is done by analyzing the information in the `.status.conditions` block. + +You can view active operations using the command: + +```bash +d8 k get vmop +``` + +Example output: + +```txt +NAME PHASE TYPE VIRTUALMACHINE AGE +firmware-update-fnbk2 Completed Evict static-vm-node-00 148m +``` + +You can interrupt any live migration while it is in the `Pending`, `InProgress` phase by deleting the corresponding `VirtualMachineOperations` resource. + +#### How to perform a live migration of a virtual machine using `VirtualMachineOperations`. + +Let's look at an example. Before starting the migration, view the current status of the virtual machine: -Before starting the migration, view the current status of the virtual machine:: ```bash d8 k get vm @@ -1423,13 +1676,22 @@ d8 k get vm Example output: ```txt -# NAME PHASE NODE IPADDRESS AGE -# linux-vm Running virtlab-pt-1 10.66.10.14 79m +NAME PHASE NODE IPADDRESS AGE +linux-vm Running virtlab-pt-1 10.66.10.14 79m ``` We can see that it is currently running on the `virtlab-pt-1` node. -To migrate a virtual machine from one node to another, taking into account the requirements for virtual machine placement, the `VirtualMachineOperations` (`vmop`) resource with the `Evict` type is used. +To migrate a virtual machine from one host to another, taking into account the virtual machine placement requirements, the command is used: + +```bash +d8 v evict -n +``` + +execution of this command leads to the creation of the `VirtualMachineOperations` resource. + +You can also start the migration by creating a `VirtualMachineOperations` (`vmop`) resource with the `Evict` type manually: + ```yaml d8 k create -f - < +Let's consider the migration mechanism on the example of a cluster with two node groups (`NodeGroups`): green and blue. Suppose a virtual machine (VM) is initially running on a node in the green group and its configuration contains no placement restrictions. + +Step 1: Add the placement parameter +Let's specify in the VM specification the requirement for placement in the green group : + +```yaml +spec: + nodeSelector: + node.deckhouse.io/group: green +``` + +After saving the changes, the VM will continue to run on the current node, since the `nodeSelector` condition is already met. + +Step 2: Change the placement parameter +Let's change the placement requirement to group blue : + +```yaml +spec: + nodeSelector: + node.deckhouse.io/group: blue ``` +Now the current node (groups green) does not match the new conditions. The system will automatically create a `VirtualMachineOperations` object of type Evict, which will initiate a live migration of the VM to an available node in group blue . + + ## IP addresses of virtual machines The `.spec.settings.virtualMachineCIDRs` block in the virtualization module configuration specifies a list of subnets to assign ip addresses to virtual machines (a shared pool of ip addresses). All addresses in these subnets are available for use except the first (network address) and the last (broadcast address). @@ -1482,8 +1765,8 @@ d8 k get vmipl Example output: ```txt -# NAME VIRTUALMACHINEIPADDRESS STATUS AGE -# ip-10-66-10-14 {"name":"linux-vm-7prpx","namespace":"default"} Bound 12h +NAME VIRTUALMACHINEIPADDRESS STATUS AGE +ip-10-66-10-14 {"name":"linux-vm-7prpx","namespace":"default"} Bound 12h ``` `VirtualMachineIPAddress` (`vmip`) resource: A project/namespace resource that is responsible for reserving leased IP addresses and binding them to virtual machines. IP addresses can be allocated automatically or by explicit request. @@ -1497,8 +1780,8 @@ d8 k get vmipl Example output: ```txt -# NAME VIRTUALMACHINEIPADDRESS STATUS AGE -# ip-10-66-10-14 {"name":"linux-vm-7prpx","namespace":"default"} Bound 12h +NAME VIRTUALMACHINEIPADDRESS STATUS AGE +ip-10-66-10-14 {"name":"linux-vm-7prpx","namespace":"default"} Bound 12h ``` By default, an ip address is automatically assigned to a virtual machine from the subnets defined in the module and is assigned to it until it is deleted. You can check the assigned ip address using the command: @@ -1510,8 +1793,8 @@ k get vmip Example output: ```txt -# NAME ADDRESS STATUS VM AGE -# linux-vm-7prpx 10.66.10.14 Attached linux-vm 12h +NAME ADDRESS STATUS VM AGE +linux-vm-7prpx 10.66.10.14 Attached linux-vm 12h ``` The algorithm for automatically assigning an ip address to a virtual machine is as follows: @@ -1598,17 +1881,23 @@ EOF Snapshots are designed to save the state of a resource at a particular point in time. Disk snapshots and virtual machine snapshots are currently supported. -### Creating snapshots from disks +### Creating disk snapshots + +The `VirtualDiskSnapshot` resource is used to create snapshots of virtual disks. These snapshots can serve as a data source when creating new disks, such as for cloning or information recovery. -The `VirtualDiskSnapshot` resource is used to create disk snapshots. It can be used as data sources for creating new virtual disks. +To ensure data integrity, a disk snapshot can be created in the following cases: + +- The disk is not attached to any virtual machine. +- The VM is powered off. +- The VM is running, but qemu-guest-agent is installed in the guest OS. +The file system has been successfully “frozen” (fsfreeze operation). -To guarantee data integrity and consistency, a disk snapshot can be created in the following cases: +If data consistency is not required (for example, for test scenarios), a snapshot can be created: -- the virtual disk is not attached to any virtual machine; -- the virtual disk is attached to a virtual machine that is powered off; -- the virtual disk is connected to a running virtual machine, an agent (`qemu-guest-agent`) is installed in the virtual machine OS, the operation to “freeze” the file system was successful. +- On a running VM without “freezing” the file system. +- Even if the disk is attached to an active VM. -If integrity and consistency is not important, the snapshot can be performed on a running virtual machine without “freezing” the file system, for this purpose in the specification of the resource `VirtualDiskSnapshot` add: +To do this, specify in the VirtualDiskSnapshot manifest: ```yaml spec: @@ -1626,9 +1915,9 @@ d8 k get volumesnapshotclasses Example output: ```txt -# NAME DRIVER DELETIONPOLICY AGE -# csi-nfs-snapshot-class nfs.csi.k8s.io Delete 34d -# sds-replicated-volume replicated.csi.storage.deckhouse.io Delete 39d +NAME DRIVER DELETIONPOLICY AGE +csi-nfs-snapshot-class nfs.csi.k8s.io Delete 34d +sds-replicated-volume replicated.csi.storage.deckhouse.io Delete 39d ``` An example manifest for creating a disk snapshot: @@ -1655,8 +1944,8 @@ d k get vdsnapshot Example output: ```txt -# NAME PHASE CONSISTENT AGE -# linux-vm-root-1728027905 Ready 3m2s +NAME PHASE CONSISTENT AGE +linux-vm-root-1728027905 Ready 3m2s ``` After creation, `VirtualDiskSnapshot` can be in the following states (phases): @@ -1667,6 +1956,8 @@ After creation, `VirtualDiskSnapshot` can be in the following states (phases): - `Failed` - an error occurred during the virtual disk snapshot creation process. - `Terminating` - the resource is in the process of being deleted. +Diagnosing problems with a resource is done by analyzing the information in the `.status.conditions` block. + A full description of the `VirtualDiskSnapshot` resource configuration parameters for machines can be found at [link](cr.html#virtualdisksnapshot) ### Recovering disks from snapshots @@ -1683,7 +1974,7 @@ spec: persistentVolumeClaim: size: 10Gi # Substitute your StorageClass name. - storageClassName: i-linstor-thin-r2 + storageClassName: i-sds-replicated-thin-r2 dataSource: type: ObjectRef objectRef: @@ -1696,12 +1987,34 @@ EOF The `VirtualMachineSnapshot` resource is used to create virtual machine snapshots. -To ensure data integrity and consistency, a virtual machine snapshot will be created if at least one of the following conditions is met: +Snapshots can be used to realize the following scenarios: +- [Restoring the VM at the time the snapshot was created](#restore-a-virtual-machine) +- [Creating a VM clone / Using the snapshot as a template for VM creation](#creating-a-vm-clone--using-a-vm-snapshot-as-a-template-for-creating-a-vm) + +![](./images/vm-restore-clone.png) + +If you plan to use the snapshot as a template, perform the following steps in the guest OS before creating it: + +- Deleting personal data (files, passwords, command history). +- Install critical OS updates. +- Clearing system logs. +- Reset network settings. +- Removing unique identifiers (e.g. via `sysprep` for Windows). +- Optimizing disk space. +- Resetting initialization configurations (`cloud-init clean`). + +{{< alert level="info">}} +A snapshot contains the configuration of the virtual machine and snapshots of all its disks. -- the virtual machine is powered off; -- an agent (qemu-guest-agent) is installed in the virtual machine's operating system, and the operation to freeze the file system was successful. +Restoring a snapshot assumes that the virtual machine is fully restored to the time when the snapshot was created. +{{{< /alert >}} -If integrity and consistency are not important, a snapshot can be created on a running virtual machine without “freezing” the file system. To do this, specify in the `VirtualMachineSnapshot` resource specification: +The snapshot will be created successfully if: + +- The VM is shut down +- `qemu-guest-agent` is installed and the file system is successfully “frozen”. + +If data integrity is not critical, the snapshot can be created on a running VM without freezing the file system. To do this, specify in the specification: ```yaml spec: @@ -1719,9 +2032,9 @@ d8 k get volumesnapshotclasses Example output: ```txt -# NAME DRIVER DELETIONPOLICY AGE -# csi-nfs-snapshot-class nfs.csi.k8s.io Delete 34d -# sds-replicated-volume replicated.csi.storage.deckhouse.io Delete 39d +NAME DRIVER DELETIONPOLICY AGE +csi-nfs-snapshot-class nfs.csi.k8s.io Delete 34d +sds-replicated-volume replicated.csi.storage.deckhouse.io Delete 39d ``` Creating a virtual machine snapshot will fail if at least one of the following conditions is met: @@ -1730,7 +2043,7 @@ Creating a virtual machine snapshot will fail if at least one of the following c - there are changes pending restart of the virtual machine; - there is a disk in the process of resizing among the dependent devices. -When you create a snapshot of the virtual machine, the IP address will be converted to a static IP address and will be used later when restoring the virtual machine from the snapshot. +When a snapshot is created, the dynamic IP address of the VM is automatically converted to a static IP address and saved for recovery. If you do not want to convert and use the old IP address of the virtual machine, you can set the corresponding policy to `Never`. In this case, the address type without conversion (`Auto` or `Static`) will be used. @@ -1750,22 +2063,29 @@ metadata: spec: virtualMachineName: linux-vm volumeSnapshotClasses: - - # Substitute your StorageClass name.: i-linstor-thin-r2 # Substitute your StorageClass name. + - # Substitute your StorageClass name.: i-sds-replicated-thin-r2 # Substitute your StorageClass name. volumeSnapshotClassName: sds-replicated-volume # Substitute your VolumeSnapshotClass name. requiredConsistency: true keepIPAddress: Never EOF ``` -### Restore virtual machines from snapshots +### Restore from snapshots -The `VirtualMachineRestore` resource is used to restore virtual machines from snapshots. +The `VirtualMachineRestore` resource is used to restore a virtual machine from a snapshot. During the restore process, the following objects are automatically created in the cluster: -The restore process will create a new virtual machine and all its dependent resources (disks, IP address, resource with automation script (`Secret`) and resources for dynamic disk attachment (`VirtualMachineBlockDeviceAttachment`)). +- VirtualMachine - the main VM resource with the configuration from the snapshot. +- VirtualDisk - disks connected to the VM at the moment of snapshot creation. +- VirtualBlockDeviceAttachment - disk connections to the VM (if they existed in the original configuration). +- Secret - secrets with cloud-init or sysprep settings (if they were involved in the original VM). -If there is a name conflict between existing and restored resources for `VirtualMachine`, `VirtualDisk`, or `VirtualMachineBlockDeviceAttachment`, the restore will fail. To avoid this, use the `nameReplacements` parameter. +Important: resources are created only if they were present in the VM configuration at the time the snapshot was created. This ensures that an exact copy of the environment is restored, including all dependencies and settings. -If the `VirtualMachineIPAddress` resource to be recovered is already present in the cluster, it must not be attached to another virtual machine, and if it is a resource of type Static, its IP address must match. The recovered secret with automation must also fully match the recovered secret. Failure to meet these conditions will cause the recovery to fail. +#### Restore a virtual machine + +{{< alert level="warning">}} +To restore a virtual machine, you must delete its current configuration and all associated disks. This is because the restore process returns the virtual machine and its disks to the state that was fixed at the time the backup snapshot was created. +{{< /alert >}} Example manifest for restoring a virtual machine from a snapshot: @@ -1774,25 +2094,52 @@ d8 k apply -f - < spec: - virtualMachineSnapshotName: linux-vm-snapshot + virtualMachineSnapshotName: +EOF +``` + +#### Creating a VM clone / Using a VM snapshot as a template for creating a VM + +A snapshot of a virtual machine can be used both to create its exact copy (clone) and as a template for deploying new VMs with a similar configuration. + +This requires creating a `VirtualMachineRestore` resource and setting the renaming parameters in the `.spec.nameReplacements` block to avoid name conflicts. + +Example manifest for restoring a VM from a snapshot: + +```yaml +d8 k apply -f - < +spec: + virtualMachineSnapshotName: nameReplacements: - - from: + - From: kind: VirtualMachine - name: linux-vm - to: linux-vm-2 # recreate an existing `linux-vm` virtual machine with the new name `linux-vm-2`. + name: + to: - from: kind: VirtualDisk - name: linux-vm-root - to: linux-vm-root-2 # recreate the existing `linux-vm-root` virtual disk with the new name `linux-vm-root-2`. + name: + to: - from: kind: VirtualDisk - name: blank-disk - to: blank-disk-2 # recreate the existing `blank-disk` virtual disk with the new name `blank-disk-2`. + name: + to: - from: kind: VirtualMachineBlockDeviceAttachment - name: attach-blank-disk - to: attach-blank-disk-2 # recreate the existing `attach-blank-disk` virtual disk with the new name `attach-blank-disk-2`. + name: + to: EOF ``` + +When restoring a virtual machine from a snapshot, it is important to consider the following conditions: + +1. If the `VirtualMachineIPAddress` resource already exists in the cluster, it must not be assigned to another VM . +2. For static IP addresses (`type: Static`) the value must be exactly the same as what was captured in the snapshot. +3. Automation-related secrets (such as cloud-init or sysprep configuration) must exactly match the configuration being restored. + +Failure to do so will result in a restore error . This is because the system checks the integrity of the configuration and the uniqueness of the resources to prevent conflicts in the cluster. diff --git a/docs/USER_GUIDE_RU.md b/docs/USER_GUIDE.ru.md similarity index 62% rename from docs/USER_GUIDE_RU.md rename to docs/USER_GUIDE.ru.md index b3d6567518..96e2dfc3db 100644 --- a/docs/USER_GUIDE_RU.md +++ b/docs/USER_GUIDE.ru.md @@ -25,7 +25,7 @@ weight: 50 dataSource: type: HTTP http: - url: "https://cloud-images.ubuntu.com/minimal/releases/jammy/release/ubuntu-22.04-minimal-cloudimg-amd64.img" + url: https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img EOF ``` @@ -107,14 +107,14 @@ weight: 50 Пример вывода: ```txt - # NAME PHASE CDROM PROGRESS AGE - # virtualimage.virtualization.deckhouse.io/ubuntu Ready false 100% + NAME PHASE CDROM PROGRESS AGE + virtualimage.virtualization.deckhouse.io/ubuntu Ready false 100% # - # NAME PHASE CAPACITY AGE - # virtualdisk.virtualization.deckhouse.io/linux-disk Ready 300Mi 7h40m + NAME PHASE CAPACITY AGE + virtualdisk.virtualization.deckhouse.io/linux-disk Ready 300Mi 7h40m # - # NAME PHASE NODE IPADDRESS AGE - # virtualmachine.virtualization.deckhouse.io/linux-vm Running virtlab-pt-2 10.66.10.2 7h46m + NAME PHASE NODE IPADDRESS AGE + virtualmachine.virtualization.deckhouse.io/linux-vm Running virtlab-pt-2 10.66.10.2 7h46m ``` 1. Подключитесь с помощью консоли к виртуальной машине (для выхода из консоли необходимо нажать `Ctrl+]`): @@ -126,12 +126,12 @@ weight: 50 Пример вывода: ```txt - # Successfully connected to linux-vm console. The escape sequence is ^] + Successfully connected to linux-vm console. The escape sequence is ^] # - # linux-vm login: cloud - # Password: cloud - # ... - # cloud@linux-vm:~$ + linux-vm login: cloud + Password: cloud + ... + cloud@linux-vm:~$ ``` 1. Для удаления созданных ранее ресурсов используйте следующие команды: @@ -146,6 +146,8 @@ weight: 50 Ресурс `VirtualImage` предназначен для загрузки образов виртуальных машин и их последующего использования для создания дисков виртуальных машин. Данный ресурс доступен только в неймспейсе или проекте в котором он был создан. +При подключении к виртуальной машине доступ к образу предоставляется в режиме «только чтение». + Процесс создания образа включает следующие шаги: - Пользователь создаёт ресурс `VirtualImage`. @@ -154,15 +156,44 @@ weight: 50 Существуют различные типы образов: -- ISO-образ — установочный образ, используемый для начальной установки операционной системы. Такие образы выпускаются производителями ОС и используются для установки на физические и виртуальные серверы. -- Образ диска с предустановленной системой — содержит уже установленную и настроенную операционную систему, готовую к использованию после создания виртуальной машины. Эти образы предлагаются несколькими производителями и могут быть представлены в таких форматах, как qcow2, raw, vmdk и другие. +- **ISO-образ** — установочный образ, используемый для начальной установки операционной системы. Такие образы выпускаются производителями ОС и используются для установки на физические и виртуальные серверы. +- **Образ диска с предустановленной системой** — содержит уже установленную и настроенную операционную систему, готовую к использованию после создания виртуальной машины. Готовые образы можно получить на ресурсах разработчиков дистрибутива, либо создать самостоятельно. Примеры ресурсов для получения образов виртуальной машины: -- [Ubuntu](https://cloud-images.ubuntu.com) -- [Alt Linux](https://ftp.altlinux.ru/pub/distributions/ALTLinux/platform/images/cloud/x86_64) +- Ubuntu + - [24.04 LTS (Noble Numbat)](https://cloud-images.ubuntu.com/noble/current/) + - [22.04 LTS (Jammy Jellyfish)](https://cloud-images.ubuntu.com/jammy/current/) + - [20.04 LTS (Focal Fossa)](https://cloud-images.ubuntu.com/focal/current/) + - [Minimal images](https://cloud-images.ubuntu.com/minimal/releases/) +- Debian + - [12 bookworm](https://cdimage.debian.org/images/cloud/bookworm/latest/) + - [11 bullseye](https://cdimage.debian.org/images/cloud/bullseye/latest/) +- AlmaLinux + - [9](https://repo.almalinux.org/almalinux/9/cloud/x86_64/images/) + - [8](https://repo.almalinux.org/almalinux/8/cloud/x86_64/images/) +- RockyLinux + - [9.5](https://download.rockylinux.org/pub/rocky/9.5/images/x86_64/) + - [8.10](https://download.rockylinux.org/pub/rocky/8.10/images/x86_64/) +- CentOS + - [10 Stream](https://cloud.centos.org/centos/10-stream/x86_64/images/) + - [9 Stream](https://cloud.centos.org/centos/9-stream/x86_64/images/) + - [8 Stream](https://cloud.centos.org/centos/8-stream/x86_64/) + - [8](https://cloud.centos.org/centos/8/x86_64/images/) +- Alt Linux + - [p10](https://ftp.altlinux.ru/pub/distributions/ALTLinux/p10/images/cloud/x86_64/) + - [p9](https://ftp.altlinux.ru/pub/distributions/ALTLinux/p9/images/cloud/x86_64/) - [Astra Linux](https://download.astralinux.ru/ui/native/mg-generic/alse/cloudinit) +Поддерживаются следующие форматы образов с предустановленной системой: + +- qcow2 +- raw +- vmdk +- vdi + +Также файлы образов могут быть сжаты одним из следующих алгоритмов сжатия: gz, xz. + После создания ресурса, тип и размер образа определяются автоматически и эта информация отражается в статусе ресурса. Образы могут быть загружены из различных источников, таких как HTTP-серверы, где расположены файлы образов, или контейнерные реестры. Также доступна возможность загрузки образов напрямую из командной строки с использованием утилиты curl. @@ -187,7 +218,7 @@ weight: 50 apiVersion: virtualization.deckhouse.io/v1alpha2 kind: VirtualImage metadata: - name: ubuntu-22.04 + name: ubuntu-22-04 spec: # Сохраним образ в DVCR. storage: ContainerRegistry @@ -195,23 +226,23 @@ weight: 50 dataSource: type: HTTP http: - url: "https://cloud-images.ubuntu.com/minimal/releases/jammy/release/ubuntu-22.04-minimal-cloudimg-amd64.img" + url: https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img EOF ``` 1. Проверьте результат создания `VirtualImage`: ```bash - d8 k get virtualimage ubuntu-22.04 + d8 k get virtualimage ubuntu-22-04 # или более короткий вариант - d8 k get vi ubuntu-22.04 + d8 k get vi ubuntu-22-04 ``` Пример вывода: ```txt - # NAME PHASE CDROM PROGRESS AGE - # ubuntu-22.04 Ready false 100% 23h + NAME PHASE CDROM PROGRESS AGE + ubuntu-22-04 Ready false 100% 23h ``` После создания ресурс `VirtualImage` может находиться в следующих состояниях (фазах): @@ -225,29 +256,31 @@ weight: 50 До тех пор пока образ не перешёл в фазу `Ready`, содержимое всего блока `.spec` допускается изменять. При изменении процесс создании диска запустится заново. После перехода в фазу `Ready` содержимое блока `.spec` менять нельзя! +Диагностика проблем с ресурсом осуществляется путем анализа информации в блоке `.status.conditions`. + Отследить процесс создания образа можно путем добавления ключа `-w` к предыдущей команде: ```bash -d8 k get vi ubuntu-22.04 -w +d8 k get vi ubuntu-22-04 -w ``` Пример вывода: ```txt -# NAME PHASE CDROM PROGRESS AGE -# ubuntu-22.04 Provisioning false 4s -# ubuntu-22.04 Provisioning false 0.0% 4s -# ubuntu-22.04 Provisioning false 28.2% 6s -# ubuntu-22.04 Provisioning false 66.5% 8s -# ubuntu-22.04 Provisioning false 100.0% 10s -# ubuntu-22.04 Provisioning false 100.0% 16s -# ubuntu-22.04 Ready false 100% 18s +NAME PHASE CDROM PROGRESS AGE +ubuntu-22-04 Provisioning false 4s +ubuntu-22-04 Provisioning false 0.0% 4s +ubuntu-22-04 Provisioning false 28.2% 6s +ubuntu-22-04 Provisioning false 66.5% 8s +ubuntu-22-04 Provisioning false 100.0% 10s +ubuntu-22-04 Provisioning false 100.0% 16s +ubuntu-22-04 Ready false 100% 18s ``` В описание ресурса `VirtualImage` можно получить дополнительную информацию о скачанном образе: ```bash -d8 k describe vi ubuntu-22.04 +d8 k describe vi ubuntu-22-04 ``` Теперь рассмотрим пример создания образа с хранением его в PVC: @@ -257,35 +290,35 @@ d8 k apply -f - < -o json | jq '.status.conditions[] | select(.type | test(".*Ready"))' + ``` + +- `Starting` - запуск виртуальной машины + + Все зависимые ресурсы ВМ - готовы, и система пытается запустить ВМ на одном из узлов кластера. + - Возможные проблемы: + - Нет подходящего узла для запуска. + - На подходящих узлах недостаточно CPU или памяти. + - Превышены квоты неймспейса или проекта. + - Диагностика: + - Если запуск затягивается, проверьте `.status.conditions`, условие `type: Running` + + ``` bash + d8 k get vm -o json | jq '.status.conditions[] | select(.type=="Running")' + ``` -Количество сокетов рассчитывается автоматически и зависит от количества ядер. +- `Running` - виртуальная машина запущена -Для .spec.cpu.cores <= 16: + ВМ успешно запущена и работает. + - Особенности: + - При установленном в гостевой системе qemu-guest-agent, условие `AgentReady` будет истинно,а в `.status.guestOSInfo` будет отображена информация о запущенной гостевой ОС. + - Условие `type: FirmwareUpToDate, status: False` информирует о том, что прошивку ВМ требуется обновить. + - Условие `type: ConfigurationApplied, status: False` информирует о том, что конфигурация ВМ не применена для запущенной ВМ. + - Условие `type: AwaitingRestartToApplyConfiguration, status: True` отображает информацию о необходимости выполнить вручную перезагрузку ВМ, т.к. некоторые изменения конфигурации невозможно применить без перезагрузки ВМ. + - Возможные проблемы: + - Внутренний сбой в работе ВМ или гипервизора. + - Диагностика: + - Проверьте `.status.conditions`, условие `type: Running` -- Создается один сокет с количеством ядер, равным указанному значению. -- Шаг инкремента ядер: 1 -- Допустимые значения: любое число от 1 до 16 включительно. + ``` bash + d8 k get vm -o json | jq '.status.conditions[] | select(.type=="Running")' + ``` -Для 16 < .spec.cpu.cores <= 32: +- `Stopping` - ВМ останавливается или перезагружается -- Создается два сокета с одинаковым количеством ядер в каждом. -- Шаг инкремента ядер: 2 -- Допустимые значения: 18, 20, 22, ..., 32. -- Минимум ядер в сокете: 9 -- Максимум ядер в сокете: 16 +- `Stopped` - ВМ остановлена и не потребляет вычислительные ресурсы -Для 32 < .spec.cpu.cores <= 64: +- `Terminating` - ВМ удаляется. -- Создается четыре сокета с одинаковым количеством ядер в каждом. -- Шаг инкремента ядер: 4 -- Допустимые значения: 36, 40, 44, ..., 64. -- Минимум ядер в сокете: 9 -- Максимум ядер в сокете: 16 + Данная фаза необратима. Все связанные с ВМ ресурсы освобождаются, но не удаляются автоматически. -Для .spec.cpu.cores > 64: +- `Migrating` - живая миграция ВМ -- Создается восемь сокетов с одинаковым количеством ядер в каждом. -- Шаг инкремента ядер: 8 -- Допустимые значения: 72, 80, ... -- Минимум ядер в сокете: 8 + ВМ переносится на другой узел кластера (живая миграция). + - Особенности: + - Миграция ВМ поддерживается только для нелокальных дисков, условие `type: Migratable` отображает информацию о том может ли ВМ мигрировать или нет. + - Возможные проблемы: + - Несовместимость процессорных инструкций (при использовании типов процессоров host или host-passthrough). + - Различие версиях ядер на узлах гипервизоров. + - На подходящих узлах недостаточно CPU или памяти. + - Превышены квоты неймспейса или проекта. + - Диагностика: + - Проверьте `.status.conditions` условие `type: Migrating`, а также блок `.status.migrationState` -Текущая топология ВМ (реальное количество сокетов и ядер) отображается в статусе ВМ в следующем формате: + ```bash + d8 k get vm -o json | jq '.status | {condition: .conditions[] | select(.type=="Migrating"), migrationState}' + ``` + +Условие `type: SizingPolicyMatched, status: False` отображает несоответствие конфигурации ресурсов политике сайзинга используемого VirtualMachineClass. При нарушении политики сохранить параметры ВМ без приведения ресурсов в соответствие политике - невозможно. + +Условия отображают информацию о состоянии ВМ, а также на возникающие проблемы. Понять, что не так с ВМ можно путем их анализа: + +```bash +d8 k get vm fedora -o json | jq '.status.conditions[] | select(.message != "")' +``` + +### Агент гостевой ОС + +Для повышения эффективности управления ВМ рекомендуется установить QEMU Guest Agent — инструмент, который обеспечивает взаимодействие между гипервизором и операционной системой внутри ВМ. + +Чем поможет агент? + +- Обеспечит создание консистентных снимков дисков и ВМ. +- Позволит получать информацию о работающей ОС, которая будет отражена в статусе ВМ. + Пример: + + ```yaml + status: + guestOSInfo: + id: fedora + kernelRelease: 6.11.4-301.fc41.x86_64 + kernelVersion: '#1 SMP PREEMPT_DYNAMIC Sun Oct 20 15:02:33 UTC 2024' + machine: x86_64 + name: Fedora Linux + prettyName: Fedora Linux 41 (Cloud Edition) + version: 41 (Cloud Edition) + versionId: "41" + ``` + +- Позволит отслеживать, что ОС действительно загрузилась: + + ```bash + d8 k get vm -o wide + ``` + + Пример вывода (колонка `AGENT`): + ```console + NAME PHASE CORES COREFRACTION MEMORY NEED RESTART AGENT MIGRATABLE NODE IPADDRESS AGE + fedora Running 6 5% 8000Mi False True True virtlab-pt-1 10.66.10.1 5d21h + ``` + +Как установить QEMU Guest Agent: + +Для Debian-based ОС: + +```bash +sudo apt install qemu-guest-agent +``` + +Для Centos-based ОС: + +```bash +sudo yum install qemu-guest-agent +``` + +Запуск службы агента: + +```bash +sudo systemctl enable --now qemu-guest-agent +``` + +### Автоматическая конфигурация топологии CPU + +Топология CPU виртуальной машины (ВМ) определяет, как ядра процессора распределяются по сокетам. Это важно для обеспечения оптимальной производительности и совместимости с приложениями, которые могут зависеть от конфигурации процессора. В конфигурации ВМ вы задаете только общее количество ядер процессора, а топология (количество сокетов и ядер в каждом сокете) рассчитывается автоматически на основе этого значения. + +Количество ядер процессора указывается в конфигурации ВМ следующим образом: + +```yaml +spec: + cpu: + cores: 1 +``` + +Далее система автоматически определяет топологию в зависимости от заданного числа ядер. Правила расчета зависят от диапазона количества ядер и описаны ниже. + +- Если количество ядер от 1 до 16 (1 ≤ `.spec.cpu.cores` ≤ 16): + - Используется 1 сокет. + - Количество ядер в сокете равно заданному значению. + - Шаг изменения: 1 (можно увеличивать или уменьшать количество ядер по одному). + - Допустимые значения: любое целое число от 1 до 16 включительно. + - Пример: Если задано `.spec.cpu.cores` = 8, то топология: 1 сокет с 8 ядрами. +- Если количество ядер от 17 до 32 (16 < `.spec.cpu.cores` ≤ 32): + - Используется 2 сокета. + - Ядра равномерно распределяются между сокетами (количество ядер в каждом сокете одинаковое). + - Шаг изменения: 2 (общее количество ядер должно быть четным). + - Допустимые значения: 18, 20, 22, 24, 26, 28, 30, 32. + - Ограничения: минимум 9 ядер в сокете, максимум 16 ядер в сокете. + - Пример: Если задано `.spec.cpu.cores` = 20, то топология: 2 сокета по 10 ядер каждый. +- Если количество ядер от 33 до 64 (32 < `.spec.cpu.cores` ≤ 64): + - Используется 4 сокета. + - Ядра равномерно распределяются между сокетами. + - Шаг изменения: 4 (общее количество ядер должно быть кратно 4). + - Допустимые значения: 36, 40, 44, 48, 52, 56, 60, 64. + - Ограничения: минимум 9 ядер в сокете, максимум 16 ядер в сокете. + - Пример: Если задано `.spec.cpu.cores` = 40, то топология: 4 сокета по 10 ядер каждый. +- Если количество ядер больше 64 (`.spec.cpu.cores` > 64): + - Используется 8 сокетов. + - Ядра равномерно распределяются между сокетами. + - Шаг изменения: 8 (общее количество ядер должно быть кратно 8). + - Допустимые значения: 72, 80, 88, 96 и так далее до 248 + - Ограничения: минимум 9 ядер в сокете. + - Пример: Если задано `.spec.cpu.cores` = 80, то топология: 8 сокетов по 10 ядер каждый. + +Шаг изменения указывает, на сколько можно увеличивать или уменьшать общее количество ядер, чтобы они равномерно распределялись по сокетам. + +Максимально возможное количество ядер - 248. + +Текущая топология ВМ (количество сокетов и ядер в каждом сокете) отображается в статусе ВМ в следующем формате: ```yaml status: resources: cpu: - coreFraction: 100% - cores: 18 - requestedCores: "18" + coreFraction: 10% + cores: 1 + requestedCores: "1" runtimeOverhead: "0" topology: - sockets: 2 - coresPerSocket: 9 + sockets: 1 + coresPerSocket: 1 ``` ### Подключение к виртуальной машине @@ -814,9 +990,9 @@ d8 v console linux-vm Пример вывода: ```txt -# Successfully connected to linux-vm console. The escape sequence is ^] -# linux-vm login: cloud -# Password: cloud +Successfully connected to linux-vm console. The escape sequence is ^] +linux-vm login: cloud +Password: cloud ``` Нажмите `Ctrl+]` для завершения работы с серийной консолью. @@ -901,15 +1077,16 @@ d8 k edit vm linux-vm Если виртуальная машина работает (`.status.phase: Running`), то способ применения изменений зависит от их типа: -| Блок конфигурации | Как применяется | -| --------------------------------------- | -------------------------------------- | -| `.metadata.labels` | Сразу | -| `.metadata.annotations` | Сразу | -| `.spec.runPolicy` | Сразу | -| `.spec.disruptions.restartApprovalMode` | Сразу | -| `.spec.affinity` | EE: Сразу, CE: Требуется перезапуск ВМ | -| `.spec.nodeSelector` | EE: Сразу, CE: Требуется перезапуск ВМ | -| `.spec.*` | Требуется перезапуск ВМ | +| Блок конфигурации | Как применяется | +| --------------------------------------- | ---------------------------------------------| +| `.metadata.labels` | Сразу | +| `.metadata.annotations` | Сразу | +| `.spec.liveMigrationPolicy` | Сразу | +| `.spec.runPolicy` | Сразу | +| `.spec.disruptions.restartApprovalMode` | Сразу | +| `.spec.affinity` | EE, SE+ : Сразу, CE: Требуется перезапуск ВМ | +| `.spec.nodeSelector` | EE, SE+ : Сразу, CE: Требуется перезапуск ВМ | +| `.spec.*` | Требуется перезапуск ВМ | Рассмотрим пример изменения конфигурации виртуальной машины: @@ -922,7 +1099,7 @@ d8 v ssh cloud@linux-vm --local-ssh --command "nproc" Пример вывода: ```txt -# 1 +1 ``` Примените следующий патч к виртуальной машине, чтобы изменить количество ядер с 1 на 2. @@ -946,7 +1123,7 @@ d8 v ssh cloud@linux-vm --local-ssh --command "nproc" Пример вывода: ```txt -# 1 +1 ``` Для применения этого изменения необходим перезапуск виртуальной машины. Выполните следующую команду, чтобы увидеть изменения, ожидающие применения (требующие перезапуска): @@ -957,15 +1134,15 @@ d8 k get vm linux-vm -o jsonpath="{.status.restartAwaitingChanges}" | jq . Пример вывода: -```txt -# [ -# { -# "currentValue": 1, -# "desiredValue": 2, -# "operation": "replace", -# "path": "cpu.cores" -# } -# ] +```json +[ + { + "currentValue": 1, + "desiredValue": 2, + "operation": "replace", + "path": "cpu.cores" + } +] ``` Выполните команду: @@ -977,8 +1154,8 @@ d8 k get vm linux-vm -o wide Пример вывода: ```txt -# NAME PHASE CORES COREFRACTION MEMORY NEED RESTART AGENT MIGRATABLE NODE IPADDRESS AGE -# linux-vm Running 2 100% 1Gi True True True virtlab-pt-1 10.66.10.13 5m16s +NAME PHASE CORES COREFRACTION MEMORY NEED RESTART AGENT MIGRATABLE NODE IPADDRESS AGE +linux-vm Running 2 100% 1Gi True True True virtlab-pt-1 10.66.10.13 5m16s ``` В колонке `NEED RESTART` мы видим значение `True`, а это значит что для применения изменений требуется перезагрузка. @@ -1000,7 +1177,7 @@ d8 v ssh cloud@linux-vm --local-ssh --command "nproc" Пример вывода: ```txt -# 2 +2 ``` Порядок применения изменений виртуальной машины через «ручной» рестарт является поведением по умолчанию. Если есть необходимость применять внесенные изменения сразу и автоматически, для этого нужно изменить политику применения изменений: @@ -1236,6 +1413,8 @@ EOF - `InProgress` - идет процесс подключения устройства. - `Attached` - устройство подключено. +Диагностика проблем с ресурсом осуществляется путем анализа информации в блоке `.status.conditions`. + Проверьте состояние вашего ресурса: ```bash @@ -1244,8 +1423,9 @@ d8 k get vmbda attach-blank-disk Пример вывода: -```txt# NAME PHASE VIRTUAL MACHINE NAME AGE -# attach-blank-disk Attached linux-vm 3m7s +```txt +NAME PHASE VIRTUAL MACHINE NAME AGE +attach-blank-disk Attached linux-vm 3m7s ``` Подключитесь к виртуальной машине и удостоверитесь, что диск подключен: @@ -1257,13 +1437,13 @@ d8 v ssh cloud@linux-vm --local-ssh --command "lsblk" Пример вывода: ```txt -# NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS -# sda 8:0 0 10G 0 disk <--- статично подключенный диск linux-vm-root -# |-sda1 8:1 0 9.9G 0 part / -# |-sda14 8:14 0 4M 0 part -# `-sda15 8:15 0 106M 0 part /boot/efi -# sdb 8:16 0 1M 0 disk <--- cloudinit -# sdc 8:32 0 95.9M 0 disk <--- динамически подключенный диск blank-disk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS +sda 8:0 0 10G 0 disk <--- статично подключенный диск linux-vm-root +|-sda1 8:1 0 9.9G 0 part / +|-sda14 8:14 0 4M 0 part +`-sda15 8:15 0 106M 0 part /boot/efi +sdb 8:16 0 1M 0 disk <--- cloudinit +sdc 8:32 0 95.9M 0 disk <--- динамически подключенный диск blank-disk ``` Для отключения диска от виртуальной машины удалите ранее созданный ресурс: @@ -1301,7 +1481,7 @@ d8 k label vm linux-vm app=nginx Пример вывода: ```txt -# virtualmachine.virtualization.deckhouse.io/linux-vm labeled +virtualmachine.virtualization.deckhouse.io/linux-vm labeled ``` #### Публикация сервисов виртуальной машины с использованием сервиса с типом NodePort @@ -1409,16 +1589,86 @@ EOF ### Живая миграция виртуальной машины -Миграция виртуальных машин является важной функцией в управлении виртуализованной инфраструктурой. Она позволяет перемещать работающие виртуальные машины с одного физического узла на другой без их отключения. +Живая миграция виртуальных машин (ВМ) — это процесс перемещения работающей ВМ с одного физического узла на другой без её отключения. Эта функция играет ключевую роль в управлении виртуализованной инфраструктурой, обеспечивая непрерывность работы приложений во время технического обслуживания, балансировки нагрузки или обновлений. + +#### Как работает живая миграция + +Процесс живой миграции включает несколько этапов: + +1. **Создание нового экземпляра ВМ** + + На целевом узле создаётся новая ВМ в приостановленном состоянии. Её конфигурация (процессор, диски, сеть) копируется с исходного узла. + +2. **Первичная передача памяти** + + Вся оперативная память ВМ копируется на целевой узел по сети. Это называется первичной передачей. + +3. **Отслеживание изменений (Dirty Pages)** + + Пока память передаётся, ВМ продолжает работать на исходном узле и может изменять некоторые страницы памяти. Такие страницы называются «грязными» (dirty pages), и гипервизор их помечает. + +4. **Итеративная синхронизация** + + После первичной передачи начинается повторная отправка только изменённых страниц. Этот процесс повторяется в несколько циклов: + - Чем выше нагрузка на ВМ, тем больше «грязных» страниц появляется, и тем дольше длится миграция. + - При хорошей пропускной способности сети объём несинхронизированных данных постепенно уменьшается. + +5. **Финальная синхронизация и переключение** + + Когда количество «грязных» страниц становится минимальным, ВМ на исходном узле приостанавливается (обычно на 100 миллисекунд): + - Оставшиеся изменения памяти передаются на целевой узел. + - Состояние процессора, устройств и открытых соединений синхронизируется. + - ВМ запускается на новом узле, а исходная копия удаляется. + +![](./images/migration.ru.png) -Миграция может осуществляться автоматически при: +{{< alert level="warning" >}} +Cкорость сети играет важную роль. Если пропускная способность низкая, итераций становится больше, а время простоя ВМ может увеличиться. В худшем случае миграция может вообще не завершиться. +{{< /alert >}} + +#### Виды миграции + +Миграция может осуществляться пользователем вручную, либо автоматически при следующих системных событиях: - Обновлении «прошивки» виртуальной машины. -- Перебалансировке нагрузки на узлах кластера. -- Переводе узлов в режим обслуживания для проведения работ. -- При изменении [параметров размещения ВМ](#размещение-вм-по-узлам) (доступно только в Enterprise-редакции). +- Перераспределение нагрузки в кластере. +- Перевод узла в режим технического обслуживания (Drain узла) +- При изменении [параметров размещения ВМ](#размещение-вм-по-узлам) (не доступно в Community-редакции). + +Триггером к живой миграции является появление ресурса `VirtualMachineOperations` с типом `Evict`. + +В таблице приведены префиксы названия ресурса `VirtualMachineOperations` с типом `Evict`, создаваемые для живых миграций вызванных системными событиями: + +| Вид системного события | Префикс имени ресурса | +|----------------------------------|------------------------| +| Обновлении «прошивки» | firmware-update-* | +| Перераспределение нагрузки | evacuation-* | +| Drain узла | evacuation-* | +| Изменение параметров размещения | nodeplacement-update-* | + +Данный ресурс может находится в следующих состояниях: + +- `Pending` - ожидается выполнение операции. +- `InProgress` - живая миграция выполняется. +- `Completed` - живая миграция виртуальной машины завершилась успешно. +- `Failed` - живая миграция виртуальной машины завершилась неуспешно. + +Посмотреть активные операции можно с использованием команды: + +```bash +d8 k get vmop +``` + +Пример вывода: + +```txt +NAME PHASE TYPE VIRTUALMACHINE AGE +firmware-update-fnbk2 Completed Evict linux-vm 1m +``` -Также миграция виртуальной машины может быть выполнена по требованию пользователя. +Прервать любую живую миграцию пока она находится в фазе `Pending`, `InProgress` можно удалив соответствующий ресурс `VirtualMachineOperations`. + +#### Как выполнить живую миграцию виртуальной машины с использованием `VirtualMachineOperations`. Рассмотрим пример. Перед запуском миграции посмотрите текущий статус виртуальной машины: @@ -1429,13 +1679,21 @@ d8 k get vm Пример вывода: ```txt -# NAME PHASE NODE IPADDRESS AGE -# linux-vm Running virtlab-pt-1 10.66.10.14 79m +NAME PHASE NODE IPADDRESS AGE +linux-vm Running virtlab-pt-1 10.66.10.14 79m ``` Мы видим что на данный момент она запущена на узле `virtlab-pt-1`. -Для осуществления миграции виртуальной машины с одного узла на другой, с учетом требований к размещению виртуальной машины используется ресурс `VirtualMachineOperations` (`vmop`) с типом `Evict`. +Для осуществления миграции виртуальной машины с одного узла на другой, с учетом требований к размещению виртуальной машины используется команда: + +```bash +d8 v evict -n +``` + +Выполнение данной команды приводит к созданию ресурса `VirtualMachineOperations`. + +Запустить миграцию можно также создав ресурс `VirtualMachineOperations` (`vmop`) с типом `Evict` вручную: ```yaml d8 k create -f - < +Рассмотрим механизм миграции на примере кластера с двумя группами узлов (`NodeGroups`): green и blue . Допустим, виртуальная машина (ВМ) изначально запущена на узле группы green , а её конфигурация не содержит ограничений на размещение. + +Шаг 1. Добавление параметра размещения +Укажем в спецификации ВМ требование к размещению в группе green : + +```yaml +spec: + nodeSelector: + node.deckhouse.io/group: green +``` + +После сохранения изменений ВМ продолжит работать на текущем узле, так как условие `nodeSelector` уже выполняется. + +Шаг 2. Изменение группы размещения +Изменим требование на размещение в группе blue : + +```yaml +spec: + nodeSelector: + node.deckhouse.io/group: blue +``` + +Теперь текущий узел (группы green) не соответствует новым условиям. Система автоматически создаст объект `VirtualMachineOperations` типа Evict, что инициирует живую миграцию ВМ на доступный узел группы blue. + +Пример вывода ресурса + +```txt +NAME PHASE TYPE VIRTUALMACHINE AGE +nodeplacement-update-dabk4 Completed Evict linux-vm 1m ``` ## IP-адреса виртуальных машин @@ -1488,8 +1775,8 @@ d8 k get vmipl Пример вывода: ```txt -# NAME VIRTUALMACHINEIPADDRESS STATUS AGE -# ip-10-66-10-14 {"name":"linux-vm-7prpx","namespace":"default"} Bound 12h +NAME VIRTUALMACHINEIPADDRESS STATUS AGE +ip-10-66-10-14 {"name":"linux-vm-7prpx","namespace":"default"} Bound 12h ``` Ресурс `VirtualMachineIPAddress` (`vmip`): проектный/неймспейсный ресурс, который отвечает за резервирование арендованных IP-адресов и их привязку к виртуальным машинам. IP-адреса могут выделяться автоматически или по явному запросу. @@ -1503,8 +1790,8 @@ d8 k get vmipl Пример вывода: ```txt -# NAME VIRTUALMACHINEIPADDRESS STATUS AGE -# ip-10-66-10-14 {"name":"linux-vm-7prpx","namespace":"default"} Bound 12h +NAME VIRTUALMACHINEIPADDRESS STATUS AGE +ip-10-66-10-14 {"name":"linux-vm-7prpx","namespace":"default"} Bound 12h ``` По умолчанию IP-адрес виртуальной машине назначается автоматически из подсетей, определенных в модуле и закрепляется за ней до её удаления. Проверить назначенный IP-адрес можно с помощью команды: @@ -1516,8 +1803,8 @@ k get vmip Пример вывода: ```txt -# NAME ADDRESS STATUS VM AGE -# linux-vm-7prpx 10.66.10.14 Attached linux-vm 12h +NAME ADDRESS STATUS VM AGE +linux-vm-7prpx 10.66.10.14 Attached linux-vm 12h ``` Алгоритм автоматического присвоения IP-адреса виртуальной машине выглядит следующим образом: @@ -1570,7 +1857,7 @@ d8 k get vm linux-vm -o jsonpath="{.status.virtualMachineIPAddressName}" Пример вывода: ```txt -# linux-vm-7prpx +linux-vm-7prpx ``` Удалите блоки `.metadata.ownerReferences` из найденного ресурса: @@ -1604,17 +1891,23 @@ EOF Снимки предназначены для сохранения состояния ресурса в конкретный момент времени. На данный момент времени поддерживаются снимки дисков и снимки виртуальных машин. -### Создание снимков из дисков +### Создание снимков дисков + +Для создания снимков виртуальных дисков используется ресурс `VirtualDiskSnapshot` . Эти снимки могут служить источником данных при создании новых дисков, например, для клонирования или восстановления информации. -Для создания снимков дисков используется ресурс `VirtualDiskSnapshot`. Он может быть использован в качестве источников данных для создания новых виртуальных дисков. +Чтобы гарантировать целостность данных, снимок диска можно создать в следующих случаях: -Для гарантии целостности и консистентности данных, снимок диска можно создать в следующих случаях: +- Диск не подключен ни к одной виртуальной машине. +- ВМ выключена. +- ВМ запущена, но yстановлен qemu-guest-agent в гостевой ОС. +Файловая система успешно "заморожена" (операция fsfreeze). -- виртуальный диск не подключен ни к одной виртуальной машине; -- виртуальный диск подключен к виртуальной машине, которая выключена; -- виртуальный диск подключен к запущенной виртуальной машине, в ОС виртуальной машины установлен агент (`qemu-guest-agent`), операция по «заморозке» файловой системы прошла успешно. +Если консистентность данных не требуется (например, для тестовых сценариев), снимок можно создать: -Если целостность и консистентность неважна, снимок можно выполнить на работающей виртуальной машине и без «заморозки» файловой системы, для этого в спецификации ресурса `VirtualDiskSnapshot` добавить: +- На работающей ВМ без "заморозки" файловой системы. +- Даже если диск подключен к активной ВМ. + +Для этого в манифесте VirtualDiskSnapshot укажите: ```yaml spec: @@ -1632,9 +1925,9 @@ d8 k get volumesnapshotclasses Пример вывода: ```txt -# NAME DRIVER DELETIONPOLICY AGE -# csi-nfs-snapshot-class nfs.csi.k8s.io Delete 34d -# sds-replicated-volume replicated.csi.storage.deckhouse.io Delete 39d +NAME DRIVER DELETIONPOLICY AGE +csi-nfs-snapshot-class nfs.csi.k8s.io Delete 34d +sds-replicated-volume replicated.csi.storage.deckhouse.io Delete 39d ``` Пример манифеста для создания снимка диска: @@ -1661,8 +1954,8 @@ d k get vdsnapshot Пример вывода: ```txt -# NAME PHASE CONSISTENT AGE -# linux-vm-root-snapshot Ready true 3m2s +NAME PHASE CONSISTENT AGE +linux-vm-root-snapshot Ready true 3m2s ``` После создания `VirtualDiskSnapshot` может находиться в следующих состояниях (фазах): @@ -1673,6 +1966,8 @@ d k get vdsnapshot - `Failed` — произошла ошибка во время процесса создания снимка виртуального диска. - `Terminating` — ресурс находится в процессе удаления. +Диагностика проблем с ресурсом осуществляется путем анализа информации в блоке `.status.conditions`. + С полным описанием параметров конфигурации ресурса `VirtualDiskSnapshot` машин можно ознакомиться [в документации ресурса](cr.html#virtualdisksnapshot). ### Восстановление дисков из снимков @@ -1691,7 +1986,7 @@ spec: # Укажем размер больше чем значение . size: 10Gi # Подставьте ваше название StorageClass. - storageClassName: i-linstor-thin-r2 + storageClassName: i-sds-replicated-thin-r2 # Источник из которого создается диск. dataSource: type: ObjectRef @@ -1705,12 +2000,34 @@ EOF Для создания снимков виртуальных машин используется ресурс `VirtualMachineSnapshot`. -Чтобы гарантировать целостность и консистентность данных, снимок виртуальной машины будет создан, если выполняется хотя бы одно из следующих условий: +Снимки можно использовать для реализации следующих сценариев: +- [Восстановление ВМ на момент создания снимка](#восстановление-виртуальной-машины) +- [Создание клона ВМ / Использование снимка как шаблона для создания ВМ](#создание-клона-вм--использование-снимка-как-шаблона-для-создания-вм) -- виртуальная машина выключена; -- в операционной системе виртуальной машины установлен агент (qemu-guest-agent), и операция по "заморозке" файловой системы прошла успешно. +![](./images/vm-restore-clone.ru.png) -Если целостность и консистентность неважны, снимок можно создать на работающей виртуальной машине и без «заморозки» файловой системы. Для этого в спецификации ресурса `VirtualMachineSnapshot` укажите: +Если снимок планируется использовать как шаблон, перед его созданием выполните в гостевой ОС: + +- Удаление персональных данных (файлы, пароли, история команд). +- Установку критических обновлений ОС. +- Очистку системных журналов. +- Сброс сетевых настроек. +- Удаление уникальных идентификаторов (например, через `sysprep` для Windows). +- Оптимизацию дискового пространства. +- Сброс конфигураций инициализации (`cloud-init clean`). + +{{< alert level="info" >}} +Снимок содержит конфигурацию виртуальной машины и снимки всех её дисков. + +Восстановление снимка предполагает полное восстановление виртуальной машины на моммент создания её снимка. +{{< /alert >}} + +Снимок будет создан успешно, если: + +- ВМ выключена +- Установлен `qemu-guest-agent` и файловая система успешно "заморожена". + +Если целостность данных не критична, снимок можно создать на работающей ВМ без заморозки ФС. Для этого укажите в спецификации: ```yaml spec: @@ -1728,9 +2045,9 @@ d8 k get volumesnapshotclasses Пример вывода: ```txt -# NAME DRIVER DELETIONPOLICY AGE -# csi-nfs-snapshot-class nfs.csi.k8s.io Delete 34d -# sds-replicated-volume replicated.csi.storage.deckhouse.io Delete 39d +NAME DRIVER DELETIONPOLICY AGE +csi-nfs-snapshot-class nfs.csi.k8s.io Delete 34d +sds-replicated-volume replicated.csi.storage.deckhouse.io Delete 39d ``` Создание снимка виртуальной машины будет неудачным, если выполнится хотя бы одно из следующих условий: @@ -1739,7 +2056,7 @@ d8 k get volumesnapshotclasses - есть изменения, ожидающие перезапуска виртуальной машины; - среди зависимых устройств есть диск, находящийся в процессе изменения размера. -При создании снимка виртуальной машины IP-адрес будет преобразован в статичный и будет использован позже при восстановлении виртуальной машины из снимка. +При создании снимка динамический IP-адрес ВМ автоматически преобразуется в статический и сохраняется для восстановления. Если не требуется преобразование и использование старого IP-адреса виртуальной машины, можно установить соответствующую политику в значение `Never`. В этом случае будет использован тип адреса без преобразования (`Auto` или `Static`). @@ -1759,22 +2076,29 @@ metadata: spec: virtualMachineName: linux-vm volumeSnapshotClasses: - - storageClassName: i-linstor-thin-r2 # Подставьте ваше название StorageClass. + - storageClassName: i-sds-replicated-thin-r2 # Подставьте ваше название StorageClass. volumeSnapshotClassName: sds-replicated-volume # Подставьте ваше название VolumeSnapshotClass. requiredConsistency: true keepIPAddress: Never EOF ``` -### Восстановление виртуальных машин из снимков +### Восстановление из снимков -Для восстановления виртуальных машин из снимков используется ресурс `VirtualMachineRestore`. +Для восстановления виртуальной машины из снимка используется ресурс `VirtualMachineRestore` . В процессе восстановления в кластере автоматически создаются следующие объекты: -В процессе восстановления будет создана новая виртуальная машина, а также все её зависимые ресурсы (диски, IP-адрес, ресурс со сценарием автоматизации (`Secret`) и ресурсы для динамического подключения дисков (`VirtualMachineBlockDeviceAttachment`)). +- VirtualMachine — основной ресурс ВМ с конфигурацией из снимка. +- VirtualDisk — диски, подключенные к ВМ на момент создания снимка. +- VirtualBlockDeviceAttachment — связи дисков с ВМ (если они существовали в исходной конфигурации). +- Secret — секреты с настройками cloud-init или sysprep (если они были задействованы в оригинальной ВМ). -Если возникает конфликт имен между существующими и восстанавливаемыми ресурсами для `VirtualMachine`, `VirtualDisk` или `VirtualMachineBlockDeviceAttachment`, восстановление не будет успешно. Чтобы избежать этого, используйте параметр `nameReplacements`. +Важно: ресурсы создаются только в том случае , если они присутствовали в конфигурации ВМ на момент создания снимка. Это гарантирует восстановление точной копии среды, включая все зависимости и настройки. -Если восстанавливаемый ресурс `VirtualMachineIPAddress` уже присутствует в кластере, он не должен быть присоединен к другой виртуальной машине, а если это ресурс типа Static, его IP-адрес должен совпадать. Восстанавливаемый секрет с автоматизацией также должен полностью соответствовать восстановленному. Несоблюдение этих условий приведет к неудаче восстановления. +#### Восстановление виртуальной машины + +{{< alert level="warning" >}} +Чтобы восстановить виртуальную машину, необходимо удалить её текущую конфигурацию и все связанные диски. Это связано с тем, что процесс восстановления возвращает виртуальную машину и её диски к состоянию, зафиксированному в момент создания резервного снимка. +{{< /alert >}} Пример манифеста для восстановления виртуальной машины из снимка: @@ -1783,25 +2107,52 @@ d8 k apply -f - < spec: - virtualMachineSnapshotName: linux-vm-snapshot + virtualMachineSnapshotName: +EOF +``` + +#### Создание клона ВМ / Использование снимка как шаблона для создания ВМ + +Снимок виртуальной машины может использоваться как для создания её точной копии (клона), так и в качестве шаблона для развёртывания новых ВМ с аналогичной конфигурацией. + +Для этого требуется создать ресурс `VirtualMachineRestore` и задать параметры переименования в блоке `.spec.nameReplacements`, чтобы избежать конфликтов имён. + +Пример манифеста для восстановления ВМ из снимка: + +```yaml +d8 k apply -f - < +spec: + virtualMachineSnapshotName: nameReplacements: - from: kind: VirtualMachine - name: linux-vm - to: linux-vm-2 # воссоздать существующую виртуальную машину `linux-vm` с новым именем `linux-vm-2`. + name: + to: - from: kind: VirtualDisk - name: linux-vm-root - to: linux-vm-root-2 # воссоздать существующий виртуальный диск `linux-vm-root` с новым именем `linux-vm-root-2`. + name: + to: - from: kind: VirtualDisk - name: blank-disk - to: blank-disk-2 # воссоздать существующий виртуальный диск `blank-disk` с новым именем `blank-disk-2`. + name: + to: - from: kind: VirtualMachineBlockDeviceAttachment - name: attach-blank-disk - to: attach-blank-disk-2 # воссоздать существующий виртуальный диск `attach-blank-disk` с новым именем `attach-blank-disk-2`. + name: + to: EOF ``` + +При восстановлении виртуальной машины из снимка важно учитывать следующие условия: + +1. Если ресурс `VirtualMachineIPAddress` уже существует в кластере, он не должен быть назначен другой ВМ . +2. Для статических IP-адресов (`type: Static`) значение должно полностью совпадать с тем, что было зафиксировано в снимке. +3. Секреты, связанные с автоматизацией (например, конфигурация cloud-init или sysprep), должны точно соответствовать восстанавливаемой конфигурации. + +Несоблюдение этих требований приведёт к ошибке восстановления . Это связано с тем, что система проверяет целостность конфигурации и уникальность ресурсов для предотвращения конфликтов в кластере. diff --git a/docs/images/arch.drawio b/docs/images/arch.drawio index fe2ac41c8d..932f6e4fc5 100644 --- a/docs/images/arch.drawio +++ b/docs/images/arch.drawio @@ -1,6 +1,132 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + @@ -13,7 +139,7 @@ - + @@ -45,7 +171,7 @@ - + @@ -53,20 +179,20 @@ - + - + - - + + @@ -86,22 +212,22 @@ - + - + - + - + - + diff --git a/docs/images/arch.png b/docs/images/arch.png index b99efda8d8..ad82dc91d5 100644 Binary files a/docs/images/arch.png and b/docs/images/arch.png differ diff --git a/docs/images/arch.ru.png b/docs/images/arch.ru.png index b99efda8d8..ad82dc91d5 100644 Binary files a/docs/images/arch.ru.png and b/docs/images/arch.ru.png differ diff --git a/docs/images/cases-pods-and-vms.drawio b/docs/images/cases-pods-and-vms.drawio index bd12e125b8..3321fd30fb 100644 --- a/docs/images/cases-pods-and-vms.drawio +++ b/docs/images/cases-pods-and-vms.drawio @@ -1,6 +1,6 @@ - + @@ -28,19 +28,19 @@ - + - + - + diff --git a/docs/images/cases-pods-and-vms.png b/docs/images/cases-pods-and-vms.png index bf762e40dc..611bc19f50 100644 Binary files a/docs/images/cases-pods-and-vms.png and b/docs/images/cases-pods-and-vms.png differ diff --git a/docs/images/cases-pods-and-vms.ru.png b/docs/images/cases-pods-and-vms.ru.png index bf762e40dc..611bc19f50 100644 Binary files a/docs/images/cases-pods-and-vms.ru.png and b/docs/images/cases-pods-and-vms.ru.png differ diff --git a/docs/images/cases-vms.drawio b/docs/images/cases-vms.drawio index e3bcfb11a3..74f5b089ac 100644 --- a/docs/images/cases-vms.drawio +++ b/docs/images/cases-vms.drawio @@ -1,6 +1,6 @@ - + @@ -10,40 +10,40 @@ - + - + - + - + - + - + - + diff --git a/docs/images/cases-vms.png b/docs/images/cases-vms.png index 239eb88942..9375f661de 100644 Binary files a/docs/images/cases-vms.png and b/docs/images/cases-vms.png differ diff --git a/docs/images/cases-vms.ru.png b/docs/images/cases-vms.ru.png index 239eb88942..9375f661de 100644 Binary files a/docs/images/cases-vms.ru.png and b/docs/images/cases-vms.ru.png differ diff --git a/docs/images/cases.dkp.drawio b/docs/images/cases.dkp.drawio index ef18da2808..ef1ff97d2b 100644 --- a/docs/images/cases.dkp.drawio +++ b/docs/images/cases.dkp.drawio @@ -1,23 +1,23 @@ - + - - + + - + - + - + @@ -25,24 +25,24 @@ - + - + - + - + - - + + - + diff --git a/docs/images/cases.dkp.png b/docs/images/cases.dkp.png index a33c92df9d..844feaf30f 100644 Binary files a/docs/images/cases.dkp.png and b/docs/images/cases.dkp.png differ diff --git a/docs/images/cases.dkp.ru.png b/docs/images/cases.dkp.ru.png index a33c92df9d..844feaf30f 100644 Binary files a/docs/images/cases.dkp.ru.png and b/docs/images/cases.dkp.ru.png differ diff --git a/docs/images/coldstandby.drawio b/docs/images/coldstandby.drawio index 328b13437d..31354f686e 100644 --- a/docs/images/coldstandby.drawio +++ b/docs/images/coldstandby.drawio @@ -1,6 +1,6 @@ - + @@ -40,8 +40,8 @@ - - + + @@ -79,8 +79,8 @@ - - + + @@ -132,8 +132,8 @@ - - + + diff --git a/docs/images/coldstandby.png b/docs/images/coldstandby.png index db3f183e0e..69dd56c942 100644 Binary files a/docs/images/coldstandby.png and b/docs/images/coldstandby.png differ diff --git a/docs/images/coldstandby.ru.png b/docs/images/coldstandby.ru.png index db3f183e0e..69dd56c942 100644 Binary files a/docs/images/coldstandby.ru.png and b/docs/images/coldstandby.ru.png differ diff --git a/docs/images/drain.drawio b/docs/images/drain.drawio index 21c7f81c56..8f61f8fcaa 100644 --- a/docs/images/drain.drawio +++ b/docs/images/drain.drawio @@ -1,40 +1,40 @@ - + - + - + - + - + - + - + - + @@ -43,46 +43,46 @@ - + - + - + - + - + - + - + - + - + - + diff --git a/docs/images/drain.png b/docs/images/drain.png index 1bec4ecc4a..eab8e3b5cc 100644 Binary files a/docs/images/drain.png and b/docs/images/drain.png differ diff --git a/docs/images/drain.ru.png b/docs/images/drain.ru.png index 1bec4ecc4a..eab8e3b5cc 100644 Binary files a/docs/images/drain.ru.png and b/docs/images/drain.ru.png differ diff --git a/docs/images/lb-ingress.drawio b/docs/images/lb-ingress.drawio index 9d24b67af5..e12dd3c618 100644 --- a/docs/images/lb-ingress.drawio +++ b/docs/images/lb-ingress.drawio @@ -1,19 +1,19 @@ - + - + - + - + @@ -22,7 +22,7 @@ - + diff --git a/docs/images/lb-ingress.png b/docs/images/lb-ingress.png index 9d3f4bc2d7..bd58718b7e 100644 Binary files a/docs/images/lb-ingress.png and b/docs/images/lb-ingress.png differ diff --git a/docs/images/lb-ingress.ru.png b/docs/images/lb-ingress.ru.png index 9d3f4bc2d7..bd58718b7e 100644 Binary files a/docs/images/lb-ingress.ru.png and b/docs/images/lb-ingress.ru.png differ diff --git a/docs/images/lb-loadbalancer.drawio b/docs/images/lb-loadbalancer.drawio index b118af98b6..3fdebc688d 100644 --- a/docs/images/lb-loadbalancer.drawio +++ b/docs/images/lb-loadbalancer.drawio @@ -1,25 +1,25 @@ - + - + - + - + @@ -72,22 +72,22 @@ - + - + - + - + - + - + diff --git a/docs/images/lb-loadbalancer.png b/docs/images/lb-loadbalancer.png index 9f772dfb76..4550342fe5 100644 Binary files a/docs/images/lb-loadbalancer.png and b/docs/images/lb-loadbalancer.png differ diff --git a/docs/images/lb-loadbalancer.ru.png b/docs/images/lb-loadbalancer.ru.png index 9f772dfb76..4550342fe5 100644 Binary files a/docs/images/lb-loadbalancer.ru.png and b/docs/images/lb-loadbalancer.ru.png differ diff --git a/docs/images/lb-nodeport.drawio b/docs/images/lb-nodeport.drawio index efb57c0e28..8d9f143a65 100644 --- a/docs/images/lb-nodeport.drawio +++ b/docs/images/lb-nodeport.drawio @@ -1,25 +1,25 @@ - + - + - + - + @@ -79,22 +79,22 @@ - + - + - + - + - + - + diff --git a/docs/images/lb-nodeport.png b/docs/images/lb-nodeport.png index ec61c2217a..bc37aca8c9 100644 Binary files a/docs/images/lb-nodeport.png and b/docs/images/lb-nodeport.png differ diff --git a/docs/images/lb-nodeport.ru.png b/docs/images/lb-nodeport.ru.png index ec61c2217a..bc37aca8c9 100644 Binary files a/docs/images/lb-nodeport.ru.png and b/docs/images/lb-nodeport.ru.png differ diff --git a/docs/images/migration.drawio b/docs/images/migration.drawio index 97bdb07271..ea0cc238c0 100644 --- a/docs/images/migration.drawio +++ b/docs/images/migration.drawio @@ -1,89 +1,363 @@ - + - - + + - - + + - - + + - - + + - - + + - - + + + + - - + + + + - - + + - - + + - - + + - - + + - - + + - - + + + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + + + - - + + + + - - + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + - - + + diff --git a/docs/images/migration.png b/docs/images/migration.png index 394ba1bec1..f259128e6b 100644 Binary files a/docs/images/migration.png and b/docs/images/migration.png differ diff --git a/docs/images/migration.ru.png b/docs/images/migration.ru.png index 394ba1bec1..f259128e6b 100644 Binary files a/docs/images/migration.ru.png and b/docs/images/migration.ru.png differ diff --git a/docs/images/placement-node-affinity.drawio b/docs/images/placement-node-affinity.drawio index 5886503d0c..f2d767873a 100644 --- a/docs/images/placement-node-affinity.drawio +++ b/docs/images/placement-node-affinity.drawio @@ -1,6 +1,6 @@ - + @@ -46,10 +46,10 @@ - + - + diff --git a/docs/images/placement-node-affinity.png b/docs/images/placement-node-affinity.png index 764b7c2edf..ef29e2344c 100644 Binary files a/docs/images/placement-node-affinity.png and b/docs/images/placement-node-affinity.png differ diff --git a/docs/images/placement-node-affinity.ru.png b/docs/images/placement-node-affinity.ru.png index 764b7c2edf..ef29e2344c 100644 Binary files a/docs/images/placement-node-affinity.ru.png and b/docs/images/placement-node-affinity.ru.png differ diff --git a/docs/images/placement-nodeselector.drawio b/docs/images/placement-nodeselector.drawio index 0f32be495e..b6320bd743 100644 --- a/docs/images/placement-nodeselector.drawio +++ b/docs/images/placement-nodeselector.drawio @@ -1,25 +1,25 @@ - + - + - + - + @@ -46,7 +46,7 @@ - + @@ -58,14 +58,14 @@ - + - + - + diff --git a/docs/images/placement-nodeselector.png b/docs/images/placement-nodeselector.png index 3a8e7300ff..f449c0428e 100644 Binary files a/docs/images/placement-nodeselector.png and b/docs/images/placement-nodeselector.png differ diff --git a/docs/images/placement-nodeselector.ru.png b/docs/images/placement-nodeselector.ru.png index 3a8e7300ff..f449c0428e 100644 Binary files a/docs/images/placement-nodeselector.ru.png and b/docs/images/placement-nodeselector.ru.png differ diff --git a/docs/images/placement-vm-affinity.drawio b/docs/images/placement-vm-affinity.drawio index 8523ff9d88..aacfc957de 100644 --- a/docs/images/placement-vm-affinity.drawio +++ b/docs/images/placement-vm-affinity.drawio @@ -1,19 +1,19 @@ - + - + - + - + @@ -22,7 +22,7 @@ - + @@ -49,10 +49,10 @@ - + - + @@ -73,7 +73,7 @@ - + diff --git a/docs/images/placement-vm-affinity.png b/docs/images/placement-vm-affinity.png index e0c31a58e2..7f783b2e77 100644 Binary files a/docs/images/placement-vm-affinity.png and b/docs/images/placement-vm-affinity.png differ diff --git a/docs/images/placement-vm-affinity.ru.png b/docs/images/placement-vm-affinity.ru.png index e0c31a58e2..7f783b2e77 100644 Binary files a/docs/images/placement-vm-affinity.ru.png and b/docs/images/placement-vm-affinity.ru.png differ diff --git a/docs/images/placement-vm-antiaffinity.drawio b/docs/images/placement-vm-antiaffinity.drawio index f2ae2e8576..c4409a4d59 100644 --- a/docs/images/placement-vm-antiaffinity.drawio +++ b/docs/images/placement-vm-antiaffinity.drawio @@ -1,28 +1,28 @@ - + - + - + - + - + - + - + @@ -46,10 +46,10 @@ - + - + @@ -61,10 +61,10 @@ - + - + diff --git a/docs/images/placement-vm-antiaffinity.png b/docs/images/placement-vm-antiaffinity.png index 56cb7e6aec..80115b5510 100644 Binary files a/docs/images/placement-vm-antiaffinity.png and b/docs/images/placement-vm-antiaffinity.png differ diff --git a/docs/images/placement-vm-antiaffinity.ru.png b/docs/images/placement-vm-antiaffinity.ru.png index 56cb7e6aec..80115b5510 100644 Binary files a/docs/images/placement-vm-antiaffinity.ru.png and b/docs/images/placement-vm-antiaffinity.ru.png differ diff --git a/docs/images/vd-immediate.drawio b/docs/images/vd-immediate.drawio index ce82f12468..5c440a8445 100644 --- a/docs/images/vd-immediate.drawio +++ b/docs/images/vd-immediate.drawio @@ -1,25 +1,25 @@ - + - + - + - + @@ -33,13 +33,13 @@ - + - + - + @@ -59,17 +59,12 @@ - - - - + + - + - - - @@ -79,21 +74,6 @@ - - - - - - - - - - - - - - - @@ -118,6 +98,24 @@ + + + + + + + + + + + + + + + + + + diff --git a/docs/images/vd-immediate.png b/docs/images/vd-immediate.png index 440b958e82..55504dd7fa 100644 Binary files a/docs/images/vd-immediate.png and b/docs/images/vd-immediate.png differ diff --git a/docs/images/vd-immediate.ru.png b/docs/images/vd-immediate.ru.png index 440b958e82..55504dd7fa 100644 Binary files a/docs/images/vd-immediate.ru.png and b/docs/images/vd-immediate.ru.png differ diff --git a/docs/images/vd-rwo-vs-rwx.drawio b/docs/images/vd-rwo-vs-rwx.drawio index dd4d7c3f2f..a81135d501 100644 --- a/docs/images/vd-rwo-vs-rwx.drawio +++ b/docs/images/vd-rwo-vs-rwx.drawio @@ -1,37 +1,37 @@ - + - + - + - + - + - + - + @@ -43,28 +43,24 @@ - + - + - - - - - - - - + + + + @@ -74,18 +70,23 @@ - + - + - - + + + + + + + - + @@ -94,8 +95,14 @@ - - + + + + + + + + diff --git a/docs/images/vd-rwo-vs-rwx.png b/docs/images/vd-rwo-vs-rwx.png index e290f26621..b4dcc9dfc5 100644 Binary files a/docs/images/vd-rwo-vs-rwx.png and b/docs/images/vd-rwo-vs-rwx.png differ diff --git a/docs/images/vd-rwo-vs-rwx.ru.png b/docs/images/vd-rwo-vs-rwx.ru.png index e290f26621..b4dcc9dfc5 100644 Binary files a/docs/images/vd-rwo-vs-rwx.ru.png and b/docs/images/vd-rwo-vs-rwx.ru.png differ diff --git a/docs/images/vd-wffc.drawio b/docs/images/vd-wffc.drawio index eb77b3c931..13d98875bb 100644 --- a/docs/images/vd-wffc.drawio +++ b/docs/images/vd-wffc.drawio @@ -1,25 +1,25 @@ - + - + - + - + @@ -33,13 +33,13 @@ - + - + - + @@ -59,17 +59,14 @@ - + - + - - - @@ -79,24 +76,27 @@ - - - - - - - - - - + - + + + + + + + + + + + + + diff --git a/docs/images/vd-wffc.png b/docs/images/vd-wffc.png index 618958aa27..6dfafd06b8 100644 Binary files a/docs/images/vd-wffc.png and b/docs/images/vd-wffc.png differ diff --git a/docs/images/vd-wffc.ru.png b/docs/images/vd-wffc.ru.png index 618958aa27..6dfafd06b8 100644 Binary files a/docs/images/vd-wffc.ru.png and b/docs/images/vd-wffc.ru.png differ diff --git a/docs/images/vm-lifecycle.drawio b/docs/images/vm-lifecycle.drawio new file mode 100644 index 0000000000..e221521f41 --- /dev/null +++ b/docs/images/vm-lifecycle.drawio @@ -0,0 +1,69 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/vm-lifecycle.png b/docs/images/vm-lifecycle.png new file mode 100644 index 0000000000..849769e54c Binary files /dev/null and b/docs/images/vm-lifecycle.png differ diff --git a/docs/images/vm-lifecycle.ru.png b/docs/images/vm-lifecycle.ru.png new file mode 100644 index 0000000000..849769e54c Binary files /dev/null and b/docs/images/vm-lifecycle.ru.png differ diff --git a/docs/images/vm-restore-clone.drawio b/docs/images/vm-restore-clone.drawio new file mode 100644 index 0000000000..b9ad4fa2ab --- /dev/null +++ b/docs/images/vm-restore-clone.drawio @@ -0,0 +1,230 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/vm-restore-clone.png b/docs/images/vm-restore-clone.png new file mode 100644 index 0000000000..a57ae0f76f Binary files /dev/null and b/docs/images/vm-restore-clone.png differ diff --git a/docs/images/vm-restore-clone.ru.png b/docs/images/vm-restore-clone.ru.png new file mode 100644 index 0000000000..a57ae0f76f Binary files /dev/null and b/docs/images/vm-restore-clone.ru.png differ diff --git a/docs/images/vm.drawio b/docs/images/vm.drawio index 562b08e150..2de41df013 100644 --- a/docs/images/vm.drawio +++ b/docs/images/vm.drawio @@ -1,62 +1,61 @@ - + - + - - + + - - + + - - + + - - + + - - + + - - + + + + + - - + + + + + - + - - + + - - - - - - - - - + + - - + + - - + + - - + + @@ -65,69 +64,89 @@ - - + + + + + + + + + + + + + + - - + + - - - - + + + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - + - - - - + + + - - + + - - + + - - + + + + + + + + - - + + - - + + + + + diff --git a/docs/images/vm.png b/docs/images/vm.png index e09ce77132..c771d9f28e 100644 Binary files a/docs/images/vm.png and b/docs/images/vm.png differ diff --git a/docs/images/vm.ru.png b/docs/images/vm.ru.png index e09ce77132..c771d9f28e 100644 Binary files a/docs/images/vm.ru.png and b/docs/images/vm.ru.png differ diff --git a/docs/images/vmclass-examples.drawio b/docs/images/vmclass-examples.drawio index 46ed152c1e..a94aacf0e6 100644 --- a/docs/images/vmclass-examples.drawio +++ b/docs/images/vmclass-examples.drawio @@ -1,6 +1,6 @@ - + diff --git a/docs/internal/cpu_cores_count_RU.md b/docs/internal/cpu_cores_count.ru.md similarity index 100% rename from docs/internal/cpu_cores_count_RU.md rename to docs/internal/cpu_cores_count.ru.md diff --git a/docs/internal/dvcr_cleaner_RU.md b/docs/internal/dvcr_cleaner.ru.md similarity index 100% rename from docs/internal/dvcr_cleaner_RU.md rename to docs/internal/dvcr_cleaner.ru.md diff --git a/docs/internal/vd_detect_best_pvc_settings.md b/docs/internal/vd_detect_best_pvc_settings.md new file mode 100644 index 0000000000..ccc415fd61 --- /dev/null +++ b/docs/internal/vd_detect_best_pvc_settings.md @@ -0,0 +1,11 @@ + +When you create a disk, the controller will automatically select the most optimal parameters supported by the storage based on the known data. + +The following are the priorities of the `PersistentVolumeClaim` parameter settings when creating a disk by automatically defining the storage features: + +- `RWX + Block` +- `RWX + FileSystem` +- `RWO + Block` +- `RWO + FileSystem` + +If the storage is unknown and it is impossible to automatically define its parameters, then `RWO + FileSystem` is used. diff --git a/tools/validation/doc_changes.go b/tools/validation/doc_changes.go index c8a1993a92..b25967ece4 100644 --- a/tools/validation/doc_changes.go +++ b/tools/validation/doc_changes.go @@ -74,7 +74,7 @@ func RunDocChangesValidation(info *DiffInfo) (exitCode int) { } var possibleDocRootsRe = regexp.MustCompile(`docs/|docs/documentation`) -var docsDirAllowedFileRe = regexp.MustCompile(`docs/(CONFIGURATION|CR|FAQ|README|ADMIN_GUIDE|USER_GUIDE|CHARACTERISTICS_DESCRIPTION|INSTALL)(_RU)?.md`) +var docsDirAllowedFileRe = regexp.MustCompile(`docs/(CONFIGURATION|CR|FAQ|README|ADMIN_GUIDE|USER_GUIDE|CHARACTERISTICS_DESCRIPTION|INSTALL)(\.ru)?.md`) var docsDirFileRe = regexp.MustCompile(`docs/[^/]+.md`) func checkDocFile(fName string, diffInfo *DiffInfo) (msg Message) { @@ -96,16 +96,16 @@ Only following file names are allowed in the module '/docs/' directory: ADMIN_GUIDE.md USER_GUIDE.md CHARACTERISTICS_DESCRIPTION.md -(also their Russian versions ended with '_RU.md')`, +(also their Russian versions ended with '.ru.md')`, ) } // Check if documentation for other language file is also modified. var otherFileName = fName - if strings.HasSuffix(fName, `_RU.md`) { - otherFileName = strings.TrimSuffix(fName, "_RU.md") + ".md" + if strings.HasSuffix(fName, `.ru.md`) { + otherFileName = strings.TrimSuffix(fName, ".ru.md") + ".md" } else { - otherFileName = strings.TrimSuffix(fName, ".md") + "_RU.md" + otherFileName = strings.TrimSuffix(fName, ".md") + ".ru.md" } return checkRelatedFileExists(fName, otherFileName, diffInfo) } diff --git a/tools/validation/no_cyrillic.go b/tools/validation/no_cyrillic.go index 64635fb371..d41c65a327 100644 --- a/tools/validation/no_cyrillic.go +++ b/tools/validation/no_cyrillic.go @@ -22,7 +22,7 @@ import ( "strings" ) -var skipDocRe = regexp.MustCompile(`doc-ru-.+\.y[a]?ml$|_RU\.md$`) +var skipDocRe = regexp.MustCompile(`doc-ru-.+\.y[a]?ml$|\.ru\.md$`) var skipI18NRe = regexp.MustCompile(`/i18n/`) var skipSelfRe = regexp.MustCompile(`no_cyrillic(_test)?.go$`) diff --git a/werf.yaml b/werf.yaml index 0cd01a2d49..9aaabd0361 100644 --- a/werf.yaml +++ b/werf.yaml @@ -118,6 +118,7 @@ git: - component_versions/README.md - hooks/lib/tests - hooks/test* + - docs/images/*.drawio --- image: release-channel-version fromImage: builder/scratch