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.

Configurar pools de storage do Google Cloud NetApp Volumes em modo ONTAP

Colaboradores joan-ing
PDFs

A partir do Trident 26.06, você pode configurar ontap-san e ontap-nas back-ends existentes para provisionar armazenamento em pools de storage do Google Cloud NetApp Volumes (GCNV) no modo ONTAP. Este recurso é uma Tech Preview.

Observação

Este recurso é uma Prévia Técnica no Trident 26.10. Recursos em Tech Preview não são suportados para uso em produção. A funcionalidade, os campos de configuração e a matriz de suporte podem ser alterados antes da disponibilidade geral (GA).

Como funciona

Trident reutiliza a ontap-san e ontap-nas lógica de driver existente e encaminha as chamadas REST do ONTAP por meio de um endpoint proxy do GCNV. Essa abordagem permite que você provisione e gerencie armazenamento em clusters ONTAP hospedados pelo GCNV, mantendo os mesmos fluxos de trabalho operacionais que você usa para um backend ONTAP direto. O modo ONTAP não introduz um novo driver de armazenamento. Você habilita isso por backend adicionando um gcnv bloco de configuração a um ontap-san ou ontap-nas backend.

O caminho de provisionamento é o seguinte:

PersistentVolumeClaim→ Trident (ontap-san ou ontap-nas) → ONTAP cliente → GCNV proxy → ONTAP cluster no pool GCNV

Escopo suportado e não suportado

Esta versão de pré-visualização técnica oferece suporte ao seguinte:

  • Drivers: ontap-san (iSCSI) e ontap-nas (NFS ou SMB).

  • Operações de ciclo de vida por meio do proxy: inicialização do backend, criação e exclusão de volumes e fluxos REST do ONTAP relacionados.

  • Modelos de autenticação: Workload Identity Pool (WIP), chave de conta de serviço e fallback de Application Default Credentials (ADC).

Os seguintes itens estão fora do escopo desta Tech Preview:

  • Os ontap-san-economy, ontap-nas-economy e ontap-nas-flexgroup drivers.

  • O caminho de personalidade ASA r2.

  • Recurso alternativo ZAPI. O modo ONTAP utiliza apenas o ONTAP REST.

Pré-requisitos

Antes de configurar um backend no modo ONTAP, certifique-se de ter o seguinte:

  • Trident 26.06 ou posterior.

  • Um pool de storage GCNV ONTAP-mode em seu projeto e localização de destino.

  • Permissões do GCP IAM para operações de proxy, com escopo adequado ao seu ambiente.

  • Uma configuração de backend que inclui proxyURL, projectNumber, location e poolID.

  • Para fluxos de trabalho iSCSI SAN, os pré-requisitos de iSCSI e multipath do lado do nó para sua plataforma. Consulte "Prepare o nó de trabalho".

Configurar o backend

É TridentBackendConfig necessário credentials referenciar um Secret do Kubernetes. Para o modo ONTAP, o Secret fornece credenciais para acesso ao proxy do GCP, não ao ONTAP managementLIF / username / password. Dependendo do método de autenticação, ele pode conter campos de chave da conta de serviço ou estar vazio. svm é opcional: cada pool do GCNV no modo ONTAP atualmente tem uma SVM, e o Trident a deriva do pool quando ela é omitida.

Para a autenticação de chave da conta de serviço, use o mesmo padrão do GCNV nativo: campos não sensíveis em gcnv.apiKey, private_key e private_key_id no secret. Consulte "Exemplos de configuração do Google Cloud NetApp Volumes". Para a autenticação do Workload Identity Pool ou da identidade de nuvem do GKE, consulte os exemplos em Autenticação.

backend ontap-san
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-ontap-san
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san
  backendName: gcnv-ontap-san
  credentials:
    name: gcnv-sa-secret
    type: secret
  gcnv:
    proxyURL: "https://netapp.googleapis.com"
    projectNumber: "<project-number>"
    location: "<pool-location>"
    poolID: "<pool-id>"
  svm: "<svm-name>"
backend ontap-nas
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-ontap-nas
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: gcnv-ontap-nas
  credentials:
    name: gcnv-sa-secret
    type: secret
  gcnv:
    proxyURL: "https://netapp.googleapis.com"
    projectNumber: "<project-number>"
    location: "<pool-location>"
    poolID: "<pool-id>"
    apiKey:
      type: service_account
      project_id: "<project-id>"
      client_email: "<service-account-email>"
      client_id: "<client-id>"
      auth_uri: "https://accounts.google.com/o/oauth2/auth"
      token_uri: "https://oauth2.googleapis.com/token"
      auth_provider_x509_cert_url: "https://www.googleapis.com/oauth2/v1/certs"
      client_x509_cert_url: "<client-x509-cert-url>"
  svm: "<svm-name>"
Segredo
apiVersion: v1
kind: Secret
metadata:
  name: gcnv-sa-secret
  namespace: trident
type: Opaque
stringData:
  private_key_id: "<private-key-id>"
  private_key: |
    -----BEGIN PRIVATE KEY-----
    <private-key>
    -----END PRIVATE KEY-----
Observação

Não coloque private_key ou private_key_id na TridentBackendConfig especificação — o CRD os rejeita. Use ontap-san com o mesmo gcnv e padrão de credencial para pool de storage em bloco.

Autenticação

O Trident resolve as credenciais para acesso por proxy na seguinte ordem:

  1. Pool de identidade de workload (WIP)

  2. Chave da conta de serviço

  3. Credenciais padrão do aplicativo (ADC)

Para esta prévia técnica, utilize as seguintes práticas:

  • Dê preferência ao Workload Identity Pool quando ele estiver disponível.

  • Não incorpore chaves privadas brutas em arquivos de backend com controle de versão. Armazene as credenciais em um segredo do Kubernetes.

  • Aplique o escopo de IAM de menor privilégio à conta de serviço.

O location no gcnv bloco deve corresponder à localização do pool: use a zona para um pool zonal e a região para um pool regional.

O Workload Identity Pool

Use gcnv.wipCredential para federação explícita de conta externa configurada no TridentBackendConfig. No OpenShift, o Trident projeta o token em /var/run/secrets/wif-token/token; este é o único caminho de token que o Trident projeta para o OpenShift WIF, portanto use-o para credential_source.file. Instale o Trident com a audience do WIF, conforme descrito em "Configure o Google Cloud NetApp Volumes com a federação de identidade da carga de trabalho". O credentials campo ainda faz referência a um Secret, mas o Secret não deve conter um private_key.

apiVersion: v1
kind: Secret
metadata:
  name: gcnv-ontap-empty
  namespace: trident
type: Opaque
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-ontap-nas-wip
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: gcnv-ontap-nas-wip
  useREST: true
  nasType: nfs
  nfsMountOptions: nfsvers=4.1
  credentials:
    name: gcnv-ontap-empty
    type: secret
  gcnv:
    proxyURL: "https://netapp.googleapis.com"
    projectNumber: "<project-number>"
    location: "<pool-location>"
    poolID: "<pool-id>"
    wipCredential:
      type: external_account
      audience: "//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<wif-pool-id>/providers/<provider-id>"
      subject_token_type: "urn:ietf:params:oauth:token-type:jwt"
      token_url: "https://sts.googleapis.com/v1/token"
      service_account_impersonation_url: "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<service-account-email>:generateAccessToken"
      credential_source:
        file: "/var/run/secrets/wif-token/token"

Identidade de nuvem do GKE

Para o GKE, configure a identidade de nuvem do Trident durante a instalação, conforme descrito em "Usar a identidade de carga de trabalho do GKE". O backend usa Application Default Credentials (ADC); omita gcnv.apiKey e gcnv.wipCredential. O campo credentials ainda faz referência a um Secret, mas não coloque um private_key nele.

apiVersion: v1
kind: Secret
metadata:
  name: gcnv-ontap-empty
  namespace: trident
type: Opaque
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-ontap-nas-wi
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: gcnv-ontap-nas-wi
  useREST: true
  nasType: nfs
  nfsMountOptions: nfsvers=4.1
  credentials:
    name: gcnv-ontap-empty
    type: secret
  gcnv:
    proxyURL: "https://netapp.googleapis.com"
    projectNumber: "<project-number>"
    location: "<pool-location>"
    poolID: "<pool-id>"

Comportamento de validação e inicialização

O Trident valida um backend no modo ONTAP durante a inicialização e falha rapidamente em vez de inicializar parcialmente.

A inicialização do backend falha se um `gcnv`campo obrigatório estiver ausente, se o driver não for compatível com o modo ONTAP ou se a resolução de credenciais falhar.

Limitações conhecidas

  • Este recurso é uma Prévia técnica. O comportamento e a matriz suportada podem mudar antes do GA.

  • O fallback do ZAPI não é usado no modo ONTAP.

  • Os requisitos de protocolo e de prontidão do nó ainda se aplicam. Por exemplo, os fluxos de trabalho do iSCSI exigem os pré-requisitos do lado do nó descritos em "Prepare o nó de trabalho".

  • As restrições existentes dos ambientes ONTAP e GCNV ainda se aplicam.

Upgrade e compatibilidade

O modo ONTAP é opcional para cada backend por meio do gcnv bloco de configuração:

  • Os backends ONTAP existentes que não são GCNV não são afetados.

  • Implantações mistas que combinam backends diretos do ONTAP e backends de proxy no modo ONTAP são compatíveis por meio da configuração no nível do backend. Cada backend é configurado independentemente.

  • Para parar de usar o ONTAP-mode, remova ou substitua os backends afetados. Nenhuma opção global é necessária.

O que se segue?

Aplique o segredo antes do TBC; use kubectl apply e -n trident para corresponder aos exemplos.