Skip to main content
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.

Prepare-se para configurar um backend com drivers ONTAP NAS.

Colaboradores netapp-aruldeepa

Compreenda os requisitos, as opções de autenticação e as políticas de exportação para configurar um backend ONTAP com drivers ONTAP NAS.

Requisitos

  • Para todos os backends ONTAP , o Trident exige que pelo menos um agregado seja atribuído à SVM.

  • Você pode executar mais de um driver e criar classes de armazenamento que apontem para um ou outro. Por exemplo, você poderia configurar uma classe Gold que usa o ontap-nas motorista e uma classe Bronze que usa o ontap-nas-economy um.

  • Todos os seus nós de trabalho do Kubernetes devem ter as ferramentas NFS apropriadas instaladas. Consulte"aqui" para mais detalhes.

  • O Trident suporta volumes SMB montados em pods executados apenas em nós Windows. Consulte Prepare-se para provisionar volumes SMB para mais detalhes.

Autenticar o backend ONTAP

O Trident oferece dois modos de autenticação de um backend ONTAP .

  • Baseado em credenciais: Este modo requer permissões suficientes no backend do ONTAP . Recomenda-se usar uma conta associada a uma função de login de segurança predefinida, como: admin ou vsadmin Para garantir a máxima compatibilidade com as versões do ONTAP .

  • Baseado em certificado: Este modo requer um certificado instalado no servidor para que o Trident se comunique com um cluster ONTAP . Aqui, a definição do backend deve conter os valores codificados em Base64 do certificado do cliente, da chave e do certificado da CA confiável, se utilizado (recomendado).

Você pode atualizar os sistemas de backend existentes para alternar entre métodos baseados em credenciais e métodos baseados em certificados. No entanto, apenas um método de autenticação é suportado por vez. Para mudar para um método de autenticação diferente, você deve remover o método existente da configuração do backend.

Aviso Se você tentar fornecer tanto credenciais quanto certificados, a criação do backend falhará com um erro informando que mais de um método de autenticação foi fornecido no arquivo de configuração.

Ativar autenticação baseada em credenciais

O Trident requer as credenciais de um administrador com escopo de SVM/cluster para se comunicar com o backend do ONTAP . Recomenda-se o uso de funções padrão predefinidas, como: admin ou vsadmin . Isso garante a compatibilidade futura com versões futuras do ONTAP que possam expor APIs de recursos a serem usadas por versões futuras do Trident . É possível criar e usar uma função de login de segurança personalizada com o Trident, mas isso não é recomendado.

Uma definição de backend de exemplo terá a seguinte aparência:

YAML
---
version: 1
backendName: ExampleBackend
storageDriverName: ontap-nas
managementLIF: 10.0.0.1
dataLIF: 10.0.0.2
svm: svm_nfs
credentials:
  name: secret-backend-creds
JSON
{
  "version": 1,
  "backendName": "ExampleBackend",
  "storageDriverName": "ontap-nas",
  "managementLIF": "10.0.0.1",
  "dataLIF": "10.0.0.2",
  "svm": "svm_nfs",
  "credentials": {
        "name": "secret-backend-creds"
    }
}

Lembre-se de que a definição do backend é o único lugar onde as credenciais são armazenadas em texto simples. Após a criação do backend, os nomes de usuário/senhas são codificados em Base64 e armazenados como segredos do Kubernetes. A criação/atualização de um backend é a única etapa que exige conhecimento das credenciais. Sendo assim, trata-se de uma operação exclusiva para administradores, a ser realizada pelo administrador do Kubernetes/armazenamento.

Habilitar autenticação baseada em certificado

Novos e existentes sistemas de backend podem usar um certificado e se comunicar com o backend ONTAP . São necessários três parâmetros na definição do backend.

  • clientCertificate: Valor do certificado do cliente codificado em Base64.

  • clientPrivateKey: Valor codificado em Base64 da chave privada associada.

  • trustedCACertificate: Valor codificado em Base64 do certificado da Autoridade Certificadora (CA) confiável. Caso esteja utilizando uma Autoridade Certificadora (CA) confiável, este parâmetro deve ser fornecido. Isso pode ser ignorado se nenhuma Autoridade Certificadora (CA) confiável for utilizada.

Um fluxo de trabalho típico envolve as seguintes etapas.

Passos
  1. Gere um certificado e uma chave de cliente. Ao gerar o código, defina o Nome Comum (CN) para o usuário ONTAP que será usado para autenticação.

    openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout k8senv.key -out k8senv.pem -subj "/C=US/ST=NC/L=RTP/O=NetApp/CN=vsadmin"
  2. Adicione um certificado CA confiável ao cluster ONTAP . Isso pode já estar sendo tratado pelo administrador de armazenamento. Ignore se nenhuma Autoridade Certificadora (CA) confiável for utilizada.

    security certificate install -type server -cert-name <trusted-ca-cert-name> -vserver <vserver-name>
    ssl modify -vserver <vserver-name> -server-enabled true -client-enabled true -common-name <common-name> -serial <SN-from-trusted-CA-cert> -ca <cert-authority>
  3. Instale o certificado e a chave do cliente (do passo 1) no cluster ONTAP .

    security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name>
    security ssl modify -vserver <vserver-name> -client-enabled true
  4. Confirme se a função de login de segurança do ONTAP é compatível. cert método de autenticação.

    security login create -user-or-group-name vsadmin -application ontapi -authentication-method cert -vserver <vserver-name>
    security login create -user-or-group-name vsadmin -application http -authentication-method cert -vserver <vserver-name>
  5. Teste a autenticação usando o certificado gerado. Substitua < ONTAP Management LIF> e <vserver name> pelo endereço IP do Management LIF e pelo nome do SVM. Você deve garantir que a política de serviço do LIF esteja definida como default-data-management .

    curl -X POST -Lk https://<ONTAP-Management-LIF>/servlets/netapp.servlets.admin.XMLrequest_filer --key k8senv.key --cert ~/k8senv.pem -d '<?xml version="1.0" encoding="UTF-8"?><netapp xmlns="http://www.netapp.com/filer/admin" version="1.21" vfiler="<vserver-name>"><vserver-get></vserver-get></netapp>'
  6. Codifique o certificado, a chave e o certificado da CA confiável em Base64.

    base64 -w 0 k8senv.pem >> cert_base64
    base64 -w 0 k8senv.key >> key_base64
    base64 -w 0 trustedca.pem >> trustedca_base64
  7. Crie o backend usando os valores obtidos na etapa anterior.

    cat cert-backend-updated.json
    {
    "version": 1,
    "storageDriverName": "ontap-nas",
    "backendName": "NasBackend",
    "managementLIF": "1.2.3.4",
    "dataLIF": "1.2.3.8",
    "svm": "vserver_test",
    "clientCertificate": "Faaaakkkkeeee...Vaaalllluuuueeee",
    "clientPrivateKey": "LS0tFaKE...0VaLuES0tLS0K",
    "storagePrefix": "myPrefix_"
    }
    
    #Update backend with tridentctl
    tridentctl update backend NasBackend -f cert-backend-updated.json -n trident
    +------------+----------------+--------------------------------------+--------+---------+
    |    NAME    | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
    +------------+----------------+--------------------------------------+--------+---------+
    | NasBackend | ontap-nas      | 98e19b74-aec7-4a3d-8dcf-128e5033b214 | online |       9 |
    +------------+----------------+--------------------------------------+--------+---------+

Atualize os métodos de autenticação ou altere as credenciais.

Você pode atualizar um backend existente para usar um método de autenticação diferente ou para rotacionar suas credenciais. Isso funciona nos dois sentidos: os sistemas internos que utilizam nome de usuário/senha podem ser atualizados para usar certificados; os sistemas internos que utilizam certificados podem ser atualizados para usar nome de usuário/senha. Para isso, você deve remover o método de autenticação existente e adicionar o novo método de autenticação. Em seguida, utilize o arquivo backend.json atualizado, que contém os parâmetros necessários, para executar o comando. tridentctl update backend .

cat cert-backend-updated.json
{
"version": 1,
"storageDriverName": "ontap-nas",
"backendName": "NasBackend",
"managementLIF": "1.2.3.4",
"dataLIF": "1.2.3.8",
"svm": "vserver_test",
"username": "vsadmin",
"password": "password",
"storagePrefix": "myPrefix_"
}
#Update backend with tridentctl
tridentctl update backend NasBackend -f cert-backend-updated.json -n trident
+------------+----------------+--------------------------------------+--------+---------+
|    NAME    | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+------------+----------------+--------------------------------------+--------+---------+
| NasBackend | ontap-nas      | 98e19b74-aec7-4a3d-8dcf-128e5033b214 | online |       9 |
+------------+----------------+--------------------------------------+--------+---------+
Observação Ao rotacionar senhas, o administrador de armazenamento deve primeiro atualizar a senha do usuário no ONTAP. Em seguida, é realizada uma atualização do sistema interno. Ao rotacionar certificados, vários certificados podem ser adicionados ao usuário. Em seguida, o sistema de backend é atualizado para usar o novo certificado, após o que o certificado antigo pode ser excluído do cluster ONTAP .

A atualização de um backend não interrompe o acesso a volumes já criados, nem afeta as conexões de volume feitas posteriormente. Uma atualização bem-sucedida do backend indica que o Trident pode se comunicar com o backend ONTAP e lidar com futuras operações em grande volume.

Criar função ONTAP personalizada para Trident

Você pode criar uma função de cluster ONTAP com privilégios mínimos para que não precise usar a função de administrador do ONTAP para executar operações no Trident. Ao incluir o nome de usuário em uma configuração de backend do Trident , o Trident usa a função de cluster ONTAP que você criou para executar as operações.

Consulte"Gerador de funções personalizadas Trident" Para obter mais informações sobre como criar funções personalizadas do Trident .

Utilizando a CLI do ONTAP
  1. Crie uma nova função usando o seguinte comando:

    security login role create <role_name\> -cmddirname "command" -access all –vserver <svm_name\>

  2. Crie um nome de usuário para o usuário do Trident :

    security login create -username <user_name\> -application ontapi -authmethod <password\> -role <name_of_role_in_step_1\> –vserver <svm_name\> -comment "user_description"

  3. Atribua a função ao usuário:

    security login modify username <user_name\> –vserver <svm_name\> -role <role_name\> -application ontapi -application console -authmethod <password\>

Utilizando o Gerenciador de Sistemas

Execute as seguintes etapas no ONTAP System Manager:

  1. Criar uma função personalizada:

    1. Para criar uma função personalizada no nível do cluster, selecione Cluster > Configurações.

      (Ou) Para criar uma função personalizada no nível da SVM, selecione Armazenamento > VMs de armazenamento > required SVM > Configurações > Usuários e funções.

    2. Selecione o ícone de seta () ao lado de Usuários e Funções.

    3. Selecione +Adicionar em Funções.

    4. Defina as regras para a função e clique em Salvar.

  2. Atribua a função ao usuário do Trident *: + Execute as seguintes etapas na página *Usuários e Funções:

    1. Selecione o ícone Adicionar * em Usuários.

    2. Selecione o nome de usuário desejado e, em seguida, selecione uma função no menu suspenso Função.

    3. Clique em Salvar.

Consulte as páginas seguintes para obter mais informações:

Gerenciar políticas de exportação NFS

O Trident utiliza políticas de exportação NFS para controlar o acesso aos volumes que provisiona.

A Trident oferece duas opções para trabalhar com políticas de exportação:

  • O Trident pode gerenciar dinamicamente a própria política de exportação; nesse modo de operação, o administrador de armazenamento especifica uma lista de blocos CIDR que representam endereços IP admissíveis. O Trident adiciona automaticamente à política de exportação, no momento da publicação, os endereços IP dos nós aplicáveis ​​que se enquadram nesses intervalos. Alternativamente, quando nenhum CIDR for especificado, todos os IPs unicast de escopo global encontrados no nó para o qual o volume está sendo publicado serão adicionados à política de exportação.

  • Os administradores de armazenamento podem criar uma política de exportação e adicionar regras manualmente. O Trident utiliza a política de exportação padrão, a menos que um nome de política de exportação diferente seja especificado na configuração.

Gerenciar políticas de exportação dinamicamente

O Trident oferece a capacidade de gerenciar dinamicamente as políticas de exportação para backends ONTAP . Isso permite ao administrador de armazenamento especificar um espaço de endereços permitido para os IPs dos nós de trabalho, em vez de definir regras explícitas manualmente. Isso simplifica bastante a gestão da política de exportação; as alterações na política de exportação não exigem mais intervenção manual no cluster de armazenamento. Além disso, isso ajuda a restringir o acesso ao cluster de armazenamento apenas aos nós de trabalho que estão montando volumes e possuem endereços IP no intervalo especificado, permitindo um gerenciamento preciso e automatizado.

Observação Não utilize Network Address Translation (NAT) ao usar políticas de exportação dinâmicas. Com NAT, o controlador de armazenamento vê o endereço NAT de front-end e não o endereço IP real do host; portanto, o acesso será negado quando nenhuma correspondência for encontrada nas regras de exportação.

Exemplo

Existem duas opções de configuração que devem ser utilizadas. Aqui está um exemplo de definição de backend:

---
version: 1
storageDriverName: ontap-nas-economy
backendName: ontap_nas_auto_export
managementLIF: 192.168.0.135
svm: svm1
username: vsadmin
password: password
autoExportCIDRs:
  - 192.168.0.0/24
autoExportPolicy: true
Observação Ao utilizar este recurso, você deve garantir que a junção raiz em sua SVM tenha uma política de exportação previamente criada com uma regra de exportação que permita o bloco CIDR do nó (como a política de exportação padrão). Siga sempre as melhores práticas recomendadas pela NetApp para dedicar uma SVM ao Trident.

Segue abaixo uma explicação de como essa funcionalidade opera, utilizando o exemplo acima:

  • autoExportPolicy`está definido para `true . Isso indica que o Trident cria uma política de exportação para cada volume provisionado com esse backend para o svm1 SVM e lidar com a adição e exclusão de regras usando autoexportCIDRs blocos de endereço. Até que um volume seja anexado a um nó, ele utiliza uma política de exportação vazia, sem regras para impedir o acesso indesejado a esse volume. Quando um volume é publicado em um nó, o Trident cria uma política de exportação com o mesmo nome da qtree subjacente, contendo o endereço IP do nó dentro do bloco CIDR especificado. Esses IPs também serão adicionados à política de exportação usada pelo FlexVol volume pai.

    • Por exemplo:

      • UUID do backend 403b5326-8482-40db-96d0-d83fb3f4daec

      • autoExportPolicy`definido para `true

      • prefixo de armazenamento trident

      • UUID do PVC a79bcf5f-7b6d-4a40-9876-e2551f159c1c

      • qtree chamado trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c cria uma política de exportação para o FlexVol chamado trident-403b5326-8482-40db96d0-d83fb3f4daec , uma política de exportação para a qtree chamada
        trident_pvc_a79bcf5f_7b6d_4a40_9876_e2551f159c1c e uma política de exportação vazia chamada trident_empty na SVM. As regras para a política de exportação FlexVol serão um superconjunto de quaisquer regras contidas nas políticas de exportação qtree. A política de exportação vazia será reutilizada por quaisquer volumes que não estejam anexados.

  • `autoExportCIDRs`Contém uma lista de blocos de endereços. Este campo é opcional e o valor padrão é ["0.0.0.0/0", "::/0"]. Caso não esteja definido, o Trident adiciona todos os endereços unicast de escopo global encontrados nos nós de trabalho com publicações.

Neste exemplo, o 192.168.0.0/24 O espaço de endereçamento é fornecido. Isso indica que os endereços IP dos nós do Kubernetes que se enquadram nesse intervalo de endereços com publicações serão adicionados à política de exportação criada Trident . Quando o Trident registra um nó no qual está sendo executado, ele recupera os endereços IP do nó e os verifica em relação aos blocos de endereços fornecidos em autoExportCIDRs No momento da publicação, após filtrar os IPs, o Trident cria as regras de política de exportação para os IPs do cliente para o nó no qual está publicando.

Você pode atualizar autoExportPolicy e autoExportCIDRs para os backends depois de criá-los. Você pode adicionar novos CIDRs para um backend que é gerenciado automaticamente ou excluir CIDRs existentes. Tenha cuidado ao excluir CIDRs para garantir que as conexões existentes não sejam interrompidas. Você também pode optar por desativar. autoExportPolicy para um backend e recorrer a uma política de exportação criada manualmente como alternativa. Isso exigirá a configuração do exportPolicy parâmetro na sua configuração de backend.

Após o Trident criar ou atualizar um backend, você pode verificar o backend usando tridentctl ou o correspondente tridentbackend CRD:

./tridentctl get backends ontap_nas_auto_export -n trident -o yaml
items:
- backendUUID: 403b5326-8482-40db-96d0-d83fb3f4daec
  config:
    aggregate: ""
    autoExportCIDRs:
    - 192.168.0.0/24
    autoExportPolicy: true
    backendName: ontap_nas_auto_export
    chapInitiatorSecret: ""
    chapTargetInitiatorSecret: ""
    chapTargetUsername: ""
    chapUsername: ""
    dataLIF: 192.168.0.135
    debug: false
    debugTraceFlags: null
    defaults:
      encryption: "false"
      exportPolicy: <automatic>
      fileSystemType: ext4

Quando um nó é removido, o Trident verifica todas as políticas de exportação para remover as regras de acesso correspondentes ao nó. Ao remover o endereço IP deste nó das políticas de exportação dos backends gerenciados, o Trident impede montagens não autorizadas, a menos que este endereço IP seja reutilizado por um novo nó no cluster.

Para backends já existentes, atualize o backend com tridentctl update backend Garante que o Trident gerencie as políticas de exportação automaticamente. Isso cria duas novas políticas de exportação com os nomes do UUID e da árvore de consulta (qtree) do backend, quando necessárias. Os volumes presentes no servidor usarão as políticas de exportação recém-criadas após serem desmontados e montados novamente.

Observação Excluir um backend com políticas de exportação gerenciadas automaticamente excluirá a política de exportação criada dinamicamente. Se o backend for recriado, ele será tratado como um novo backend e resultará na criação de uma nova política de exportação.

Se o endereço IP de um nó ativo for atualizado, você deverá reiniciar o pod do Trident nesse nó. A Trident atualizará então a política de exportação dos servidores que gerencia para refletir essa alteração de IP.

Prepare-se para provisionar volumes SMB

Com um pouco de preparação adicional, você pode provisionar volumes SMB usando ontap-nas motoristas.

Aviso Você deve configurar os protocolos NFS e SMB/CIFS na SVM para criar um ontap-nas-economy Volume SMB para clusters ONTAP locais. A falha na configuração de qualquer um desses protocolos fará com que a criação do volume SMB falhe.
Observação `autoExportPolicy`Não é compatível com volumes SMB.
Antes de começar

Antes de poder provisionar volumes SMB, você precisa ter o seguinte.

  • Um cluster Kubernetes com um nó controlador Linux e pelo menos um nó de trabalho Windows executando o Windows Server 2022. O Trident suporta volumes SMB montados em pods executados apenas em nós Windows.

  • Pelo menos um segredo Trident contendo suas credenciais do Active Directory. Para gerar segredos smbcreds :

    kubectl create secret generic smbcreds --from-literal username=user --from-literal password='password'
  • Um proxy CSI configurado como um serviço do Windows. Para configurar um csi-proxy , consulte"GitHub: Proxy CSI" ou"GitHub: CSI Proxy para Windows" para nós do Kubernetes executados no Windows.

Passos
  1. Para o ONTAP local, você pode opcionalmente criar um compartilhamento SMB ou a Trident pode criar um para você.

    Observação Os compartilhamentos SMB são necessários para o Amazon FSx para ONTAP.

    Você pode criar os compartilhamentos administrativos SMB de duas maneiras: usando o"Console de gerenciamento da Microsoft" Acesse as Pastas Compartilhadas pelo snap-in ou usando a CLI do ONTAP . Para criar compartilhamentos SMB usando a CLI do ONTAP :

    1. Se necessário, crie a estrutura de diretórios para o compartilhamento.

      O vserver cifs share create O comando verifica o caminho especificado na opção -path durante a criação do compartilhamento. Se o caminho especificado não existir, o comando falhará.

    2. Crie um compartilhamento SMB associado à SVM especificada:

      vserver cifs share create -vserver vserver_name -share-name share_name -path path [-share-properties share_properties,...] [other_attributes] [-comment text]
    3. Verifique se o compartilhamento foi criado:

      vserver cifs share show -share-name share_name
      Observação Consulte"Criar um compartilhamento SMB" Para obter detalhes completos.
  2. Ao criar o backend, você deve configurar o seguinte para especificar os volumes SMB. Para todas as opções de configuração do backend FSx para ONTAP , consulte"Opções e exemplos de configuração do FSx para ONTAP" .

    Parâmetro Descrição Exemplo

    smbShare

    Você pode especificar uma das seguintes opções: o nome de um compartilhamento SMB criado usando o Console de Gerenciamento da Microsoft ou a CLI do ONTAP ; um nome para permitir que o Trident crie o compartilhamento SMB; ou você pode deixar o parâmetro em branco para impedir o acesso comum aos volumes compartilhados. Este parâmetro é opcional para o ONTAP local. Este parâmetro é obrigatório para backends do Amazon FSx para ONTAP e não pode estar em branco.

    smb-share

    nasType

    Deve ser configurado para smb . Se for nulo, o valor padrão é nfs .

    smb

    securityStyle

    Estilo de segurança para novos volumes. Deve ser configurado para ntfs ou mixed para volumes SMB.

    ntfs`ou `mixed para volumes SMB

    unixPermissions

    Modo para novos volumes. Deve ficar vazio para volumes SMB.

    ""

Ativar SMB seguro

A partir da versão 25.06, o NetApp Trident oferece suporte ao provisionamento seguro de volumes SMB criados usando ontap-nas e ontap-nas-economy back-ends. Quando o SMB seguro está habilitado, você pode fornecer acesso controlado aos compartilhamentos SMB para usuários e grupos de usuários do Active Directory (AD) usando Listas de Controle de Acesso (ACLs).

Pontos a serem lembrados
  • Importando ontap-nas-economy O volume não é suportado.

  • Somente clones somente leitura são suportados para ontap-nas-economy volumes.

  • Se o SMB seguro estiver ativado, o Trident ignorará o compartilhamento SMB mencionado no backend.

  • A atualização da anotação PVC, da anotação da classe de armazenamento e do campo de backend não atualiza a ACL de compartilhamento SMB.

  • A ACL de compartilhamento SMB especificada na anotação do PVC clonado terá precedência sobre as do PVC de origem.

  • Certifique-se de fornecer usuários válidos do Active Directory ao habilitar o SMB seguro. Usuários inválidos não serão adicionados à ACL.

  • Se você fornecer o mesmo usuário do Active Directory no backend, na classe de armazenamento e no PVC com permissões diferentes, a prioridade de permissão será: PVC, classe de armazenamento e, por último, backend.

  • O Secure SMB é compatível com ontap-nas Importações de volume gerenciadas e não aplicáveis a importações de volume não gerenciadas.

Passos
  1. Especifique o usuário adAdminUser no TridentBackendConfig conforme mostrado no exemplo a seguir:

    apiVersion: trident.netapp.io/v1
    kind: TridentBackendConfig
    metadata:
      name: backend-tbc-ontap
      namespace: trident
    spec:
      version: 1
      storageDriverName: ontap-nas
      managementLIF: 10.193.176.x
      svm: svm0
      useREST: true
      defaults:
        adAdminUser: tridentADtest
      credentials:
        name: backend-tbc-ontap-invest-secret
  2. Adicione a anotação na classe de armazenamento.

    Adicione o trident.netapp.io/smbShareAdUser Anotação na classe de armazenamento para habilitar o SMB seguro sem falhas. O valor do usuário especificado para a anotação trident.netapp.io/smbShareAdUser deve ser o mesmo que o nome de usuário especificado no smbcreds segredo. Você pode escolher uma das seguintes opções para smbShareAdUserPermission : full_control , change , ou read . A permissão padrão é full_control .

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-smb-sc
  annotations:
    trident.netapp.io/smbShareAdUserPermission: change
    trident.netapp.io/smbShareAdUser: tridentADuser
parameters:
  backendType: ontap-nas
  csi.storage.k8s.io/node-stage-secret-name: smbcreds
  csi.storage.k8s.io/node-stage-secret-namespace: trident
  trident.netapp.io/nasType: smb
provisioner: csi.trident.netapp.io
reclaimPolicy: Delete
volumeBindingMode: Immediate
  1. Criar um PVC.

    O exemplo a seguir cria um PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc4
  namespace: trident
  annotations:
    trident.netapp.io/snapshotDirectory: "true"
    trident.netapp.io/smbShareAccessControl: |
      read:
        - tridentADtest
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: ontap-smb-sc