Gatekeepers com Red Hat OpenShift ou Kubernetes upstream

Zusammenfassung: Este artigo da KB explica como usar o repositório kubevirt-rawio-addon do Red Hat GitHub para apresentar gatekeepers do PowerMax a um ambiente Red Hat OpenShift ou upstream do 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 Gatekeepers

Os gatekeepers do PowerMax são pequenos dispositivos (normalmente três MBs) esculpidos em discos no PowerMax que atuam como destinos SCSI para comandos do Solutions Enabler. As informações de configuração e status são mantidas em um arquivo de banco de dados do host do PowerMax symapi_db.bin por padrão. Ele é conhecido como o banco de dados de configuração do PowerMax. Reduz o número de consultas do host aos storage arrays. Os gatekeepers devem ser dispositivos brutos para que o sistema operacional simplesmente passe os comandos SCSI sem manipulação. Embora os hosts físicos sempre funcionem com gatekeepers (com um sistema operacional compatível), os hosts virtuais são limitados ao VMware usando RDMs (Physical Raw Device Mappings, mapeamentos de dispositivos brutos), iSCSI em guest no Windows ou Linux, NVMe/TCP em guest no Linux ou dispositivos de passagem (NIC ou HBA). No entanto, somente a VMware pode apresentar um dispositivo bruto verdadeiro que seja reconhecido como um gatekeeper viável. Outras soluções de virtualização permitem que o usuário apresente dispositivos como "brutos", mas suas soluções bloqueiam alguns comandos SCSI, impedindo seu uso como Gatekeepers. O Solutions Enabler os rotula como Gatekeepers, mas relata um erro conforme abaixo.

Além disso, se você examinar os gatekeepers, eles mostrarão um estado "CLS" ou "closed".

Portanto, você não pode passar os comandos SCSI necessários.

Para aproveitar essa solução, você deve usar um protocolo compatível com o Solutions Enabler no sistema operacional escolhido. Consulte a documentação do produto.

Solução Red Hat GitHub

A Dell solicitou a assistência da Red Hat para desenvolver uma solução temporária para Gatekeepers em um ambiente OpenShift para alguns de nossos clientes mútuos. Para isso, eles criaram uma solução que funciona para o OpenShift e o Upstream Kubernetes com pequenas variações na implementação. O repositório do GitHub é chamado de kubevirt-rawio-addon conforme está localizado aqui: https://github.com/openshift-cnv/kubevirt-rawio-addon O GitHub inclui um readme https://github.com/openshift-cnv/kubevirt-rawio-addon/blob/main/README.md.

O complemento instala vários componentes:

  • Webhooks mutantes para modificar objetos em tempo real
  • Validando webhook: uma verificação de segurança específica do OpenShift
  • Configuração de segurança para permitir recursos privilegiados
  • Gancho do sidecar 

O sidecar é um pequeno contêiner extra que é executado junto com o pod da VM e modifica a configuração de baixo nível da VM antes de iniciar. Ele intercepta a configuração de VM gerada pelo KubeVirt, localiza os discos anotados e define rawio=yes. KubeVirt então recebe de volta o XML. A arquitetura subjacente libvirt/QEMU suporta isso, mas não a expõe, então esse pequeno ajuste é necessário. É possível que o KubeVirt exponha isso no futuro, quando a solução alternativa será desnecessária.


  

Implementação no OpenShift

O repositório contém todas as instruções para implementar essa solução. Como a Red Hat é proprietária da solução, a Dell recomenda seguir as instruções atuais, que estão sujeitas a alterações no futuro.  A Dell não atualizará a base de conhecimento para refletir essas alterações. Como cortesia, fornecemos as informações básicas abaixo, mas encorajamos os usuários desta KB a usá-las junto ao repositório.

Como observado, você pode implementar isso no OpenShift ou no Kubernetes upstream. Como as etapas são para o OpenShift, há alguns itens importantes se você fizer o Kubernetes upstream.

  • Se você implementar em baunilha K8s, você deve ter cert-manager instalado. Se o driver CSI do PowerMax estiver instalado, isso estará presente.
  • Se você implementar em baunilha K8s, você precisará de um namespace privilegiado. Você pode usar o namespace nos scripts ou criar o seu próprio e, em seguida, modificar os scripts.

Os dois scripts que você precisa para a implementação estão na pasta hack. O rawio-setup.sh é o primeiro script e é o mesmo para qualquer uma das plataformas, mas lembre-se de que ele depende do namespace openshift-cNV, que só está presente no OpenShift. Adicione o namespace ou crie um novo e modifique o script para K8s. O script de criação da VM é exclusivo da plataforma, mas, novamente, usa o namespace openshift-cnv. Para OpenShift, é rawio-create-vm-openshift.sh. Os scripts são projetados para criar um ambiente de teste e precisarão de modificação para uma configuração de produção. Em particular, o script rawio-setup.sh cria um dispositivo SCSI virtual. Em vez disso, modifique o script para usar sua classe de armazenamento do PowerMax. Além disso, o script pressupõe um único nó para programar a VM. Modificá-lo para permitir que ele seja executado em qualquer nó de trabalho. O script usa um sistema operacional Fedora pré-buit.

Os scripts de exemplo estão em Conteúdo suplementar.

Etapas básicas

Lembre-se de que o CSI do PowerMax não pode criar um dispositivo menor que 50 MB, mesmo que você solicite um gatekeeper tradicional de 3 MB. Isso não causa nenhum problema.

Outras soluções de virtualização

Nenhuma das soluções abaixo funciona com esse repositório Red Hat.

  • Soluções baseadas em K8s, como SUSE Harvester - a SUSE deve desenvolver sua própria solução
  • Soluções KVM como Proxmox ou Oracle KVM (oVirt) - não são baseadas em Kubert e não podem ser usadas



 

Weitere Informationen

rawio-setup.sh

 

#!/bin/bash

 

set -euo pipefail

 

se [ -z "${KUBEVIRT_NAMESPACE:-}" ]; Então
  Se kubectl get ns openshift-cnv &>/dev/null; então
    NAMESPACE="openshift-cnv"
  Mais
    NAMESPACE="kubevirt"
  fi
Mais
  NAMESPACE="$KUBEVIRT_NAMESPACE"
fi

 

PVC_NAMESPACE="${PVC_NAMESPACE:-default}"
SC_NAME="powermax-2164-default"
PVC_NAME="scsi-rawio-pvc"

 

# Crie namespace se ele não existir
kubectl get ns "$PVC_NAMESPACE" >/dev/null 2>&1 || kubectl create ns "$PVC_NAMESPACE"

 

# Criar PVC
echo "Criando PVC $PVC_NAME no namespace $PVC_NAMESPACE..."

 

kubectl apply -f - <<EOF
apiVersion: v1
Tipo: InsistentVolumeClaim
Metadados:
  name: $PVC_NOME
  Namespace: $PVC_NAMESPACE
Especificação:
  storageClassName: $SC_NOME
  volumeMode: Bloquear
  accessModes:
    - ReadWriteOnce
  Recursos:
    Solicitações:
      Armazenamento: 8Mi
EOF

 

eco ""
echo "=== Configuração concluída ==="
echo "StorageClass:   $SC_NOME"
echo "PVC:            $PVC_NAMESPACE/$PVC_NAME"
eco ""
 

*******************************************

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 "Criando ServiceAccount $VM_SA no namespace $PVC_NAMESPACE"

 

kubectl apply -f - <<EOF
apiVersion: v1
Tipo: Serviceaccount
Metadados:
  name: $VM_SA
  Namespace: $PVC_NAMESPACE
EOF

 

echo "Criando SCC $SCC_NAME para a conta de serviço $VM_SA"

 

kubectl apply -f - <<EOF
apiVersion: security.openshift.io/v1
Tipo: SecurityContextConstraints
Metadados:
  name: $SCC_NOME
Prioridade: 11
allowPrivilegedContainer: falso
allowHostDirVolumePlugin: verdadeiro
allowHostNetwork: falso
allowHostPorts: falso
allowHostPID: falso
allowHostIPC: falso
Capacidades permitidas:
  - NET_BIND_SERVICE
  - SYS_NICE
  - SYS_RAWIO
  - SETFCAP
defaultAddCapabilities: []
seccompProfiles:
  - tempo de execução/padrão
  - desconfinado
  - localhost/kubevirt/kubevirt.json
Volumes:
  - "*"
readOnlyRootFilesystem: falso
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
fsGroup:
  type: RunAsAny
suplementarGrupos:
  type: RunAsAny
Usuários:
  - Sistema:ServiceAccount:${PVC_NAMESPACE}:${VM_SA}
groups: []
EOF

 

echo "Criando VM $VM_NAME no namespace $PVC_NAMESPACE"
echo "PVC:               $PVC_NOME"
echo "ServiceAccount:    $VM_SA"
echo "Disco de contêiner:    $CONTAINER_DISCO"

 

kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
Tipo: Máquina virtual
Metadados:
  name: $VM_NOME
  Namespace: $PVC_NAMESPACE
  Anotações:
    kubevirt.io/rawioSupport: "LUN0"
Especificação:
  Em execução: true
  Modelo:
    Metadados:
      Anotações:
        kubevirt.io/rawioSupport: "LUN0"
    Especificação:
      Domínio:
        Cpu:
          Núcleos: 2
        Recursos:
          Solicitações:
            Memória: 2Gi
        Dispositivos:
          Rng: {}
          Discos:
            - Nome: Disk0
              Disco:
                Ônibus: Virtio
            - Nome: LUN0
              Lun:
                Ônibus: SCSI
            -Nome: $VM_SA
              Disco:
                Ônibus: Virtio
      Volumes:
        - Nome: Disk0
          containerDisk:
            Imagem: $CONTAINER_DISCO
        - Nome: LUN0
          persistentVolumeClaim:
            Nome da reivindicação: $PVC_NOME
        -Nome: $VM_SA
          Serviceaccount:
            serviceAccountName: $VM_SA
EOF

 

eco ""
echo "VM $VM_NAME created. Esperando começar..."
echo "Assista com: kubectl get vmi -n $PVC_NAMESPACE $VM_NAME -w"
echo "Console:    virtctl console -n $PVC_NAMESPACE $VM_NAME"
eco ""
echo "Limpeza:"
echo " kubectl delete vm -n $PVC_NAMESPACE $VM_NAME"
echo " kubectl delete scc $SCC_NAME"

Betroffene Produkte

PowerMax, PowerMax, PowerMax 2000, PowerMax 2500, PowerMax 8000, PowerMax 8500, PowerMaxOS 10
Artikeleigenschaften
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.