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

Installa NetApp Trident in un cluster VKS

09/01/2026 Collaboratori

PDF

Installa NetApp Trident come provisioner di storage dinamico nel tuo cluster vSphere Kubernetes Service per integrare lo storage NetApp ONTAP con i tuoi carichi di lavoro Kubernetes.

Prima di iniziare

Assicurati che il tuo ONTAP cluster sia configurato e connesso al tuo ambiente VMware Kubernetes.
Assicurati che il tuo cluster VKS abbia gli strumenti iSCSI o NVMe installati se i tuoi carichi di lavoro utilizzeranno questi protocolli per lo storage.
Assicurati di avere kubectl installato su una macchina dalla quale puoi connetterti al cluster VKS utilizzando il file kubeconfig.

Passaggi

Installa l'operatore Trident utilizzando un chart Helm seguendo le istruzioni nella documentazione di Trident:

"https://docs.netapp.com/us-en/trident/trident-install/kubernetes-deploy-helm.html"

Prima di eseguire l'installazione di Helm, crea e assegna l'etichetta al trident namespace. L'etichetta enforce=privileged è necessaria perché Trident esegue carichi di lavoro privilegiati. Senza di essa, il controller di ammissione alla sicurezza dei pod di Kubernetes bloccherà l'avvio dei pod di Trident.
```
kubectl create namespace trident
kubectl label namespace trident pod-security.kubernetes.io/enforce=privileged
```
Mostra esempio
helm install trident netapp-trident/trident-operator --version 100.2606.0 --namespace trident
Per abilitare la registrazione di debug, aggiungi --set tridentDebug=true:
helm install trident netapp-trident/trident-operator --version 100.2606.0 --namespace trident --set tridentDebug=true
Puoi anche installare Trident manualmente usando il Trident Operator. Consulta la documentazione di Trident per le procedure: "Distribuisci manualmente l'operatore Trident"

Assicurati di aver assegnato al namespace trident le etichette di sicurezza del pod richieste prima di installare Trident manualmente.

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

Mostra esempio

kubectl get pods -n trident

Se i pod di Trident non si avviano a causa di un errore di PodSecurity`ammissione, potrebbe essere che le etichette di sicurezza dei pod non siano state applicate allo `trident`namespace prima dell'installazione. Usa `--overwrite per riapplicarle, poi verifica che i pod si avviino.

kubectl label namespace trident pod-security.kubernetes.io/enforce=privileged --overwrite

Prepara i file di backend dello storage e di configurazione StorageClass per il tuo ambiente

Configura un backend Trident per ONTAP definendo i dettagli di connessione e i parametri di storage necessari.
Definisci classi di storage in Kubernetes che mappano i backend di storage NetApp. Queste classi specificano parametri come le caratteristiche prestazionali e le politiche di replica.

Definisci i backend e le classi di storage Trident per i seguenti protocolli, in base alle esigenze dei tuoi carichi di lavoro:
- NAS (driver ontap-nas)
- NAS Economy (driver ontap-nas-economy)
- SAN (driver ontap-san) per iSCSI, FC o protocolli NVMe
- SAN Economy (driver ontap-san-economy) per iSCSI
  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 namespace: trident type: Opaque data: username: "<base64-encoded cluster admin username>" password: "<base64-encoded cluster admin password>" --- 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: <your SVM name> storagePrefix: <your prefix for all volume names created using this backend configuration> 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 key value> --- 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: <your SVM name> storagePrefix: <your prefix for all volume names created using this backend configuration> credentials: name: ontap-nas-secret clientCertificate: <client certificate>
  
  StorageClass definition (salva come sc-nas.yaml):
  mountOptions è un parametro opzionale che specifica opzioni di montaggio aggiuntive per i volumi NFS. L'opzione nconnect consente più connessioni TCP parallele per un singolo mount NFS, il che può migliorare le prestazioni per carichi di lavoro ad alto throughput. Il valore predefinito è 1, ma può essere aumentato fino al massimo consentito dal sistema ONTAP.

ONTAP supporta fino a 16 connessioni per un singolo mount NFS su un client compatibile con nconnect. Trident passa le opzioni di mount direttamente ai nodi worker di Kubernetes, quindi scegli un valore supportato sia dal client NFS del nodo worker che da ONTAP; l'esempio seguente utilizza quattro connessioni.

# 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
mountOptions:
- nconnect=4

Crea un TridentBackendConfig e una StorageClass per il driver ONTAP NAS Economy per abilitare il provisioning dello 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
  namespace: trident
type: Opaque
data:
  username: "<base64-encoded cluster admin username>"
  password: "<base64-encoded cluster admin password>"
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas-economy
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas-economy
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas-eco
  svm: <your SVM name>
  storagePrefix: <your prefix for all volume names created using this backend configuration>
  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"
allowVolumeExpansion: true
mountOptions:
- nconnect=4

Crea un TridentBackendConfig e una 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 predefinito è il protocollo iSCSI se omesso.

Segreto del backend e file di configurazione del backend che utilizzano l'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
  namespace: trident
type: Opaque
data:
  username: "<base64-encoded cluster admin username>"
  password: "<base64-encoded cluster admin password>"
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-iscsi
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <ONTAP management LIF>
  backendName: ontap-iscsi
  svm: <your 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
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-iscsi
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <ONTAP management LIF>
  backendName: ontap-iscsi
  svm: <your 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

Crea un TridentBackendConfig e un StorageClass per ONTAP SAN con NVMe per abilitare il provisioning dello storage a blocchi basato su NVMe. La configurazione del backend utilizza il driver ontap-san e include le credenziali memorizzate in un Secret di Kubernetes. Il sanType parametro deve essere impostato su nvme.

Segreto del backend e file di configurazione del backend che utilizzano l'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
  namespace: trident
type: Opaque
data:
  username: "<base64-encoded cluster admin username>"
  password: "<base64-encoded cluster admin password>"
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-nvme
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san
  sanType: nvme
  managementLIF: <ONTAP management LIF>
  backendName: ontap-nvme
  svm: <your 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
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-nvme
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san
  sanType: nvme
  managementLIF: <ONTAP management LIF>
  backendName: ontap-nvme
  svm: <your 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

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.

Crea un file di configurazione VolumeSnapshotClass

Crea una definizione VolumeSnapshotClass. 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

Applica i file di configurazione al tuo cluster

Applica i file di configurazione che hai creato nei passaggi precedenti al cluster vSphere Kubernetes Service usando kubectl. Questo crea i segreti necessari, le configurazioni di backend, le classi di storage e la classe snapshot nel tuo cluster.

Passaggi

Applica i file TridentBackendConfig e StorageClass per ciascun protocollo configurato.

kubectl apply -f tbc-nas.yaml -n trident
kubectl apply -f sc-nas.yaml

kubectl apply -f tbc-nas-economy.yaml -n trident
kubectl apply -f sc-nas-economy.yaml

kubectl apply -f tbc-iscsi.yaml -n trident
kubectl apply -f sc-iscsi.yaml

kubectl apply -f tbc-nvme.yaml -n trident
kubectl apply -f sc-nvme.yaml

kubectl apply -f snapshot-class.yaml

Verificare che le risorse siano state create correttamente.

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

Imposta le classi di storage e snapshot predefinite di Trident

Imposta Trident StorageClass e VolumeSnapshotClass come predefiniti nel cluster vSphere.

Passaggi

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.

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

Dalla CLI:
```
kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-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 le VolumeSnapshots utilizzino automaticamente il driver CSI Trident quando non viene specificata alcuna classe di snapshot.

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

Dalla CLI:
```
kubectl patch volumesnapshotclass <snapshot class name> --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'
```

Utilizza Kubernetes Persistent Volume Claims per richiedere storage per i carichi di lavoro

Trident esegue automaticamente il provisioning dei volumi necessari dallo storage NetApp di backend. Consulta "Distribuisci i carichi di lavoro con storage persistente" per esempi di distribuzione di un carico di lavoro con PVC in un cluster VKS.

Installa NetApp Trident in un cluster VKS

Creating your file...

Prepara i file di backend dello storage e di configurazione StorageClass per il tuo ambiente

Crea un file di configurazione VolumeSnapshotClass

Applica i file di configurazione al tuo cluster

Imposta le classi di storage e snapshot predefinite di Trident

Utilizza Kubernetes Persistent Volume Claims per richiedere storage per i carichi di lavoro