From 9d77314ec2f8a5fb5144d78e70cf34ec050a36b3 Mon Sep 17 00:00:00 2001 From: MariaMakeeva <156068662+MariaMakeeva@users.noreply.github.com> Date: Tue, 13 Feb 2024 17:46:14 +0300 Subject: [PATCH 1/6] Update EXAMPLES_RU.md Update text Signed-off-by: MariaMakeeva <156068662+MariaMakeeva@users.noreply.github.com> --- docs/EXAMPLES_RU.md | 152 +++++++++++++++++++++----------------------- 1 file changed, 71 insertions(+), 81 deletions(-) diff --git a/docs/EXAMPLES_RU.md b/docs/EXAMPLES_RU.md index 64f636850..ba45ea4a3 100644 --- a/docs/EXAMPLES_RU.md +++ b/docs/EXAMPLES_RU.md @@ -6,13 +6,13 @@ title: "Примеры конфигурации" Пример создания виртуальной машины с Ubuntu 22.04. -Создадим namespace, где будем создавать виртуальные машины: +1. Создайте namespace для виртуальных машин с помощью команды: ```bash kubectl create ns vms ``` -Создадим диск виртуальной машины из внешнего источника: +2. Создайте диск виртуальной машины из внешнего источника: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -32,7 +32,7 @@ spec: После создания `VirtualMachineDiks` в namespace vms, запустится под с именем `importer-*`, который осуществит загрузку заданного образа. -Посмотрим на текущий статус ресурса: +3. Посмотрите текущий статус ресурса с помощью комнады: ```bash kubectl -n vms get virtualmachinedisk -o wide @@ -41,7 +41,7 @@ kubectl -n vms get virtualmachinedisk -o wide # linux-disk Ready 10Gi 100% vmd-vmd-blank-001-10c7616b-ba9c-4531-9874-ebcb3a2d83ad 1m ``` -Далее создадим виртуальную машину из следующей спецификации: +4. Создайте виртуальную машину из следующей спецификации: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -80,7 +80,7 @@ spec: name: linux-disk ``` -Проверим, что виртуальная машина создана и запущена: +5. Проверьте с помощью команды, что виртуальная машина создана и запущена: ```bash kubectl -n default get virtualmachine @@ -89,13 +89,13 @@ kubectl -n default get virtualmachine # linux-vm Running virtlab-1 10.66.10.1 5m ``` -Подключимся к виртуальной машине с использованием консоли (для выхода из консоли необходимо нажать `Ctrl+]`): +6. Подключитесь с помощью консоли к виртуальной машине (для выхода из консоли необходимо нажать `Ctrl+]`): ```bash dvp console -n vms linux-vm ``` -Подключимся к машине с использованием VNC: +7. Подключитесь к машине с использованием VNC: ```bash dvp vnc -n vms linux-vm @@ -105,17 +105,15 @@ dvp vnc -n vms linux-vm ## Образы -`VirtualMachineImage` и `ClusterVirtualMachineImage` предназначены для хранения образов дисков виртуальных машин или установочных образов в формате `iso`, чтобы создавать и однотипно воспроизводить диски виртуальных машин. При подключении к виртуальной машине эти образы доступны только для чтения, и установочный образ в формате `iso` будет подключен в виде cdrom-устройства. +`VirtualMachineImage` и `ClusterVirtualMachineImage` используются для хранения образов виртуальных машин, представляющих собой диски виртуальных машин или ISO-образы с установочными файлами, с целью создания и тиражирования идентичных дисков виртуальных машин. При подключении к виртуальной машине эти образы доступны только для чтения, и установочный IS0-образ будет подключен в виде cdrom-устройства. -Ресурс `VirtualMachineImage` доступен только в том пространстве имен, в котором он был создан, а `ClusterVirtualMachineImage` доступен для всех пространств имен внутри кластера. +Ресурс `VirtualMachineImage` доступен только в том пространстве имен, в котором был создан, а `ClusterVirtualMachineImage` доступен для всех пространств имен внутри кластера. -В зависимости от конфигурации, ресурс `VirtualMachineImage` может хранить данные в `DVCR` или использовать дисковое хранилище, предоставляемое платформой (PV). С другой стороны, `ClusterVirtualMachineImage` хранит данные только в `DVCR`, обеспечивая единый доступ ко всем образам для всех пространств имен в кластере. - -Рассмотрим на примерах создание этих ресурсов. +В зависимости от конфигурации, ресурс `VirtualMachineImage` может хранить данные в `DVCR` или использовать дисковое хранилище, предоставляемое платформой (PV). `ClusterVirtualMachineImage` хранит данные только в `DVCR`, обеспечивая единый доступ ко всем образам для всех пространств имен в кластере. ### Создание и использование образа c HTTP-ресурса -Создадим `VirtualMachineImage` и в качестве хранилища образов будем использовать `DVCR`: +1. Создадайте `VirtualMachineImage` и в качестве хранилища образов используйте `DVCR`: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -131,7 +129,7 @@ spec: url: "https://cloud-images.ubuntu.com/minimal/releases/jammy/release-20230615/ubuntu-22.04-minimal-cloudimg-amd64.img" ``` -Посмотрим, что получилось: +2. Проверьте результат с помощью команды: ```bash kubectl -n vms get virtualmachineimage @@ -151,7 +149,7 @@ spec: где `your-storage-class-name` — это название StorageClass, который будет использоваться. -Для просмотра списка доступных StorageClass'ов выполните следующую команду: +3. Для просмотра списка доступных StorageClass'ов выполните следующую команду: ```bash kubectl get storageclass @@ -177,7 +175,7 @@ spec: url: "https://cloud-images.ubuntu.com/minimal/releases/jammy/release-20230615/ubuntu-22.04-minimal-cloudimg-amd64.img" ``` -Просмотрим статус `ClusterVirtualMachineImage`: +4. Проверьте статус `ClusterVirtualMachineImage` с помощью команды: ```bash kubectl get clustervirtualmachineimage @@ -186,42 +184,42 @@ kubectl get clustervirtualmachineimage # ubuntu-img Ready false 100% 11m ``` -Образы могут быть созданы из различных внешних источников, таких как HTTP-сервер, где размещены файлы образов или контейнерный реестр (container registry), где образы хранятся и доступны для загрузки. Кроме того, возможно загрузить образы напрямую из командной строки, используя утилиту curl. Давайте рассмотрим каждый из этих вариантов более подробно. +Образы могут быть получены из различных источников, таких как HTTP-серверы, на которых расположены файлы образов, или контейнерные реестры (container registries), где образы сохраняются и становятся доступны для скачивания. Также существует возможность загрузить образы напрямую из командной строки, используя утилиту `curl`. ### Создание и использование образа из container registry -Первое, что необходимо, — это сформировать сам образ для хранения в container registry. +1. Cформируйте образ для хранения в `container registry`. -В качестве примера рассмотрим вариант создания docker-образа c диском Ubuntu 22.04. +Ниже представлен пример создания docker-образа c диском Ubuntu 22.04. -Загрузим образ локально: +* Загрузите образ локально: ```bash curl -L https://cloud-images.ubuntu.com/minimal/releases/jammy/release-20230615/ubuntu-22.04-minimal-cloudimg-amd64.img -o ubuntu2204.img ``` -Создадим Dockerfile со следующим содержимым: +* Создайте Dockerfile со следующим содержимым: ```Dockerfile FROM scratch COPY ubuntu2204.img /disk/ubuntu2204.img ``` -Соберем образ и загрузим его в container registry. В качестве container registry будем использовать docker.io, для этого вам необходимо иметь учетную запись сервиса и настроенное окружение. +* Соберите образ и загрузите его в `container registry`. В качестве `container registry` в примере ниже использован docker.io. для выполнения вам необходимо иметь учетную запись сервиса и настроенное окружение. ```bash docker build -t docker.io/username/ubuntu2204:latest ``` -где `username` — ваше имя пользователя, указанное при регистрации в docker.io. +где `username` — имя пользователя, указанное при регистрации в docker.io. -Загрузим созданный образ в container registry: +* Загрузите созданный образ в `container registry` с помощью команды: ```bash docker push docker.io/username/ubuntu2204:latest ``` -Чтобы использовать этот образ, создадим в качестве примера ресурс `ClusterVirtualMachineImage`: +* Чтобы использовать этот образ, создайте в качестве примера ресурс `ClusterVirtualMachineImage`: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -235,7 +233,7 @@ spec: image: docker.io/username/ubuntu2204:latest ``` -Чтобы посмотреть ресурс и его статус, выполните команду: +* Чтобы посмотреть ресурс и его статус, выполните команду: ```bash kubectl get clustervirtalmachineimage @@ -243,7 +241,7 @@ kubectl get clustervirtalmachineimage ### Загрузка образа из командной строки -Чтобы загрузить образ из командной строки, нам предварительно нужно создать следующий ресурс, рассмотрим на примере `ClusterVirtualMachineImage`: +1. Чтобы загрузить образ из командной строки, предварительно создайте следующий ресурс, как представлено ниже на примере `ClusterVirtualMachineImage`: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -255,7 +253,7 @@ spec: type: Upload ``` -После того как ресурс будет создан, посмотрим его статус: +2. После того как ресурс будет создан, проверьте его статус с помощью команды: ```bash kubectl get clustervirtualmachineimages some-image -o json | jq .status.uploadCommand -r @@ -264,9 +262,9 @@ kubectl get clustervirtualmachineimages some-image -o json | jq .status.uploadCo -T example.iso ``` -> Стоит отметить, что CVMI с типом Upload ожидает начала загрузки образа 15 минут после создания. По истечении данного таймаута ресурс перейдет в состояние Failed. +> CVMI с типом **Upload** ожидает начала загрузки образа 15 минут после создания. По истечении этого срока ресурс перейдет в состояние **Failed**. -Загрузим для примера образ Cirros и загрузим его: +3. Загрузите образ Cirros (представлено в качестве примера): ```bash curl -L http://download.cirros-cloud.net/0.5.1/cirros-0.5.1-x86_64-disk.img -o cirros.img @@ -275,7 +273,7 @@ https://virtualization.example.com/upload/dSJSQW0fSOerjH5ziJo4PEWbnZ4q6ffc -T ci После завершения работы команды `curl` образ должен быть создан. -Проверить, что все прошло успешно, можно, проверив статус созданного образа: +4. Проверьте, что статус созданного образа успешен: ```bash kubectl get clustervirtualmachineimages @@ -288,17 +286,17 @@ kubectl get clustervirtualmachineimages Диски используются в виртуальных машинах для записи и хранения данных. Для хранения дисков используется хранилище, предоставляемое платформой. -Чтобы посмотреть доступные варианты, выполните команду: +1. Чтобы посмотреть доступные варианты, выполните команду: ```bash kubectl get storageclass ``` -Рассмотрим варианты, какие диски мы можем создавать: - ### Создание пустого диска -Первое, что стоит отметить, — это то, что диски мы можем создавать пустыми! +> Существует возможность создания пустых дисков. + +1. Создайте диск: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -311,9 +309,9 @@ spec: size: 100M ``` -После создания диска мы его можем использовать для подключения к виртуальной машине. +Созданный диск можно использовать для подключения к виртуальной машине. -Посмотреть состояние созданного ресурса можно командой: +2. Проверьте состояние созданного ресурса с помощью команды: ```bash kubectl get virtualmachinedisk @@ -324,11 +322,11 @@ kubectl get virtualmachinedisk ### Создание диска из образа -Мы можем создавать диски, используя уже имеющиеся образы дисков, а также внешние источники, подобно образам. +> Можно создать диски из существующих дисковых образов, а также из внешних ресурсов, таких как образы. -При создании ресурса диска мы можем указать желаемый размер. Если размер не указан, то будет создан диск с размером, соответствующим исходному образу диска, который хранится в ресурсе `VirtualMachineImage` или `ClusterVirtualMachineImage`. Если необходимо создать диск большего размера, необходимо явно указать это. +При создании ресурса диска можно указать желаемый размер. Если размер не указан, то будет создан диск с размером, соответствующим исходному образу диска, который хранится в ресурсе `VirtualMachineImage` или `ClusterVirtualMachineImage`. Если необходимо создать диск большего размера, укажите необходимый размер. -В качестве примера используем ранее созданный `ClusterVirtualMachineImage` с именем `ubuntu-2204`: +Используйте ранее созданный `ClusterVirtualMachineImage` с именем `ubuntu-2204` (приведено в качестве примера): ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -347,7 +345,7 @@ spec: ### Изменение размера диска -Размер дисков можно менять (пока только в сторону увеличения), даже если они подключены к виртуальной машине, для этого необходимо отредактировать поле `spec.persistentVolumeClame.size`: +Размер дисков можно изменить только в сторону увеличения, даже если они подключены к виртуальной машине. Для этого отредактируйте поле `spec.persistentVolumeClame.size`: ```yaml kubectl patch ubuntu-root --type merge -p '{"spec":{"persistentVolumeClaim":{"size":"11Gi"}}}' @@ -355,7 +353,7 @@ kubectl patch ubuntu-root --type merge -p '{"spec":{"persistentVolumeClaim":{"si ### Подключение дисков к запущенным виртуальным машинам -Диски можно подключать «на живую», к уже запущенной виртуальной машине, для этого используется ресурс `VirtualMachineBlockDeviceAttachment`, например: +Диски могут быть подключены в работающей виртуальной машине с использованием `VirtualMachineBlockDeviceAttachment` ресурса (приведенного в качестве примера): ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -370,10 +368,10 @@ spec: name: vmd-blank # Имя подключаемого диска. ``` -Если изменить имя машины в этом ресурсе на имя другой машины, диск будет переподключен от одной виртуальной машины к другой. +Если в указанном ресурсе изменить имя виртуальной машины на имя другой виртуальной машины, диск будет перенаправлен от одной виртуальной машины к другой. При удалении ресурса `VirtualMachineBlockDeviceAttachment` диск от виртуальной машины будет отключен. -Чтобы посмотреть список подключенных «на живую» дисков, выполните команду: +Чтобы посмотреть список подключенных дисков в работающей виртуальной машине, выполните команду: ```bash kubectl get virtualmachineblockdeviceattachments @@ -381,8 +379,6 @@ kubectl get virtualmachineblockdeviceattachments ## Виртуальные машины -Итак, теперь у нас есть диски и образы, перейдем к самому главному — созданию виртуальной машины. - Для создания виртуальной машины используется ресурс `VirtualMachine`, его параметры позволяют сконфигурировать: - ресурсы, требуемые для работы виртуальной машины (процессор, память, диски и образы); @@ -391,13 +387,9 @@ kubectl get virtualmachineblockdeviceattachments - политику запуска виртуальной машины и политику применения изменений; - сценарии начальной конфигурации (cloud-init). -Cоздадим виртуальную машину и настроим ее по шагам: - -### 0. Создание диска для виртуальной машины +### Создание диска для виртуальной машины -Первое, что нужно, прежде чем создавать ресурс виртуальной машины, — это создать диск с установленной ОС. - -Создадим диск для виртуальной машины: +Создайте диск с установыленной ОС для виртуальной машины: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -413,9 +405,9 @@ spec: url: "https://cloud-images.ubuntu.com/minimal/releases/jammy/release-20230615/ubuntu-22.04-minimal-cloudimg-amd64.img" ``` -### 1. Создание виртуальной машины +### Создание виртуальной машины -Ниже представлен пример простейшей конфигурации виртуальной машины, запускающей ОС Ubuntu 22.04. В примере используется сценарий первичной инициализации виртуальной машины (cloud-init), который устанавливает пакет nginx и создает пользователя `cloud` с паролем `cloud`: +Ниже представлен пример простой конфигурации виртуальной машины, запускающей ОС Ubuntu 22.04. В примере используется сценарий первичной инициализации виртуальной машины (cloud-init), который устанавливает пакет **nginx** и создает пользователя `cloud` с паролем `cloud`: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -456,9 +448,7 @@ spec: name: ubuntu-2204-root ``` -При наличии каких-то приватных данных сценарий начальной инициализации виртуальной машины может быть создан в Secret'е. - -Пример Secret'а: +При наличии приватных данных, сценарий начальной инициализации виртуальной машины может быть создан в Secret'е. Пример Secret'а приведен ниже: ```yaml apiVersion: v1 @@ -471,7 +461,7 @@ data: type: Opaque ``` -Как это будет выглядеть в спецификации виртуальной машины: +Спецификация виртуальной машины будет выглядеть следующим образом: ```yaml spec: @@ -481,9 +471,9 @@ spec: name: linux-vm-cloud-init ``` -Создадим виртуальную машину из манифеста выше. +1. Создайте виртуальную машину из манифеста представленного выше. -После запуска виртуальня машина должна быть в статусе `Ready`. +После запуска виртуальная машина должна иметь статус `Ready`. ```bash kubectl get virtualmachine @@ -494,9 +484,9 @@ kubectl get virtualmachine После создания виртуальная машина автоматически получит IP-адрес из диапазона, указанного в настройках модуля (блок `virtualMachineCIDRs`). -Если мы хотим зафиксировать конкретный IP-адрес для машины перед ее запуском, необходимо выполнить следующие шаги: +2. Чтобы зафиксировать IP-адрес виртуальной машины перед ее запуском, выполните следующие шаги: -1. Создать ресурс `VirtualMachineIPAddressClaim`, в котором зафиксировать желаемый IP-адрес виртуальной машины: +* Создайте ресурс `VirtualMachineIPAddressClaim`, в котором зафиксирован желаемый IP-адрес виртуальной машины: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -508,7 +498,7 @@ spec: address: "W.X.Y.Z" ``` -2. Соответствующим образом зафиксировать изменения в спецификации виртуальной машины: +* Зафиксируйте изменения в спецификации виртуальной машины: ```yaml spec: @@ -517,7 +507,7 @@ spec: ### 2. Настройка правил размещения виртуальной машины -Допустим, нам необходимо, чтобы виртуальная машина запускалась на заданном наборе узлов, например на группе узлов `system`. В этом нам поможет следующий фрагмент конфигурации: +1. Для того, чтобы виртуальная машина запускалась на заданном наборе узлов, например, на группе узлов `system`, используйте следующий фрагмент конфигурации: ```yaml spec: @@ -529,23 +519,23 @@ spec: node-role.kubernetes.io/system: "" ``` -Внесите изменения в ранее созданную спецификацию виртуальной машины. +2. Внесите изменения в ранее созданную спецификацию виртуальной машины. ### 3. Настройка порядка применения изменений -После внесения изменений в конфигурацию машины ничего не произойдет, так как по умолчанию применяется политика применения изменений `Manual`, а это значит, что изменения нужно подтвердить. +Внесенные изменения в конфигурацию виртуальной машины не отобразятся, так как по умолчанию применяется политика изменений `Manual`. Внесенные изменения изменения нужно подтвердить. -Как мы можем это понять? - -Посмотрим на статус VM: +1. Чтобы проверить статус виртуальной машины, введите командую: ```bash kubectl get linux-vm -o jsonpath='{.status}' ``` -В поле `.status.pendingChanges` мы увидим изменения, которые требуют применения. В поле `.status.message` сообщение, о том что для применения требуемых изменений необходим рестарт виртуальной машины. +В поле `.status.pendingChanges` отобразятся изменения, которые требуют подтверждения. + +В поле `.status.message` появится сообщение: для применения изменений, необходимо перезапустить виртуальную машину. -Создадим и применим следующий ресурс, от отвечает за декларативный способ управления состоянием виртуальной машины: +2. Создайте и примените ресурс, который отвечает за декларативный способ управления состоянием виртуальной машины, как представлено на примере ниже: ```bash cat < В отличие от традиционных систем виртуализации, мы используем политику запуска для определения состояния виртуальной машины, которая определяет требуемое состояние виртуальной машины в любое время. -При создании виртуальной машины мы указали параметр `runPolicy: AlwaysOn`, а это значит, что виртуальная машина должна быть запущена, даже если по какой-то причине произошло ее выключение, рестарт или сбой, повлекший завершение ее работы. +> При создании виртуальной машины используется параметр `runPolicy: AlwaysOn`. Это означает, что виртуальная машина будет запущена, даже если по каким-либо причинам произошло ее отключение, перезапуск или сбой, вызвавший прекращение ее работы. -Чтобы выключить машину, поменяем значение политики на `AlwaysOff`, при этом произойдет корректное завершение работы виртуальной машины. +Для выключения виртуальной машины, поменяйте значение политики на `AlwaysOff`. После чего произойдет корректное завершение работы виртуальной машины. From 2a86cd1c001e83ccfea4090ec8dafb21064cc909 Mon Sep 17 00:00:00 2001 From: MariaMakeeva <156068662+MariaMakeeva@users.noreply.github.com> Date: Wed, 14 Feb 2024 10:43:46 +0300 Subject: [PATCH 2/6] Update FAQ_RU.md Signed-off-by: MariaMakeeva <156068662+MariaMakeeva@users.noreply.github.com> --- docs/FAQ_RU.md | 47 ++++++++++++++++++++++++++--------------------- 1 file changed, 26 insertions(+), 21 deletions(-) diff --git a/docs/FAQ_RU.md b/docs/FAQ_RU.md index ca60789db..0296a1a31 100644 --- a/docs/FAQ_RU.md +++ b/docs/FAQ_RU.md @@ -4,11 +4,11 @@ title: "FAQ" ## Как установить ОС в виртуальной машине из ISO-образа? -Рассмотрим установку ОС в виртуальной машине из ISO-образа на примере установки ОС Windows. +**Установка ОС в виртуальной машине из ISO-образа на примере установки ОС Windows** -Для установки ОС нам потребуется ISO-образ ОС Windows. Необходимо его загрузить и опубликовать на каком-либо HTTP-сервисе, доступном из кластера. +Для установки ОС необходим ISO-образ ОС Windows. Для этого загрузите и опубликуйте его на каком-либо HTTP-сервисе, доступном из кластера. -Создадим пустой диск для установки ОС: +1. Создайте пустой диск для установки ОС: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -22,7 +22,7 @@ spec: storageClassName: local-path ``` -Создадим ресурсы с ISO-образами ОС Windows и драйверами virtio: +2. Создайте ресурсы с ISO-образами ОС Windows и драйверами virtio: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -48,7 +48,7 @@ spec: url: "https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso" ``` -Создадим виртуальную машину: +3. Создайте виртуальную машину: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -80,15 +80,17 @@ spec: name: win-disk ``` -После создания ресурса виртуальная машина будет запущена. К ней необходимо подключиться, с помощью графического установщика добавить драйверы `virtio` и выполнить установку ОС. +После создания ресурса виртуальная машина будет запущена. К ней необходимо подключиться с помощью графического установщика. + +4. Добавьте драйверы `virtio` и выполните установку ОС: ```bash dvp vnc -n default win-vm ``` -После окончания установки завершить работу виртуальной машины. +6. После окончания установки завершите работу виртуальной машины. -Далее необходимо модифицировать ресурс `VirtualMachine` и применить изменения: +7. Модифицируйте ресурс `VirtualMachine` и примените изменения: ```yaml spec: @@ -113,7 +115,7 @@ FROM scratch COPY image-name.img /disk/image-name.img ``` -Далее необходимо собрать образ и запушить его в container registry: +1. Соберите образ и отправьте его в `container registry`: ```bash docker build -t docker.io/username/image:latest @@ -123,11 +125,11 @@ docker push docker.io/username/image:latest ## Как перенаправить трафик на виртуальную машину -Поскольку виртуальная машина функционирует в кластере Kubernetes, направление сетевого трафика на нее осуществляется аналогично направлению трафика на поды. +Так как виртуальная машина функционирует в кластере Kubernetes, направление сетевого трафика осуществляется аналогично направлению трафика на поды. -Для этого нужно всего лишь создать сервис с требуемыми настройками. +1. Для этого создайте сервис с требуемыми настройками. -Допустим, у нас есть виртуальная машина с HTTP-сервисом, опубликованным на порте 80, и следующим набором меток: +В качестве примера приведена виртуальная машина с HTTP-сервисом, опубликованным на порте 80, и следующим набором меток: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -139,7 +141,7 @@ metadata: spec: ... ``` -Чтобы направить сетевой трафик на 80-й порт виртуальной машины, создадим сервис: +2. Чтобы направить сетевой трафик на 80-й порт виртуальной машины, создайте сервис: ```yaml apiVersion: v1 @@ -156,9 +158,8 @@ spec: app: old ``` -Настройки меток виртуальной машины мы можем менять «на лету», то есть изменение меток не требует рестарта виртуальной машины, а это значит, что мы можем конфигурировать перенаправление сетевого трафика с разных сервисов динамически. - -Представим, что мы создали новый сервис и хотим перенаправить трафик на нашу виртуальную машину с него: +Можно изменять метки виртуальной машины без необходимости перезапуска, что позволяет настраивать перенаправление сетевого трафика между различными сервисами в реальном времени. +Предположим, что был создан новый сервис и требуется перенаправить трафик на виртуальную машину от этого сервиса: ```yaml apiVersion: v1 @@ -175,7 +176,7 @@ spec: app: new ``` -Изменив метки на виртуальной машине, мы перенаправим на нее сетевой трафик с сервиса `svc-2`: +Изменив метки на виртуальной машине, перенаправьте на нее сетевой трафик с сервиса `svc-2`: ```yaml metadata: @@ -185,16 +186,18 @@ metadata: # Как увеличить размер DVCR -Для увеличения размера нужно задать размер в конфигурации `moduleconfig` `virtualization` размер больший чем есть +Чтобы увеличить размер, необходимо установить больший размер в конфигурации модуля `virtualization`, чем текущий размер. -Посмотреть текущий размер dvcr +1. Проверьте текущий размер dvcr: + ```shell kubectl get mc virtualization -o jsonpath='{.spec.settings.dvcr.storage.persistentVolumeClaim}' #Output {"size":"58G","storageClassName":"linstor-thick-data-r1"} ``` -Задать размер +2. Задайте размер: + ```shell kubectl patch mc virtualization \ --type merge -p '{"spec": {"settings": {"dvcr": {"storage": {"persistentVolumeClaim": {"size":"59G"}}}}}}' @@ -202,7 +205,9 @@ kubectl patch mc virtualization \ #Output moduleconfig.deckhouse.io/virtualization patched ``` -Проверить изменение размера + +3. Проверьте изменение размера: + ```shell kubectl get mc virtualization -o jsonpath='{.spec.settings.dvcr.storage.persistentVolumeClaim}' #Output From e190802aeec11ce8f0e38f1c41d9f8b55634ea36 Mon Sep 17 00:00:00 2001 From: MariaMakeeva <156068662+MariaMakeeva@users.noreply.github.com> Date: Wed, 14 Feb 2024 11:36:35 +0300 Subject: [PATCH 3/6] Update README_RU.md Signed-off-by: MariaMakeeva <156068662+MariaMakeeva@users.noreply.github.com> --- docs/README_RU.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/docs/README_RU.md b/docs/README_RU.md index 2aec78550..e33f9860b 100644 --- a/docs/README_RU.md +++ b/docs/README_RU.md @@ -13,7 +13,7 @@ moduleStatus: experimental - Простой и интуитивно понятный интерфейс для декларативного создания и управления виртуальными машинами и их ресурсами. - Возможность запуска приложений, которые по каким-то причинам нельзя или сложно запустить в контейнере. - Возможность запуска виртуальных машин и контейнеризованных приложений в одном окружении. -- Интеграция с имеющейся экосистемой Deckhouse, позволяющая использовать ее возможности для виртуальных машин. +- Интеграцию с экосистемой Deckhouse, которая использует ее возможности для виртуальных машин. ## Требования @@ -24,14 +24,14 @@ moduleStatus: experimental - Модуль [CNI Cilium](/documentation/v1/modules/021-cni-cilium/) для обеспечения сетевой связности виртуальных машин. - Модули [SDS-DRBD](https://deckhouse.ru/modules/sds-drbd/stable/) или [CEPH-CSI](/documentation/v1/modules/031-ceph-csi/) для хранения данных виртуальных машин. Также возможно использовать другие варианты хранилищ, поддерживающие создание блочных устройств с режимом доступа `RWX` (`ReadWriteMany`). -## Что необходимо для включить модуль? +## Чтобы включить модуль Порядок действий для включения модуля -1. Настроить кластер deckhouse -2. Включить модуль CNI Cilium -3. Установить и настроить хранилище SDS-DRBD/CEPH/etc -4. Включить модуль virtualization +1. Настройте кластер deckhouse. +2. Включите модуль CNI Cilium. +3. Установите и настроите хранилище SDS-DRBD/CEPH/etc. +4. Включите модуль virtualization. ## Архитектура @@ -52,13 +52,16 @@ API предоставляет возможности для создания и Образы представляют собой неизменяемые ресурсы, которые позволяют создавать новые виртуальные машины на основе предварительно настроенных и сконфигурированных образов. В зависимости от типа, образы могут быть в форматах `raw`, `qcow2`, `vmdk` и других для образов дисков виртуальных машин, а также в формате `iso` для установочных образов, которые могут быть подключены как `cdrom-устройства`. -Для загрузки образов вы можете использовать внешние источники, такие как `HTTP-сервер`, `container registry`, а также локально через командную строку (`cli`). Также существует возможность создавать образы из дисков виртуальных машин, например при необходимости создания базового образа для тиражирования (`golden-image`). +Для загрузки образов можно использовать внешние источники, такие как `HTTP-сервер`, `container registry`, а также локальные источники через командную строку (`cli`). Также существует возможность создавать образы из дисков виртуальных машин, например, при необходимости создания базового образа для тиражирования (`golden-image`). -Важно отметить, что образы могут быть подключены к виртуальной машине только в режиме для чтения. +> Образы могут быть подключены к виртуальной машине только в режиме для чтения. -Образы бывают двух типов: кластерные `ClusterVirtualMachineImage`, которые доступны для всех пользователей платформы, и ограниченные по пространству имен `VirtualMachineImage`, которые доступны только для пользователей в рамках определенного `namespace`. +Образы бывают двух типов: -Для `ClusterVirtualMachineImage` образы хранятся только в `DVCR`, а для `VirtualMachineImage` вы можете использовать как `DVCR`, так и хранилище, предоставляемое платформой (`PVC`). +* кластерные `ClusterVirtualMachineImage`, которые доступны для всех пользователей платформы; +* ограниченные по пространству имен `VirtualMachineImage`, которые доступны только для пользователей в рамках определенного `namespace`. + +Для `ClusterVirtualMachineImage` образы хранятся только в `DVCR`, а для `VirtualMachineImage` можно использовать как `DVCR`, так и хранилище, предоставляемое платформой (`PVC`). ### Диски виртуальных машин @@ -74,7 +77,7 @@ Cоздание дисков для виртуальных машины обес Ресурс `VirtualMachine` отвечает за создание виртуальной машины и управления её жизненным циклом. Через конфигурацию `VirtualMachine` можно определить параметры виртуальной машины, такие как количество процессоров, объем оперативной памяти, подключаемые образы и диски, а также правила размещения на узлах платформы, аналогично тому, как это делается для подов. -Политика запуска виртуальной машины определяет ее состояние. Она может быть включена, выключена, либо управление состоянием может осуществляться вручную. При перезагрузке узла, на котором запущена виртуальная машина, она будет временно выселена с этого узла с использованием механизма «живой миграции» на другой свободный узел, который удовлетворяет правилам размещения. +Политика запуска виртуальной машины определяет ее состояние. Она может быть включена, выключена или управление состоянием может осуществляться вручную. Во время перезагрузки узла, на котором находится виртуальная машина, эта виртуальная машина будет автоматически перемещена с помощью механизма "живой миграции" на другой доступный узел, который соответствует правилам размещения. Виртуальная машина запускается внутри пода, что позволяет управлять виртуальными машинами как обычными ресурсами Kubernetes и использовать все возможности платформы, включая балансировщики нагрузки, сетевые политики, средства автоматизации и т. д. From c33300ec1eb99028a6df030d46ad22f3230b9da5 Mon Sep 17 00:00:00 2001 From: MariaMakeeva <156068662+MariaMakeeva@users.noreply.github.com> Date: Wed, 14 Feb 2024 11:59:27 +0300 Subject: [PATCH 4/6] Update doc-ru-config-values.yaml Signed-off-by: MariaMakeeva <156068662+MariaMakeeva@users.noreply.github.com> --- openapi/doc-ru-config-values.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openapi/doc-ru-config-values.yaml b/openapi/doc-ru-config-values.yaml index 2719c45e8..5b3ccbe5e 100644 --- a/openapi/doc-ru-config-values.yaml +++ b/openapi/doc-ru-config-values.yaml @@ -29,7 +29,7 @@ properties: - `Disabled` — доступ только по HTTP. - `OnlyInURI` — доступ по HTTP, подразумевая, что перед web-интерфейсом стоит внешний HTTPS-балансер, который терминирует HTTPS и все ссылки в `user-authn` будут генерироваться с HTTPS-схемой. certManager: - description: "Настройки для certmanager." + description: Настройки для certmanager. properties: clusterIssuerName: description: | From 9f116f5fcdfdb2ba1c4dc72ac8b18da81e1997c4 Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Wed, 14 Feb 2024 20:43:10 +0300 Subject: [PATCH 5/6] update Signed-off-by: Pavel Tishkov --- docs/EXAMPLES_RU.md | 17 ++++++++++------- docs/FAQ_RU.md | 20 +++++++++++++------- docs/README_RU.md | 14 ++++++++------ 3 files changed, 31 insertions(+), 20 deletions(-) diff --git a/docs/EXAMPLES_RU.md b/docs/EXAMPLES_RU.md index ba45ea4a3..6aac1e38e 100644 --- a/docs/EXAMPLES_RU.md +++ b/docs/EXAMPLES_RU.md @@ -105,7 +105,10 @@ dvp vnc -n vms linux-vm ## Образы -`VirtualMachineImage` и `ClusterVirtualMachineImage` используются для хранения образов виртуальных машин, представляющих собой диски виртуальных машин или ISO-образы с установочными файлами, с целью создания и тиражирования идентичных дисков виртуальных машин. При подключении к виртуальной машине эти образы доступны только для чтения, и установочный IS0-образ будет подключен в виде cdrom-устройства. +`VirtualMachineImage` и `ClusterVirtualMachineImage` используются для хранения образов виртуальных машин. +Образы могут быть следующих видов: +- Образ диска виртуальной машины, который предназначен для тиражирования идентичных дисков виртуальных машин. +- ISO-образ, содержащий файлы для установки ОС. Этот тип образа подключается к виртуальной машине как cdrom. Ресурс `VirtualMachineImage` доступен только в том пространстве имен, в котором был создан, а `ClusterVirtualMachineImage` доступен для всех пространств имен внутри кластера. @@ -273,7 +276,7 @@ https://virtualization.example.com/upload/dSJSQW0fSOerjH5ziJo4PEWbnZ4q6ffc -T ci После завершения работы команды `curl` образ должен быть создан. -4. Проверьте, что статус созданного образа успешен: +4. Проверьте, что статус созданного образа `Ready`: ```bash kubectl get clustervirtualmachineimages @@ -326,7 +329,7 @@ kubectl get virtualmachinedisk При создании ресурса диска можно указать желаемый размер. Если размер не указан, то будет создан диск с размером, соответствующим исходному образу диска, который хранится в ресурсе `VirtualMachineImage` или `ClusterVirtualMachineImage`. Если необходимо создать диск большего размера, укажите необходимый размер. -Используйте ранее созданный `ClusterVirtualMachineImage` с именем `ubuntu-2204` (приведено в качестве примера): +В качестве примера рассмотрен ранее созданный `ClusterVirtualMachineImage` с именем `ubuntu-2204`: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -353,7 +356,7 @@ kubectl patch ubuntu-root --type merge -p '{"spec":{"persistentVolumeClaim":{"si ### Подключение дисков к запущенным виртуальным машинам -Диски могут быть подключены в работающей виртуальной машине с использованием `VirtualMachineBlockDeviceAttachment` ресурса (приведенного в качестве примера): +Диски могут быть подключены в работающей виртуальной машине с использованием `VirtualMachineBlockDeviceAttachment` ресурса: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -523,7 +526,7 @@ spec: ### 3. Настройка порядка применения изменений -Внесенные изменения в конфигурацию виртуальной машины не отобразятся, так как по умолчанию применяется политика изменений `Manual`. Внесенные изменения изменения нужно подтвердить. +Внесенные изменения в конфигурацию виртуальной машины не отобразятся, так как по умолчанию применяется политика изменений `Manual`. Для применения изменений виртуальную машину требуется перезагрузить. 1. Чтобы проверить статус виртуальной машины, введите командую: @@ -531,7 +534,7 @@ spec: kubectl get linux-vm -o jsonpath='{.status}' ``` -В поле `.status.pendingChanges` отобразятся изменения, которые требуют подтверждения. +В поле `.status.pendingChanges` отобразятся изменения, которые требуют подтверждения. В поле `.status.message` появится сообщение: для применения изменений, необходимо перезапустить виртуальную машину. @@ -591,7 +594,7 @@ kubectl get virtualmachine # linux-vm Running node-name-x 10.66.10.1 5m ``` -Если виртуальная машина снова запустилась: +Виртуальная машина была перезапущена. Причина перезапуска: > В отличие от традиционных систем виртуализации, мы используем политику запуска для определения состояния виртуальной машины, которая определяет требуемое состояние виртуальной машины в любое время. diff --git a/docs/FAQ_RU.md b/docs/FAQ_RU.md index 0296a1a31..520dd7cfd 100644 --- a/docs/FAQ_RU.md +++ b/docs/FAQ_RU.md @@ -80,9 +80,9 @@ spec: name: win-disk ``` -После создания ресурса виртуальная машина будет запущена. К ней необходимо подключиться с помощью графического установщика. +После создания ресурса виртуальная машина будет запущена. К ней необходимо подключиться, и с помощью графического установщика выполнить установку ОС и драйверов `virtio`. -4. Добавьте драйверы `virtio` и выполните установку ОС: +Команда для подключения: ```bash dvp vnc -n default win-vm @@ -104,6 +104,12 @@ spec: name: win-disk ``` +8. После внесенных изменений виртуальная машина запустится, для продолжения работы с ней используйте команду: + +```bash +dvp vnc -n default win-vm +``` + ## Как создать образ виртуальной машины для container registry Образ диска виртуальной машины, хранящийся в container registry, должен быть сформирован специальным образом. @@ -176,7 +182,7 @@ spec: app: new ``` -Изменив метки на виртуальной машине, перенаправьте на нее сетевой трафик с сервиса `svc-2`: +При изменении метки на виртуальной машине, трафик с сервиса `svc-2` будет перенаправлен на виртуальную машину: ```yaml metadata: @@ -186,10 +192,10 @@ metadata: # Как увеличить размер DVCR -Чтобы увеличить размер, необходимо установить больший размер в конфигурации модуля `virtualization`, чем текущий размер. +Чтобы увеличить размер диска для DVCR, необходимо установить больший размер в конфигурации модуля `virtualization`, чем текущий размер. 1. Проверьте текущий размер dvcr: - + ```shell kubectl get mc virtualization -o jsonpath='{.spec.settings.dvcr.storage.persistentVolumeClaim}' #Output @@ -197,7 +203,7 @@ kubectl get mc virtualization -o jsonpath='{.spec.settings.dvcr.storage.persiste ``` 2. Задайте размер: - + ```shell kubectl patch mc virtualization \ --type merge -p '{"spec": {"settings": {"dvcr": {"storage": {"persistentVolumeClaim": {"size":"59G"}}}}}}' @@ -207,7 +213,7 @@ moduleconfig.deckhouse.io/virtualization patched ``` 3. Проверьте изменение размера: - + ```shell kubectl get mc virtualization -o jsonpath='{.spec.settings.dvcr.storage.persistentVolumeClaim}' #Output diff --git a/docs/README_RU.md b/docs/README_RU.md index e33f9860b..4705375ff 100644 --- a/docs/README_RU.md +++ b/docs/README_RU.md @@ -24,7 +24,7 @@ moduleStatus: experimental - Модуль [CNI Cilium](/documentation/v1/modules/021-cni-cilium/) для обеспечения сетевой связности виртуальных машин. - Модули [SDS-DRBD](https://deckhouse.ru/modules/sds-drbd/stable/) или [CEPH-CSI](/documentation/v1/modules/031-ceph-csi/) для хранения данных виртуальных машин. Также возможно использовать другие варианты хранилищ, поддерживающие создание блочных устройств с режимом доступа `RWX` (`ReadWriteMany`). -## Чтобы включить модуль +## Как включить модуль? Порядок действий для включения модуля @@ -52,16 +52,16 @@ API предоставляет возможности для создания и Образы представляют собой неизменяемые ресурсы, которые позволяют создавать новые виртуальные машины на основе предварительно настроенных и сконфигурированных образов. В зависимости от типа, образы могут быть в форматах `raw`, `qcow2`, `vmdk` и других для образов дисков виртуальных машин, а также в формате `iso` для установочных образов, которые могут быть подключены как `cdrom-устройства`. -Для загрузки образов можно использовать внешние источники, такие как `HTTP-сервер`, `container registry`, а также локальные источники через командную строку (`cli`). Также существует возможность создавать образы из дисков виртуальных машин, например, при необходимости создания базового образа для тиражирования (`golden-image`). +Для загрузки образов можно использовать внешние источники, такие как `HTTP-сервер`, `container registry`, а также загрузить локальный файл через командную строку (`cli`). Также существует возможность создавать образы из дисков виртуальных машин, например, при необходимости создания базового образа для тиражирования (`golden-image`). > Образы могут быть подключены к виртуальной машине только в режиме для чтения. -Образы бывают двух типов: +Образы бывают двух типов: * кластерные `ClusterVirtualMachineImage`, которые доступны для всех пользователей платформы; -* ограниченные по пространству имен `VirtualMachineImage`, которые доступны только для пользователей в рамках определенного `namespace`. +* ограниченные по пространству имен `VirtualMachineImage`, которые доступны только для пользователей `namespace`, в котором они созданы. -Для `ClusterVirtualMachineImage` образы хранятся только в `DVCR`, а для `VirtualMachineImage` можно использовать как `DVCR`, так и хранилище, предоставляемое платформой (`PVC`). +Все образы хранятся в `DVCR`. ### Диски виртуальных машин @@ -77,7 +77,9 @@ Cоздание дисков для виртуальных машины обес Ресурс `VirtualMachine` отвечает за создание виртуальной машины и управления её жизненным циклом. Через конфигурацию `VirtualMachine` можно определить параметры виртуальной машины, такие как количество процессоров, объем оперативной памяти, подключаемые образы и диски, а также правила размещения на узлах платформы, аналогично тому, как это делается для подов. -Политика запуска виртуальной машины определяет ее состояние. Она может быть включена, выключена или управление состоянием может осуществляться вручную. Во время перезагрузки узла, на котором находится виртуальная машина, эта виртуальная машина будет автоматически перемещена с помощью механизма "живой миграции" на другой доступный узел, который соответствует правилам размещения. +Политика запуска виртуальной машины определяет ее состояние. Она может быть всегда включена, выключена или управление состоянием может осуществляться вручную. + +При переводе узла кластера в режим обслуживания, работающая виртуальная машина будет автоматически перемещена на другой подходящий узел с помощью механизма "живой миграции". Виртуальная машина запускается внутри пода, что позволяет управлять виртуальными машинами как обычными ресурсами Kubernetes и использовать все возможности платформы, включая балансировщики нагрузки, сетевые политики, средства автоматизации и т. д. From 01b82bab4ae93e02a54e4e47cbd02fc79ce9fae4 Mon Sep 17 00:00:00 2001 From: Pavel Tishkov Date: Thu, 15 Feb 2024 08:57:01 +0300 Subject: [PATCH 6/6] update Signed-off-by: Pavel Tishkov --- docs/EXAMPLES_RU.md | 91 ++++++++++++++++++--------------------------- docs/README_RU.md | 13 ++++--- 2 files changed, 44 insertions(+), 60 deletions(-) diff --git a/docs/EXAMPLES_RU.md b/docs/EXAMPLES_RU.md index 6aac1e38e..5cded788e 100644 --- a/docs/EXAMPLES_RU.md +++ b/docs/EXAMPLES_RU.md @@ -32,7 +32,7 @@ spec: После создания `VirtualMachineDiks` в namespace vms, запустится под с именем `importer-*`, который осуществит загрузку заданного образа. -3. Посмотрите текущий статус ресурса с помощью комнады: +3. Посмотрите текущий статус ресурса с помощью команды: ```bash kubectl -n vms get virtualmachinedisk -o wide @@ -95,28 +95,22 @@ kubectl -n default get virtualmachine dvp console -n vms linux-vm ``` -7. Подключитесь к машине с использованием VNC: - -```bash -dvp vnc -n vms linux-vm -``` - -После выполнения команды запустится VNC-клиент, используемый в системе по умолчанию. Альтернативный способ подключения — с помощью параметра `--proxy-only` пробросить VNC-порт на локальную машину. - ## Образы `VirtualMachineImage` и `ClusterVirtualMachineImage` используются для хранения образов виртуальных машин. + Образы могут быть следующих видов: + - Образ диска виртуальной машины, который предназначен для тиражирования идентичных дисков виртуальных машин. - ISO-образ, содержащий файлы для установки ОС. Этот тип образа подключается к виртуальной машине как cdrom. -Ресурс `VirtualMachineImage` доступен только в том пространстве имен, в котором был создан, а `ClusterVirtualMachineImage` доступен для всех пространств имен внутри кластера. +Ресурс `VirtualMachineImage` доступен только в том пространстве имен, в котором был создан, а `ClusterVirtualMachineImage` доступен для всех пространств имен внутри кластера. Оба этих ресурсов хранят свои данные в `DVCR`. -В зависимости от конфигурации, ресурс `VirtualMachineImage` может хранить данные в `DVCR` или использовать дисковое хранилище, предоставляемое платформой (PV). `ClusterVirtualMachineImage` хранит данные только в `DVCR`, обеспечивая единый доступ ко всем образам для всех пространств имен в кластере. +Образы могут быть получены из различных источников, таких как HTTP-серверы, на которых расположены файлы образов, или контейнерные реестры (container registries), где образы сохраняются и становятся доступны для скачивания. Также существует возможность загрузить образы напрямую из командной строки, используя утилиту `curl`. ### Создание и использование образа c HTTP-ресурса -1. Создадайте `VirtualMachineImage` и в качестве хранилища образов используйте `DVCR`: +1. Создайте `VirtualMachineImage`: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -141,30 +135,7 @@ kubectl -n vms get virtualmachineimage # ubuntu-img Ready false 100% 10m ``` -Для хранения образа в дисковом хранилище, предоставляемом платформой, настройки `storage` будут выглядеть следующим образом: - -```yaml -spec: - storage: Kubernetes - persistentVolumeClaim: - storageClassName: "your-storage-class-name" -``` - -где `your-storage-class-name` — это название StorageClass, который будет использоваться. - -3. Для просмотра списка доступных StorageClass'ов выполните следующую команду: - -```bash -kubectl get storageclass - -# Пример вывода команды: -# NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE -# linstor-thin-r1 linstor.csi.linbit.com Delete WaitForFirstConsumer true 20d -# linstor-thin-r2 linstor.csi.linbit.com Delete WaitForFirstConsumer true 20d -# linstor-thin-r3 linstor.csi.linbit.com Delete WaitForFirstConsumer true 20d -``` - -Ресурс `ClusterVirtualMachineImage` создается по аналогии, но не требует указания настроек `storage`: +3. Ресурс `ClusterVirtualMachineImage` создается по аналогии, но не требует указания настроек `storage`: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -187,28 +158,26 @@ kubectl get clustervirtualmachineimage # ubuntu-img Ready false 100% 11m ``` -Образы могут быть получены из различных источников, таких как HTTP-серверы, на которых расположены файлы образов, или контейнерные реестры (container registries), где образы сохраняются и становятся доступны для скачивания. Также существует возможность загрузить образы напрямую из командной строки, используя утилиту `curl`. - ### Создание и использование образа из container registry 1. Cформируйте образ для хранения в `container registry`. -Ниже представлен пример создания docker-образа c диском Ubuntu 22.04. +Ниже представлен пример создания образа c диском Ubuntu 22.04. -* Загрузите образ локально: +- Загрузите образ локально: ```bash curl -L https://cloud-images.ubuntu.com/minimal/releases/jammy/release-20230615/ubuntu-22.04-minimal-cloudimg-amd64.img -o ubuntu2204.img ``` -* Создайте Dockerfile со следующим содержимым: +- Создайте Dockerfile со следующим содержимым: ```Dockerfile FROM scratch COPY ubuntu2204.img /disk/ubuntu2204.img ``` -* Соберите образ и загрузите его в `container registry`. В качестве `container registry` в примере ниже использован docker.io. для выполнения вам необходимо иметь учетную запись сервиса и настроенное окружение. +- Соберите образ и загрузите его в `container registry`. В качестве `container registry` в примере ниже использован docker.io. для выполнения вам необходимо иметь учетную запись сервиса и настроенное окружение. ```bash docker build -t docker.io/username/ubuntu2204:latest @@ -216,13 +185,13 @@ docker build -t docker.io/username/ubuntu2204:latest где `username` — имя пользователя, указанное при регистрации в docker.io. -* Загрузите созданный образ в `container registry` с помощью команды: +- Загрузите созданный образ в `container registry` с помощью команды: ```bash docker push docker.io/username/ubuntu2204:latest ``` -* Чтобы использовать этот образ, создайте в качестве примера ресурс `ClusterVirtualMachineImage`: +- Чтобы использовать этот образ, создайте в качестве примера ресурс `ClusterVirtualMachineImage`: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -236,7 +205,7 @@ spec: image: docker.io/username/ubuntu2204:latest ``` -* Чтобы посмотреть ресурс и его статус, выполните команду: +- Чтобы посмотреть ресурс и его статус, выполните команду: ```bash kubectl get clustervirtalmachineimage @@ -271,7 +240,12 @@ kubectl get clustervirtualmachineimages some-image -o json | jq .status.uploadCo ```bash curl -L http://download.cirros-cloud.net/0.5.1/cirros-0.5.1-x86_64-disk.img -o cirros.img -https://virtualization.example.com/upload/dSJSQW0fSOerjH5ziJo4PEWbnZ4q6ffc -T cirros.img +``` + +4. Выполните загрузку образа: + +```bash +curl https://virtualization.example.com/upload/dSJSQW0fSOerjH5ziJo4PEWbnZ4q6ffc -T cirros.img ``` После завершения работы команды `curl` образ должен быть создан. @@ -293,6 +267,11 @@ kubectl get clustervirtualmachineimages ```bash kubectl get storageclass + +# NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE +# linstor-thin-r1 linstor.csi.linbit.com Delete WaitForFirstConsumer true 27d +# linstor-thin-r2 linstor.csi.linbit.com Delete WaitForFirstConsumer true 27d +# linstor-thin-r3 linstor.csi.linbit.com Delete WaitForFirstConsumer true 27d ``` ### Создание пустого диска @@ -371,13 +350,15 @@ spec: name: vmd-blank # Имя подключаемого диска. ``` -Если в указанном ресурсе изменить имя виртуальной машины на имя другой виртуальной машины, диск будет перенаправлен от одной виртуальной машины к другой. При удалении ресурса `VirtualMachineBlockDeviceAttachment` диск от виртуальной машины будет отключен. Чтобы посмотреть список подключенных дисков в работающей виртуальной машине, выполните команду: ```bash kubectl get virtualmachineblockdeviceattachments + +# NAME PHASE +# vmd-blank-attachment Attached ``` ## Виртуальные машины @@ -392,7 +373,7 @@ kubectl get virtualmachineblockdeviceattachments ### Создание диска для виртуальной машины -Создайте диск с установыленной ОС для виртуальной машины: +Создайте диск с установленной ОС для виртуальной машины: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -489,7 +470,7 @@ kubectl get virtualmachine 2. Чтобы зафиксировать IP-адрес виртуальной машины перед ее запуском, выполните следующие шаги: -* Создайте ресурс `VirtualMachineIPAddressClaim`, в котором зафиксирован желаемый IP-адрес виртуальной машины: +- Создайте ресурс `VirtualMachineIPAddressClaim`, в котором зафиксирован желаемый IP-адрес виртуальной машины: ```yaml apiVersion: virtualization.deckhouse.io/v1alpha2 @@ -501,7 +482,7 @@ spec: address: "W.X.Y.Z" ``` -* Зафиксируйте изменения в спецификации виртуальной машины: +- Зафиксируйте изменения в спецификации виртуальной машины: ```yaml spec: @@ -545,7 +526,7 @@ cat < В отличие от традиционных систем виртуализации, мы используем политику запуска для определения состояния виртуальной машины, которая определяет требуемое состояние виртуальной машины в любое время. diff --git a/docs/README_RU.md b/docs/README_RU.md index 4705375ff..eec1fdd98 100644 --- a/docs/README_RU.md +++ b/docs/README_RU.md @@ -50,16 +50,19 @@ API предоставляет возможности для создания и ### Образы виртуальных машин и загрузочные образы -Образы представляют собой неизменяемые ресурсы, которые позволяют создавать новые виртуальные машины на основе предварительно настроенных и сконфигурированных образов. В зависимости от типа, образы могут быть в форматах `raw`, `qcow2`, `vmdk` и других для образов дисков виртуальных машин, а также в формате `iso` для установочных образов, которые могут быть подключены как `cdrom-устройства`. +Образы представляют собой неизменяемые ресурсы, которые позволяют создавать новые виртуальные машины на основе предварительно настроенных и сконфигурированных образов. В зависимости от типа, образы могут быть в форматах `raw`, `qcow2`, `vmdk` и других для образов дисков виртуальных машин, а также в формате `iso` для установочных образов. -Для загрузки образов можно использовать внешние источники, такие как `HTTP-сервер`, `container registry`, а также загрузить локальный файл через командную строку (`cli`). Также существует возможность создавать образы из дисков виртуальных машин, например, при необходимости создания базового образа для тиражирования (`golden-image`). +Для загрузки образов можно использовать внешние источники, такие как `HTTP-сервер`, `container registry`, а также загрузить локальный файл через командную строку (`cli`). -> Образы могут быть подключены к виртуальной машине только в режиме для чтения. +> Образы могут быть подключены к виртуальной машине. +> +> - ISO-образы - как `cdrom-устройства` и всегда доступны только в режиме для чтения (`ReadOnly`). +> - Образы дисков виртуальных машин - как эфимерные диски, после рестарта машины все записанные на них данные будут утеряны Образы бывают двух типов: -* кластерные `ClusterVirtualMachineImage`, которые доступны для всех пользователей платформы; -* ограниченные по пространству имен `VirtualMachineImage`, которые доступны только для пользователей `namespace`, в котором они созданы. +- кластерные `ClusterVirtualMachineImage`, которые доступны для всех пользователей платформы; +- ограниченные по пространству имен `VirtualMachineImage`, которые доступны только для пользователей `namespace`, в котором они созданы. Все образы хранятся в `DVCR`.