O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Instale o Trident em um cluster Red Hat OpenShift e crie objetos de storage

03/18/2026 Colaboradores

PDFs

Instale Trident com o Trident Operator certificado da Red Hat e crie objetos de storage para ONTAP e Amazon FSx for NetApp ONTAP para habilitar o provisionamento dinâmico de volumes para contêineres e VMs. Prepare os nós de trabalho para acesso a blocos quando necessário.

Antes de começar

Conclua os procedimentos desta página antes de instalar OpenShift Virtualization. OpenShift Virtualization requer um StorageClass padrão com suporte do Trident e um VolumeSnapshotClass padrão para criar imagens douradas para modelos de máquinas virtuais.
Se você já instalou OpenShift Virtualization antes de configurar Trident, exclua quaisquer imagens douradas criadas com uma classe de armazenamento diferente. Depois de definir Trident como padrão, OpenShift Virtualization recria as imagens douradas usando o storage Trident.
```
oc delete dv,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron
```

Passo 1: Instalar Trident

O operador Trident certificado pela Red Hat é compatível com NetApp para OpenShift em ambientes locais, nuvens públicas e serviços gerenciados como o ROSA. A partir do Trident 25.02, o operador também pode preparar nós de trabalho para iSCSI quando você usa Amazon FSx for NetApp ONTAP e planeja executar cargas de trabalho de VM de Virtualização do OpenShift.

Para outras opções de instalação, consulte "a documentação do Trident".

Passos

Em OperatorHub, selecione Certified NetApp Trident.

Mostrar exemplo
Na página Install, mantenha a versão mais recente e selecione Install.

Mostrar exemplo
Após a instalação do operador, selecione View operator e crie uma instância do Trident Orchestrator.

Se você deseja preparar nós de trabalho para iSCSI, mude para a visualização YAML e adicione iscsi a nodePrep.

Mostrar exemplo
Confirme que todos os pods do Trident estão em execução no cluster.

Mostrar exemplo
Se você habilitou a preparação do nó iSCSI, faça login nos nós de trabalho e verifique se iscsid e multipathd estão ativos e se multipath.conf tem entradas.

Mostrar exemplo

Mostrar exemplo

Mostrar exemplo

Demonstração em vídeo

O vídeo a seguir mostra uma demonstração da instalação do Trident usando o Trident Operator certificado pela Red Hat.

Instalando o Trident 25.02.1 usando o Trident Operator certificado no OpenShift

Etapa 2: Prepare o backend de armazenamento e os arquivos de configuração StorageClass para o seu ambiente

Crie definições de TridentBackendConfig e StorageClass para o seu ambiente. Você pode configurar vários protocolos de storage dentro do seu ambiente. Crie arquivos YAML para cada protocolo que deseja usar e substitua os valores de espaço reservado pelos seus detalhes específicos de configuração.

Preencha a seção on-premises ou ROSA abaixo, dependendo do seu ambiente, e prossiga para a Etapa 3.

Clusters locais OpenShift

Crie arquivos YAML para cada protocolo que você deseja configurar. Você pode configurar um ou mais dos seguintes protocolos: NAS para storage de arquivos baseado em NFS, iSCSI para storage em bloco iSCSI, NVMe/TCP para storage em bloco NVMe sobre TCP de alto desempenho ou FC para storage em bloco Fibre Channel.

NAS

Crie um TridentBackendConfig e StorageClass para ONTAP NAS para habilitar o provisionamento de storage persistente baseado em NFS. A configuração de backend inclui credenciais armazenadas em um segredo do Kubernetes e faz referência à sua ONTAP SVM e à LIF de gerenciamento.

Segredo do backend e arquivo de configuração (salvar como tbc-nas.yaml):

# tbc-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-nas-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas
  svm: zoneb #<replace with your SVM name>
  storagePrefix: testzoneb #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-nas-secret

StorageClass definição (salvar como sc-nas.yaml):

# sc-nas.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nas
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"
allowVolumeExpansion: true

iSCSI

Crie um TridentBackendConfig e StorageClass para ONTAP SAN para habilitar o provisionamento de storage em bloco baseado em iSCSI. A configuração do backend usa o driver ontap-san e inclui credenciais armazenadas em um segredo do Kubernetes.

Segredo do backend e arquivo de configuração (salvar como tbc-iscsi.yaml):

# tbc-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-iscsi-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <management LIF>
  backendName: ontap-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-iscsi-secret

StorageClass definition (salvar como sc-iscsi.yaml):

# sc-iscsi.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-iscsi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

NVMe/TCP

Crie um TridentBackendConfig e StorageClass para ONTAP SAN com NVMe sobre TCP para habilitar o provisionamento de storage de blocos de alto desempenho. A configuração do backend usa o driver ontap-san otimizado para transporte NVMe/TCP e inclui credenciais armazenadas em um segredo do Kubernetes.

Segredo do backend e arquivo de configuração (salvar como tbc-nvme.yaml):

# tbc-nvme.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-nvme-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nvme
spec:
  version: 1
  storageDriverName: ontap-san
  sanType: nvme
  managementLIF: <ONTAP management LIF>
  backendName: backend-tbc-ontap-nvme
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-nvme-secret

StorageClass definition (salvar como sc-nvme.yaml):

# sc-nvme.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nvme
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

Crie um TridentBackendConfig e StorageClass para ONTAP SAN com Fibre Channel para habilitar o provisionamento de storage em bloco baseado em FC. A configuração do backend usa o driver ontap-san com o protocolo FCP especificado e inclui credenciais armazenadas em um Kubernetes Secret.

Segredo do backend e arquivo de configuração (salvar como tbc-fc.yaml):

# tbc-fc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-fc-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-fc
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <ONTAP management LIF>
  backendName: tbc-fc
  svm: openshift-fc #<replace with your SVM name>
  sanType: fcp
  storagePrefix: demofc #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-fc-secret

StorageClass definição (salvar como sc-fc.yaml):

# sc-fc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-fc
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

Clusters ROSA com Amazon FSx for NetApp ONTAP

Crie arquivos YAML para cada protocolo que você deseja configurar. Você pode configurar um ou ambos os seguintes protocolos: NAS para storage de arquivos ou iSCSI para block storage.

NAS

Crie um TridentBackendConfig e StorageClass para Amazon FSx for NetApp ONTAP com ONTAP NAS para habilitar o provisionamento de storage persistente baseado em NFS em clusters ROSA. A configuração de backend usa nomes DNS do Amazon FSx for NetApp ONTAP para LIFs de gerenciamento e dados, e inclui credenciais armazenadas em um Secret do Kubernetes no namespace trident.

Segredo do backend e arquivo de configuração (salvar como tbc-fsx-nas.yaml):

# tbc-fsx-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-fsx-ontap-nas-secret
type: Opaque
stringData:
  username: <FSx for ONTAP, for example fsxadmin>
  password: <FSx for ONTAP password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-fsx-ontap-nas
spec:
  version: 1
  backendName: fsx-ontap
  storageDriverName: ontap-nas
  managementLIF: <Management DNS name>
  dataLIF: <NFS DNS name>
  svm: <SVM NAME>
  credentials:
    name: backend-fsx-ontap-nas-secret

StorageClass definition (salvar como sc-fsx-nas.yaml):

# sc-fsx-nas.yaml (storage class name is trident-csi)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: trident-csi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  fsType: "ext4"
allowVolumeExpansion: true
reclaimPolicy: Retain

iSCSI

Crie um TridentBackendConfig e StorageClass para Amazon FSx for NetApp ONTAP com ONTAP SAN para habilitar o provisionamento de storage baseado em blocos via iSCSI em clusters ROSA. A configuração de backend utiliza o driver ontap-san e inclui credenciais armazenadas em um Kubernetes Secret. Certifique-se de que os nós de trabalho estejam preparados para acesso iSCSI.

Segredo do backend e arquivo de configuração (salvar como tbc-fsx-iscsi.yaml):

# tbc-fsx-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-fsx-iscsi-secret
type: Opaque
stringData:
  username: <FSx for ONTAP, for example fsxadmin>
  password: <FSx for ONTAP password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: fsx-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <Management DNS name>
  backendName: fsx-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-fsx-iscsi-secret

StorageClass definição (salvar como sc-fsx-iscsi.yaml):

# sc-fsx-iscsi.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-fsx-iscsi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

Passo 3: criar um arquivo de configuração VolumeSnapshotClass

Crie uma definição de VolumeSnapshotClass para implantações locais e ROSA. Essa configuração permite operações baseadas em snapshots para volumes persistentes.

VolumeSnapshotClass definição (salvar como snapshot-class.yaml):

# snapshot-class.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: trident-snapshotclass
driver: csi.trident.netapp.io
deletionPolicy: Retain

Etapa 4: aplique os arquivos de configuração ao seu cluster

Aplique os arquivos de configuração que você criou nas etapas anteriores ao seu OpenShift cluster.

Passos

Aplique os arquivos TridentBackendConfig e StorageClass para cada protocolo que você configurou.

Para clusters locais:

oc create -f tbc-nas.yaml -n trident
oc create -f sc-nas.yaml

oc create -f tbc-iscsi.yaml -n trident
oc create -f sc-iscsi.yaml

oc create -f tbc-nvme.yaml -n trident
oc create -f sc-nvme.yaml

oc create -f tbc-fc.yaml -n trident
oc create -f sc-fc.yaml

Para clusters ROSA:

oc create -f tbc-fsx-nas.yaml -n trident
oc create -f sc-fsx-nas.yaml

oc create -f tbc-fsx-iscsi.yaml -n trident
oc create -f sc-fsx-iscsi.yaml

Aplique a configuração VolumeSnapshotClass.
```
oc create -f snapshot-class.yaml
```
Verifique se os recursos foram criados com sucesso.

Verifique os objetos TridentBackendConfig:
```
oc get tbc -n trident
```
Verifique os objetos StorageClass:
```
oc get storageclass
```
Verifique VolumeSnapshotClass:
```
oc get volumesnapshotclass
```

Etapa 5: defina as classes padrão de storage e snapshot do Trident

Defina o Trident StorageClass e VolumeSnapshotClass como padrões no cluster OpenShift. Isso é necessário para OpenShift Virtualization criar fontes de imagem golden para os templates de VM.

Passos

Defina o StorageClass padrão do Trident.

Defina um StorageClass com suporte Trident como padrão do cluster para que PersistentVolumeClaims o utilizem automaticamente quando nenhuma classe de armazenamento for especificada. Você precisa configurar duas anotações: uma para o padrão de todo o cluster e uma específica para OpenShift Virtualization.
1. Defina a anotação padrão StorageClass para todo o cluster.
  
  Certifique-se de que apenas um StorageClass esteja definido como padrão. Se outro StorageClass já estiver definido como padrão, defina sua anotação como falsa.
  
  No console, edite a anotação:
  storageclass.kubernetes.io/is-default-class: "true"
  A partir da linha de comando:
  kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
2. Defina a anotação padrão específica para OpenShift Virtualization.
  
  OpenShift Virtualization usa uma anotação específica que tem precedência sobre a anotação geral do cluster is-default-class. Se outra StorageClass já estiver definida como padrão, defina sua anotação como falsa.
  
  No console, edite a anotação:
  storageclass.kubevirt.io/is-default-virt-class: "true"
  A partir da linha de comando:
```
kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'
```
Defina o Trident VolumeSnapshotClass padrão.

Defina um VolumeSnapshotClass com suporte do Trident como padrão do cluster para habilitar operações baseadas em snapshots para volumes persistentes. Isso garante que VolumeSnapshots usem automaticamente o driver CSI do Trident quando nenhuma classe de snapshot for especificada e permite que a OpenShift Virtualization crie snapshots de imagens douradas.

Certifique-se de que apenas um VolumeSnapshotClass esteja definido como padrão. Se outro VolumeSnapshotClass já estiver definido como padrão, defina sua anotação como falsa.

No console, edite a anotação:
```
snapshot.storage.kubernetes.io/is-default-class: "true"
```
A partir da linha de comando:
```
oc patch volumesnapshotclass <snapshot class name> --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'
```

Instale o Trident em um cluster Red Hat OpenShift e crie objetos de storage

Creating your file...

Passo 1: Instalar Trident

Etapa 2: Prepare o backend de armazenamento e os arquivos de configuração StorageClass para o seu ambiente

Clusters locais OpenShift

Clusters ROSA com Amazon FSx for NetApp ONTAP

Passo 3: criar um arquivo de configuração VolumeSnapshotClass

Etapa 4: aplique os arquivos de configuração ao seu cluster

Etapa 5: defina as classes padrão de storage e snapshot do Trident