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 NetApp Trident em um cluster VKS

09/01/2026 Colaboradores

PDFs

Instale o NetApp Trident como o provisionador de storage dinâmico no seu cluster do vSphere Kubernetes Service para integrar o storage NetApp ONTAP às suas cargas de trabalho do Kubernetes.

Antes de começar

Certifique-se de que o seu cluster ONTAP esteja configurado e conectado ao seu ambiente VMware Kubernetes.
Certifique-se de que seu cluster VKS tenha as ferramentas iSCSI ou NVMe instaladas caso suas cargas de trabalho utilizem esses protocolos para storage.
Certifique-se de ter kubectl instalado em uma máquina a partir da qual você possa se conectar ao cluster VKS usando o arquivo kubeconfig.

Passos

Instale o Trident Operator usando um Helm chart, seguindo as instruções na documentação do Trident:

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

Antes de executar a instalação do Helm, crie e rotule o trident namespace. O enforce=privileged rótulo é necessário porque o Trident executa cargas de trabalho privilegiadas. Sem ele, o controlador de admissão de segurança de pods do Kubernetes impedirá que os pods do Trident sejam iniciados.
```
kubectl create namespace trident
kubectl label namespace trident pod-security.kubernetes.io/enforce=privileged
```
Mostrar exemplo
helm install trident netapp-trident/trident-operator --version 100.2606.0 --namespace trident
Para ativar o registro de depuração, adicione --set tridentDebug=true:
helm install trident netapp-trident/trident-operator --version 100.2606.0 --namespace trident --set tridentDebug=true
Você também pode instalar o Trident manualmente usando o Trident Operator. Revise os procedimentos na documentação do Trident: "Implante manualmente o Trident Operator"

Certifique-se de ter atribuído os rótulos de segurança de pod necessários ao `trident`namespace antes de instalar o Trident manualmente.

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

Mostrar exemplo

kubectl get pods -n trident

Se os pods do Trident não iniciarem com um erro de admissão PodSecurity, os rótulos de segurança do pod podem não ter sido aplicados ao namespace trident antes da instalação. Use --overwrite para reaplicá-los e, em seguida, verifique se os pods iniciam.

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

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

Configure um backend Trident para o ONTAP definindo os detalhes de conexão e os parâmetros de storage necessários.
Defina classes de armazenamento no Kubernetes que correspondam aos backends de armazenamento NetApp. Essas classes especificam parâmetros como características de desempenho e políticas de replicação.

Defina os backends e as classes de armazenamento do Trident para os seguintes protocolos, conforme exigido pelas suas cargas de trabalho:
- NAS (driver ontap-nas)
- NAS Economy (driver ontap-nas-economy)
- SAN (driver ontap-san) para os protocolos iSCSI, FC ou NVMe
- SAN Economy (driver ontap-san-economy) para iSCSI
  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 Secret do Kubernetes e faz referência à sua ONTAP SVM e à LIF de gerenciamento.
  
  Exemplo de segredo do backend e arquivo de configuração do backend usando autenticação por nome de usuário e senha (salve como 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
  
  Exemplo de segredo do backend e arquivo de configuração do backend usando autenticação por certificado de cliente (salve como 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 definição (salvar como sc-nas.yaml):
  mountOptions é um parâmetro opcional que especifica opções de montagem adicionais para volumes NFS. A opção nconnect permite múltiplas conexões TCP paralelas para uma única montagem NFS, o que pode melhorar o desempenho em cargas de trabalho de alta taxa de transferência. O valor padrão é 1, mas pode ser aumentado até o máximo permitido pelo sistema ONTAP.

O ONTAP suporta até 16 conexões para uma única montagem NFS em um cliente compatível com nconnect. O Trident passa as opções de montagem diretamente para os nós de trabalho do Kubernetes, então escolha um valor compatível tanto com o cliente NFS do nó de trabalho quanto com o ONTAP; o exemplo a seguir usa quatro conexões.

# 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

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

Exemplo de segredo do backend e arquivo de configuração do backend usando autenticação por nome de usuário e senha (salve como 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 definição (salvar como 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

Crie um TridentBackendConfig e um StorageClass para o ONTAP SAN com iSCSI 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. O parâmetro sanType assume o protocolo iSCSI por padrão se omitido.

Segredo do backend e arquivo de configuração do backend usando autenticação por nome de usuário e senha (salve como 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

Segredo do backend e arquivo de configuração do backend usando autenticação por certificado de cliente (salve como 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 definição (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

Crie um TridentBackendConfig e um StorageClass para o ONTAP SAN com NVMe para habilitar o provisionamento de storage em bloco baseado em NVMe. A configuração do backend usa o driver ontap-san e inclui credenciais armazenadas em um Kubernetes Secret. O sanType parâmetro deve ser definido como nvme.

Segredo do backend e arquivo de configuração do backend usando autenticação por nome de usuário e senha (salve como 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

Segredo do backend e arquivo de configuração do backend usando autenticação por certificado de cliente (salve como 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 definição (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

Consulte a documentação do Trident para obter exemplos adicionais de arquivos YAML e informações sobre os modos de acesso e os modos de volume suportados pelos drivers SAN e NAS.

Crie um arquivo de configuração VolumeSnapshotClass

Crie uma definição de VolumeSnapshotClass. Essa configuração habilita 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

Aplique os arquivos de configuração ao seu cluster

Aplique os arquivos de configuração que você criou nas etapas anteriores ao cluster do serviço Kubernetes vSphere usando kubectl. Isso cria os segredos necessários, as configurações de backend, as classes de armazenamento e a classe de snapshot em seu cluster.

Passos

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

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

Verifique se os recursos foram criados com sucesso.

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

Defina as classes padrão de armazenamento e snapshot do Trident

Defina o Trident StorageClass e VolumeSnapshotClass como padrão no cluster do serviço Kubernetes do vSphere.

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.

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 false.

A partir da linha de comando:
```
kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-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.

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 false.

A partir da linha de comando:
```
kubectl patch volumesnapshotclass <snapshot class name> --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'
```

Use as Persistent Volume Claims do Kubernetes para solicitar storage para cargas de trabalho

O Trident provisiona automaticamente os volumes necessários a partir do storage de backend NetApp. Consulte "Implante cargas de trabalho com storage persistente" para exemplos de implantação de uma carga de trabalho com PVCs em um cluster VKS.

Instale o NetApp Trident em um cluster VKS

Creating your file...

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

Crie um arquivo de configuração VolumeSnapshotClass

Aplique os arquivos de configuração ao seu cluster

Defina as classes padrão de armazenamento e snapshot do Trident

Use as Persistent Volume Claims do Kubernetes para solicitar storage para cargas de trabalho