La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Installare Trident su un cluster OpenShift e creare oggetti di storage

07/14/2026 Collaboratori

PDF

Installa Trident con il Red Hat Certified Trident Operator e crea oggetti di storage per ONTAP e Amazon FSx for NetApp ONTAP per abilitare il provisioning dinamico dei volumi per container e VM. Prepara i nodi worker per l'accesso a blocchi quando richiesto.

Prima di iniziare

Completa le procedure in questa pagina prima di installare OpenShift Virtualization. OpenShift Virtualization richiede un StorageClass predefinito basato su Trident e un VolumeSnapshotClass per creare immagini golden per i template delle VM.
Se hai già installato OpenShift Virtualization prima di configurare Trident, elimina tutte le golden images create con una classe di storage diversa. Dopo aver impostato Trident come predefinito, OpenShift Virtualization ricrea le golden images utilizzando lo storage Trident.
```
oc delete dv,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron
```

Passaggio 1: installa Trident

L'operatore Trident certificato da Red Hat è supportato da NetApp per OpenShift on-premises, nei cloud pubblici e nei servizi gestiti come ROSA. A partire da Trident 25.02, l'operatore può anche preparare i nodi worker per iSCSI quando si utilizza Amazon FSx for NetApp ONTAP e si prevede di eseguire carichi di lavoro VM di OpenShift Virtualization.

Per altre opzioni di installazione, vedere "la documentazione di Trident".

Passi

In OperatorHub, seleziona Certified NetApp Trident.

Mostra esempio
Nella pagina Install, mantieni la versione più recente e seleziona Install.

Mostra esempio
Dopo l'installazione dell'operatore, selezionare View operator e creare un'istanza di Trident Orchestrator.

Se vuoi preparare i nodi worker per iSCSI, passa alla visualizzazione YAML e aggiungi iscsi a nodePrep.

Mostra esempio
Verificare che tutti i pod di Trident siano in esecuzione nel cluster.

Mostra esempio
Se hai abilitato la preparazione del nodo iSCSI, accedi ai nodi worker e verifica che iscsid e multipathd siano attivi e che multipath.conf abbia delle voci.

Mostra esempio

Mostra esempio

Mostra esempio

Dimostrazione video

Il seguente video mostra una dimostrazione dell'installazione di Trident utilizzando il Red Hat Certified Trident Operator.

Installazione di Trident 25.02.1 utilizzando l'operatore Trident certificato in OpenShift

Passaggio 2: Preparare i file di backend dello storage e di configurazione di StorageClass per il proprio ambiente

Crea le definizioni di TridentBackendConfig e StorageClass per il tuo ambiente. Puoi configurare più protocolli di storage all'interno del tuo ambiente. Crea file YAML per ogni protocollo che desideri utilizzare e sostituisci i valori segnaposto con i dettagli specifici della tua configurazione.

Completa la sezione relativa all'ambiente locale o ROSA riportata di seguito in base al tuo ambiente, quindi procedi al passaggio 3.

Cluster OpenShift locali

Crea file YAML per ogni protocollo che desideri configurare. Puoi configurare uno o più dei seguenti protocolli: NAS per file storage basato su NFS, iSCSI per storage a blocchi iSCSI, NVMe/TCP per storage a blocchi NVMe over TCP dalle performance elevate o FC per storage a blocchi Fibre Channel.

Crea un TridentBackendConfig e StorageClass per ogni protocollo. La configurazione del backend include le credenziali memorizzate in un Secret di Kubernetes.

Linee guida essenziali per le opzioni di base della configurazione del backend

I file di configurazione del backend fanno riferimento al tuo ONTAP SVM e al management LIF. +
Puoi usare nome utente e password per autenticarti con ONTAP. Può trattarsi del nome utente e della password dell'amministratore del cluster o dell'amministratore del vserver. +
Puoi anche usare un certificato client per l'autenticazione con ONTAP. Per dettagli su come generare il certificato client, la chiave privata e il certificato CA, consulta "Documentazione di Trident qui".

Linee guida essenziali per le opzioni di configurazione del backend per il driver NAS economy

Per la configurazione del driver NAS economy è possibile includere i seguenti parametri:

qtreesPerFlexvol Il valore deve essere compreso tra 50 e 300, il valore predefinito è 200. +
limitVolumePoolSize Il valore è la dimensione massima di FlexVol che richiedi quando usi i qtree nel backend ontap-nas-economy. Non è impostato alcun valore predefinito e questo parametro non viene applicato per impostazione predefinita. Se imposti questo parametro, l'operatore Trident crea un nuovo FlexVol quando quello corrente FlexVol raggiunge la dimensione specificata. Questo parametro può aiutarti a controllare l'utilizzo della capacità nel tuo cluster limitando la dimensione dei FlexVols usati per il provisioning dei PV. +
denyNewVolumePools Questo parametro impedisce ai backend ontap-nas-economy di creare nuovi FlexVol volumi per contenere i loro qtree. Solo i FlexVol preesistenti vengono utilizzati per il provisioning di nuovi PV.

Linee guida essenziali per le opzioni di configurazione del backend per il driver SAN

Per la configurazione del driver SAN puoi includere i seguenti parametri:

limitVolumeSize Il valore è la dimensione massima del volume che richiedi quando usi il backend SAN. Non è impostato alcun valore predefinito e questo parametro non viene applicato per impostazione predefinita. Se imposti questo parametro, l'operatore Trident non esegue il provisioning se la dimensione del volume richiesta supera questo valore. Puoi usare questo parametro per limitare la dimensione massima dei volumi che gestisce per le LUN. +
lunsPerFlexvol Numero massimo di LUN per FlexVol, deve essere compreso nell'intervallo [50, 200], il valore predefinito è 100. Se imposti questo parametro, l'operatore Trident crea un nuovo FlexVol quando quello corrente FlexVol raggiunge il numero di LUN specificato. Questo parametro può aiutarti a controllare l'utilizzo della capacità nel tuo cluster limitando il numero di LUN per FlexVol utilizzati per il provisioning dei PV.

Linee guida essenziali per le opzioni di configurazione del backend per il driver SAN economy

Per la configurazione del SAN economy driver è possibile includere i seguenti parametri:

limitVolumePoolSize Il valore è la dimensione massima di FlexVol che richiedi quando usi il backend SAN economy. Non è impostato alcun valore predefinito e questo parametro non viene applicato per impostazione predefinita. Se imposti questo parametro, l'operatore Trident limita la dimensione massima del flexvol che può essere creata per la creazione di LUN nel flexvol. Questo parametro può aiutarti a controllare l'utilizzo della capacità nel tuo cluster limitando la dimensione delle FlexVols usate per il provisioning dei PV. +
denyNewVolumePools Questo parametro impedisce ai backend SAN economy di creare nuovi FlexVol volumi per contenere i propri LUN. Solo i FlexVol preesistenti vengono utilizzati per il provisioning di nuovi PV.

Linee guida essenziali per le opzioni di configurazione del backend per il provisioning dei volumi

Nei file yaml di esempio forniti per ciascun protocollo, se storagePrefix non viene specificato, viene utilizzato il prefisso predefinito "trident". Quando usi ontap-nas-economy e un storagePrefix di 24 o più caratteri, i qtree non avranno il prefisso di storage incorporato, anche se sarà presente nel nome del volume.

Quando crei un volume in ONTAP direttamente da System Manager o dalla CLI, senza fornire valori per tutti i parametri opzionali, alcuni valori predefiniti vengono impostati automaticamente durante il provisioning di un volume come mostrato di seguito.

Crea un volume in ONTAP

valori predefiniti per i parametri di volume

Ecco un esempio di volume creato utilizzando la configurazione backend di Trident. Non presenta opzioni impostate esplicitamente nella sezione delle impostazioni predefinite, ad eccezione del modello di nome.

oc describe tbc -n trident tbc-nas
### output truncated for brevity
Spec:
  Backend Name:  tbc-nas
  Credentials:
    Name:  tbc-nas-secret
  Defaults: # There are no defaults set except for the volume name template.
    Name Template:      {{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}
  Management LIF:       10.192.102.50
  Storage Driver Name:  ontap-nas
  Storage Prefix:       testautomation
  Svm:                  oc-test-automation

Quando il volume viene creato utilizzando questa configurazione di backend, le opzioni che non sono impostate nel file di configurazione del backend vengono impostate sui valori predefiniti come mostrato di seguito.

Volume creato utilizzando la configurazione backend di Trident

Tuttavia, quando imposti i valori nella sezione predefinita della configurazione del backend di Trident, puoi creare volumi che possono avere valori specifici per quei parametri. Nell'esempio seguente, snapshotPolicy è impostato sulla policy predefinita (è none se non imposti nulla esplicitamente) e snapshotDir è impostato su true nella sezione predefinita del file di configurazione yaml del backend. Con queste impostazioni, puoi vedere che il volume del backend ottiene quei valori. (snapdir-access è true e snapshot-policy è default)

sezione predefinita con valori espliciti

imposta esplicitamente i valori snapshotDir e snapshotPolicy nella configurazione del backend

imposta esplicitamente i valori snapshotDir e snapshotPolicy nel volume

Per tutti gli altri parametri aggiuntivi, consulta la documentazione di Trident:

NAS

Crea un TridentBackendConfig e un StorageClass per ONTAP NAS per abilitare il provisioning di storage persistente basato su NFS. La configurazione del backend include le credenziali memorizzate in un Secret di Kubernetes e fa riferimento al tuo ONTAP SVM e al LIF di gestione.

Esempio di segreto del backend e file di configurazione con metodo di autenticazione tramite nome utente e password (salva come 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

Esempio di segreto del backend e file di configurazione che utilizza l'autenticazione tramite certificato client (salva come tbc-nas.yaml):

# tbc-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: ontap-nas-secret
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas
  namespace: trident
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>
  credentials:
    name: ontap-nas-secret
  clientCertificate: <client certificate>

StorageClass definition (salva come 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

NAS economy

Crea un TridentBackendConfig e un StorageClass per il driver ONTAP NAS economy per abilitare il provisioning di storage persistente basato su NFS utilizzando i qtree. La configurazione del backend include le credenziali memorizzate in un Secret di Kubernetes e fa riferimento al tuo ONTAP SVM e al LIF di gestione.

Esempio di segreto del backend e file di configurazione con metodo di autenticazione tramite nome utente e password (salva come tbc-nas-economy.yaml):

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

StorageClass definition (salva come sc-nas-economy.yaml):

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

Consulta la sezione "Linee guida essenziali per le opzioni di configurazione del backend per il driver NAS economy" sopra per i dettagli sui parametri aggiuntivi che puoi includere nel file di configurazione del backend per il driver ontap-nas-economy.

iSCSI SAN

Crea un TridentBackendConfig e un StorageClass per ONTAP SAN con iSCSI per abilitare il provisioning dello storage a blocchi basato su iSCSI. La configurazione del backend utilizza il driver ontap-san e include le credenziali memorizzate in un Secret di Kubernetes. Il parametro sanType utilizza per impostazione predefinita il protocollo iSCSI se omesso.

Segreto del backend e file di configurazione del backend che utilizzano il metodo di autenticazione tramite nome utente e password (salva come 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

Segreto del backend e file di configurazione del backend che utilizzano il metodo di autenticazione tramite certificato client (salva come tbc-iscsi.yaml):

# tbc-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-iscsi-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
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
  clientCertificate: <client certificate>

StorageClass definition (salva come 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 SAN

Crea una TridentBackendConfig e una StorageClass per ONTAP SAN con NVMe su TCP per abilitare il provisioning di storage a blocchi dalle performance elevate. La configurazione del backend utilizza il driver ontap-san ottimizzato per il trasporto NVMe/TCP e include le credenziali memorizzate in un Secret di Kubernetes.

Segreto del backend e file di configurazione del backend che utilizzano il metodo di autenticazione tramite nome utente e password (salva come 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

Segreto del backend e file di configurazione del backend che utilizzano il metodo di autenticazione tramite certificato client (salva come tbc-nvme.yaml):

# tbc-nvme.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-nvme-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
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
  clientCertificate: <client certificate>

StorageClass definition (salva come 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

Se prevedi di usare i volumi ReadWriteMany (RWX) con il protocollo NVMe, un singolo volume RWX NVMe non può essere montato da più di 64 nodi in un cluster Kubernetes. Per maggiori informazioni su questa limitazione e sui dettagli del modello Super-subsystem introdotto in Trident 26.02 e del modello Per-volume subsystem precedente a Trident 26.02, consulta la documentazione di Trident: https://docs.netapp.com/us-en/trident/trident-use/ontap-san-prep.html#nvme-tcp-considerations.

FC SAN

Crea una TridentBackendConfig e una StorageClass per ONTAP SAN con Fibre Channel per abilitare il provisioning dello storage a blocchi basato su FC. La configurazione del backend utilizza il driver ontap-san con il protocollo FCP specificato e include le credenziali memorizzate in un Secret di Kubernetes.

Usa il metodo di autenticazione username/password o il metodo di autenticazione con certificato client per autenticarti con ONTAP. Per dettagli su come generare il certificato client, la chiave privata e il certificato CA, consulta "Documentazione di Trident qui". Qui sotto trovi esempi per entrambi i metodi.

Mostra esempio

Segreto del backend e file di configurazione del backend che utilizzano il metodo di autenticazione ONTAP con nome utente e password (salva come 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

Segreto del backend e file di configurazione del backend che utilizzano il metodo di autenticazione tramite certificato client (salva come tbc-fc.yaml):

# tbc-fc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-fc-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
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
  clientCertificate: <client certificate>

# 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

Economia SAN iSCSI

Crea un TridentBackendConfig e un StorageClass per ONTAP SAN economy con iSCSI per abilitare il provisioning dello storage a blocchi basato su iSCSI. La configurazione del backend utilizza il driver ontap-san-economy con il protocollo iSCSI e include le credenziali memorizzate in un Secret di Kubernetes.

Segreto del backend e file di configurazione del backend che utilizzano il metodo di autenticazione tramite certificato client (salva come tbc-san-eco.yaml):

# tbc-san-eco.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: ontap-san-cert-auth
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-san-eco-cert
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san-economy
  managementLIF: "<ONTAP management LIF>"
  backendName: tbc_san_eco
  svm: <replace with your SVM name>
  storagePrefix: <replace with your prefix>
  credentials:
    name: ontap-san-cert-auth
  clientCertificate: <client certificate>

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

Consulta la documentazione di Trident per ulteriori esempi di file yaml e informazioni sulle modalità di accesso e sulle modalità di volume supportate dai driver SAN e NAS.

Cluster ROSA con Amazon FSx for NetApp ONTAP

Crea file YAML per ogni protocollo che desideri configurare. Puoi configurare uno o entrambi i seguenti protocolli: NAS per file storage basato su NFS o iSCSI per storage a blocchi.

NAS

Crea un TridentBackendConfig e un StorageClass per Amazon FSx for NetApp ONTAP con ONTAP NAS per abilitare il provisioning di storage persistente basato su NFS sui cluster ROSA. La configurazione del backend utilizza i nomi DNS di Amazon FSx for NetApp ONTAP per le LIF di gestione e dati, e include le credenziali memorizzate in un Secret di Kubernetes nel namespace trident.

Segreto del backend e file di configurazione del backend (salva come 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 (salva come 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

Crea una TridentBackendConfig e una StorageClass per Amazon FSx for NetApp ONTAP con ONTAP SAN per abilitare il provisioning dello storage a blocchi basato su iSCSI sui cluster ROSA. La configurazione del backend utilizza il driver ontap-san e include le credenziali memorizzate in un Secret di Kubernetes. Assicurati che i nodi worker siano predisposti per l'accesso iSCSI.

Segreto del backend e file di configurazione del backend (salva come 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 definition (salva come 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

Passaggio 3: Creare un file di configurazione VolumeSnapshotClass

Crea una definizione VolumeSnapshotClass sia per le implementazioni on-premises che per quelle ROSA. Questa configurazione abilita le operazioni basate su snapshot per i volumi persistenti.

VolumeSnapshotClass definition (salva come 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

Passaggio 4: applica i file di configurazione al tuo cluster

Applica i file di configurazione che hai creato nei passaggi precedenti al tuo OpenShift cluster.

Passi

Applica i file TridentBackendConfig e StorageClass per ciascun protocollo configurato.

Per i cluster on-premises:

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

oc create -f tbc-nas-economy.yaml -n trident
oc create -f sc-nas-economy.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

Per i cluster 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

Applica la configurazione VolumeSnapshotClass.
```
oc create -f snapshot-class.yaml
```
Verificare che le risorse siano state create correttamente.

Controlla gli oggetti TridentBackendConfig:
```
oc get tbc -n trident
```
Controlla gli oggetti StorageClass:
```
oc get storageclass
```
Verifica VolumeSnapshotClass:
```
oc get volumesnapshotclass
```

Passaggio 5: Imposta le classi di storage e snapshot predefinite di Trident

Imposta StorageClass e VolumeSnapshotClass di Trident come predefiniti nel cluster OpenShift. Questo è necessario affinché OpenShift Virtualization crei sorgenti di immagini golden per i template delle VM.

Passi

Imposta il StorageClass predefinito di Trident.

Imposta una StorageClass supportata da Trident come predefinita del cluster, in modo che le PersistentVolumeClaims la utilizzino automaticamente quando non viene specificata alcuna classe di storage. È necessario configurare due annotazioni: una per l'impostazione predefinita a livello di cluster e una specifica per la virtualizzazione OpenShift.
1. Imposta l'annotazione StorageClass predefinita a livello di cluster.
  
  Assicurati che solo uno StorageClass sia impostato come predefinito. Se un altro StorageClass è già impostato come predefinito, imposta la relativa annotazione su false.
  
  Nella console, modifica l'annotazione:
  storageclass.kubernetes.io/is-default-class: "true"
  Dalla CLI:
  kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
2. Imposta l'annotazione predefinita specifica per la OpenShift Virtualization.
  
  OpenShift Virtualization utilizza un'annotazione specifica che ha la precedenza sull'annotazione generale del cluster is-default-class. Se un'altra StorageClass è già impostata come predefinita, imposta la relativa annotazione su false.
  
  Nella console, modifica l'annotazione:
  storageclass.kubevirt.io/is-default-virt-class: "true"
  Dalla CLI:
```
kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'
```
Imposta la VolumeSnapshotClass predefinita di Trident.

Imposta un VolumeSnapshotClass supportato da Trident come predefinito del cluster per abilitare le operazioni basate su snapshot per i volumi persistenti. Questo garantisce che i VolumeSnapshots utilizzino automaticamente il driver CSI Trident quando non viene specificata alcuna classe di snapshot e consente a OpenShift Virtualization di creare snapshot di immagini golden.

Assicurati che solo un VolumeSnapshotClass sia impostato come predefinito. Se un altro VolumeSnapshotClass è già impostato come predefinito, imposta la relativa annotazione su false.

Nella console, modifica l'annotazione:
```
snapshot.storage.kubernetes.io/is-default-class: "true"
```
Dalla CLI:
```
oc patch volumesnapshotclass <snapshot class name> --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'
```

Installare Trident su un cluster OpenShift e creare oggetti di storage

Creating your file...

Passaggio 1: installa Trident

Passaggio 2: Preparare i file di backend dello storage e di configurazione di StorageClass per il proprio ambiente

Cluster OpenShift locali

Cluster ROSA con Amazon FSx for NetApp ONTAP

Passaggio 3: Creare un file di configurazione VolumeSnapshotClass

Passaggio 4: applica i file di configurazione al tuo cluster

Passaggio 5: Imposta le classi di storage e snapshot predefinite di Trident