Воротарі з Red Hat OpenShift або Upstream Kubernetes
Zusammenfassung: У цій базі пояснюється, як використовувати репозиторій Red Hat GitHub kubevirt-rawio-addon для презентації PowerMax Gatekeepers у середовищі Red Hat OpenShift або Upstream Kubernetes.
Dieser Artikel gilt für
Dieser Artikel gilt nicht für
Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden.
In diesem Artikel werden nicht alle Produktversionen aufgeführt.
Weisungen
Воротарі PowerMax
PowerMax Gatekeeper — це невеликі пристрої (зазвичай три МБ), вирізані з дисків у PowerMax, які виконують роль SCSI-цілей для команд Solutions Enabler. Інформація про конфігурацію та статус зберігається у файлі бази даних PowerMax, symapi_db.bin за замовчуванням. Вона відома як база даних конфігурацій PowerMax. Це зменшує кількість запитів від хоста до масивів зберігання. Гейткіпери мають бути сирими пристроями, щоб ОС просто передавала SCSI-команди без маніпуляцій. Хоча фізичні хости завжди працюють із Gatekeeper (з підтримуваною ОС), віртуальні хости обмежені VMware з використанням фізичних сирих відображень пристроїв (RDM), in-Guest iSCSI на Windows або Linux, in-Guest NVMe/TCP у Linux або passthrough пристроями (NIC або HBA). Однак лише VMware може надати справжній сирий пристрій, який визнається життєздатним Gatekeeper. Інші рішення для віртуалізації дозволяють користувачу представляти пристрої як «сирі», але їхні рішення блокують деякі SCSI-команди, що не дозволяє їх використовувати як Gatekeeper. Solutions Enabler позначає їх як Gatekeepers, але повідомляє про помилку, як зазначено нижче.
Крім того, якщо подивитися на Gatekeepers, вони показують стан «CLS» або закритий.
Тому ви не можете передати необхідні SCSI-команди.
Щоб скористатися цим рішенням, потрібно використовувати протокол, який підтримує Solutions Enabler на обраній операційній системі. Будь ласка, ознайомтеся з документацією продукту.
Рішення Red Hat на GitHub
Dell звернулася до Red Hat з проханням допомогти розробити обхідний шлях для Gatekeepers у OpenShift-середовищі для деяких наших спільних клієнтів. З цією метою вони створили рішення, яке працює як для OpenShift, так і для Upstream Kubernetes з невеликими відмінностями у реалізації. Репозиторій GitHub називається kubevirt-rawio-addon, оскільки розташований тут: https://github.com/openshift-cnv/kubevirt-rawio-addon GitHub містить readme https://github.com/openshift-cnv/kubevirt-rawio-addon/blob/main/README.md.
Додаток встановлює кілька компонентів:
- Мутація вебхуків для модифікації об'єктів на льоту
- Валідація вебхука — спеціалізована для OpenShift перевірка безпеки
- конфігурація безпеки для забезпечення привілейованих можливостей
- Гачок для сайдкару
Сайдкар — це невеликий додатковий контейнер, який працює поруч із VM pod і змінює низькорівневу конфігурацію VM перед запуском. Він перехоплює конфігурацію віртуальної машини, створену KubeVirt, знаходить анотовані диски та встановлює rawio=yes. KubeVirt потім повертає XML. Архітектура libvirt/QEMU підтримує це, але не відкриває, тому потрібна ця незначна корекція. Можливо, KubeVirt викриє це в майбутньому, і тоді обхідний шлях стане зайвим.
Реалізація на OpenShift
Репозиторій містить усі інструкції для реалізації цього рішення. Оскільки рішення належить Red Hat, Dell рекомендує дотримуватися чинних інструкцій, які можуть змінюватися в майбутньому. Dell не оновлює базу знань з урахуванням цих змін. З люб'язності ми надаємо базову інформацію нижче, але заохочуємо користувачів цієї бази знань використовувати її разом із репозиторієм.
Як зазначалося, це можна реалізувати на OpenShift або Upstream Kubernetes. Як кроки для OpenShift, є кілька важливих моментів, якщо ви обираєте Upstream Kubernetes.
- Якщо ви впроваджуєте це на стандартних K8s, у вас має бути встановлений cert-manager. Якщо встановлено драйвер PowerMax CSI, то він присутній.
- Якщо ви реалізуєте на ванільних K8, вам потрібен привілейований простір імен. Ви можете використовувати простір імен у скриптах або створити власний, а потім змінити скрипти.
Два скрипти, які потрібні для реалізації, знаходяться у папці hack . rawio-setup.sh — це перший скрипт, і він однаковий для обох платформ, але майте на увазі, що він базується на просторі назв openshift-cnv, який присутній лише на OpenShift. Додайте простір імен або створіть новий і змініть скрипт для K8s. Скрипт створення віртуальної машини унікальний для платформи, але знову ж таки використовує простір імен openshift-cnv. Для OpenShift це rawio-create-vm-openshift.sh. Скрипти розроблені для створення тестового середовища і потребуватимуть модифікації для виробництва. Зокрема, скрипт rawio-setup.sh створює віртуальний SCSI-пристрій. Натомість модифікуйте скрипт, щоб використовувати ваш клас зберігання PowerMax. Крім того, скрипт передбачає наявність одного вузла для планування віртуальної машини. Модифікуйте його, щоб він працював на будь-якому робочому вузлі. Скрипт використовує попередню ОС Fedora.
Зразки сценаріїв містяться у додатковому контенті.
Основні кроки
- Клонуйте репозиторій: git clonehttps://github.com/openshift-cnv/kubevirt-rawio-addon.git
- Встановіть маніфест: oc apply -fhttps://github.com/openshift-cnv/kubevirt-rawio-addon/releases/download/v0.1.0/rawio-addon-openshift.yaml
- Встановити sidecar: oc annotate –overwrite -n openshift-cnv hco kubevirt-hyperconverged kubevirt.kubevirt.io/jsonpatch='[{"op": «додати», «шлях»: "/spec/configuration/developerConfiguration/featureGates/-", "value": "Sidecar"}]'
- Запусти налаштування: rawio-setup.sh
- Створити віртуальну машину: rawio-create-vm-openshift.sh
- Встановіть свою ОС (якщо ви не використовуєте готову)
Майте на увазі, що PowerMax CSI не може створити пристрій менше 50 МБ, навіть якщо ви просите традиційний Gatekeeper на 3 МБ. Це не створює проблем.
Інші рішення для віртуалізації
Жодне з наведених нижче рішень не працює з цим репозиторієм Red Hat.
- Рішення на базі K8s, такі як SUSE Harvester - SUSE повинні розробити власне рішення
- KVM-рішення, такі як Proxmox або Oracle KVM (oVirt) — вони не базуються на KubeVirt і не використовуються
Weitere Informationen
rawio-setup.sh
#!/bin/bash
set -euo pipefail
якщо [ -z "${KUBEVIRT_NAMESPACE:-}" ]; тоді
якщо kubectl отримує ns openshift-cnv &>/dev/null; тоді
NAMESPACE="openshift-cnv"
інше
NAMESPACE="kubevirt"
Fi
інше
SPACESPACE="$KUBEVIRT_NAMESPACE"
Fi
PVC_NAMESPACE="${PVC_NAMESPACE:-default}"
SC_NAME="powermax-2164-за замовчуванням"
PVC_NAME="SCSI-Rawio-PVC"
# Створити простір назв, якщо його немає
kubectl get ns "$PVC_NAMESPACE" >/dev/null 2>&1 || kubectl create ns "$PVC_NAMESPACE"
# Створіть ПВХ
echo "Створення PVC $PVC_NAME у просторі імен $PVC_NAMESPACE..."
kubectl apply -f - <<EOF
apiVersion: v1
Доброзичливий: PersistentVolumeClaim
Метадані:
Ім'я: $PVC_ІМ'Я
Простір назв: $PVC_ПРОСТОР ІМЕН
Специфікація:
storageClassName: $SC_ІМ'Я
volumeMode: Блок
accessModes:
- ReadWriteOnce
Ресурси:
Запити:
Зберігання: 8 миль
EOF
відлуння ""
echo "=== Налаштування завершено ==="
відлуння «СкладКлас: $SC_ІМ'Я»
ехо: «ПВХ: $PVC_NAMESPACE/$PVC_NAME"
відлуння ""
*******************************************
rawio-create-vm-openshift.sh
#!/bin/bash
set -euo pipefail
PVC_NAMESPACE="${PVC_NAMESPACE:-default}"
PVC_NAME="${PVC_NAME:-scsi-rawio-pvc}"
VM_NAME="${VM_NAME:-rawio-test-vm}"
VM_SA="${VM_SA:-rawio-vm}"
CONTAINER_DISK="${CONTAINER_DISK:-quay.io/kubevirt/fedora-with-testtooling:v20240717-a087e7e}"
SCC_NAME="${SCC_NAME:-rawio-vm}"
KUBEVIRT_NAMESPACE="openshift-CNV"
echo "Створення ServiceAccount $VM_SA у просторі імен $PVC_NAMESPACE"
kubectl apply -f - <<EOF
apiVersion: v1
Доброзичливий: ServiceAccount
Метадані:
Ім'я: $VM_SA
Простір назв: $PVC_ПРОСТОР ІМЕН
EOF
echo "Створення SCC $SCC_NAME для сервісного облікового запису $VM_SA"
kubectl apply -f - <<EOF
apiVersion: security.openshift.io/v1
Доброзичливий: SecurityContextConstraints
Метадані:
Ім'я: $SCC_ІМ'Я
Пріоритет: 11
allowPrivilegedContainer: false
allowHostDirVolumePlugin: true
allowHostNetwork: неправда
allowHostPorts: false
allowHostPID: неправда
allowHostIPC: неправда
дозволеніМожливості:
- NET_BIND_SERVICE
- SYS_NICE
- SYS_RAWIO
- SETFCAP
defaultДодатиМожливості: []
seccompProfiles:
- Виконання/за замовчуванням
- необмежений
- localhost/kubevirt/kubevirt.json
Томи:
- "*"
readOnlyRootFilesystem: false
runAsUser:
Тип: RunAsAny
seLinuxКонтекст:
Тип: RunAsAny
fsGroup:
Тип: RunAsAny
Додаткові групи:
Тип: RunAsAny
Користувачі:
- system:serviceaccount:${PVC_NAMESPACE}:${VM_SA}
Групи: []
EOF
echo "Створення VM $VM_NAME у просторі імен $PVC_NAMESPACE"
ехо: «ПВХ: $PVC_ІМ'Я»
echo "ServiceAccount: $VM_SA"
ехо: «Контейнерний диск: $CONTAINER_ДИСК»
kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
Доброзичливий: VirtualMachine
Метадані:
Ім'я: $VM_ІМ'Я
Простір назв: $PVC_ПРОСТОР ІМЕН
Анотації:
kubevirt.io/rawioSupport: "Lun0"
Специфікація:
Біг: Правда
Шаблон:
Метадані:
Анотації:
kubevirt.io/rawioSupport: "Lun0"
Специфікація:
Домен:
CPU:
Ядра: 2
Ресурси:
Запити:
Пам'ять: 2Gi
Пристрої:
RNG: {}
Диски:
- ім'я: disk0
Диск:
Автобус: Віртіо
- ім'я: Lun0
Лун:
Автобус: SCSI
-Ім'я: $VM_SA
Диск:
Автобус: Віртіо
Томи:
- ім'я: disk0
containerDisk:
Зображення: $CONTAINER_ДИСК
- ім'я: Lun0
persistentVolumeClaim:
claimName: $PVC_ІМ'Я
-Ім'я: $VM_SA
serviceAccount:
serviceAccountName: $VM_SA
EOF
відлуння ""
echo "VM $VM_NAME створено. Чекаю, поки почнеться..."
echo "Watch with: kubectl get vmi -n $PVC_NAMESPACE $VM_NAME -w"
відлуння: «Консоль: virtctl console -n $PVC_NAMESPACE $VM_NAME"
відлуння ""
повторює "Cleanup:"
echo " kubectl видалити vm -n $PVC_NAMESPACE $VM_NAME"
echo " kubectl видалити SCC $SCC_NAME"
Betroffene Produkte
PowerMax, PowerMax, PowerMax 2000, PowerMax 2500, PowerMax 8000, PowerMax 8500, PowerMaxOS 10Artikeleigenschaften
Artikelnummer: 000472526
Artikeltyp: How To
Zuletzt geändert: 03 Juni 2026
Version: 1
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.