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 o Google Cloud NetApp Volumes para cargas de trabalho SAN

11/03/2026 Colaboradores

PDFs

Use o google-cloud-netapp-volumes-san driver para provisionar volumes de bloco iSCSI dos pools de armazenamento Flex Unified do Google Cloud NetApp Volumes.

O driver SAN suporta apenas cargas de trabalho em bloco. Para provisionar volumes NAS, use o google-cloud-netapp-volumes driver.

Visão geral

O driver provisiona volumes dos pools de armazenamento do Flex Unified e os apresenta aos nós do Kubernetes como dispositivos de bloco iSCSI.

O driver é compatível com os seguintes ambientes:

Trident 26.02 e posteriores
Google Kubernetes Engine (GKE) ou clusters do Red Hat OpenShift em execução no GCP
Pools de storage unificado do Google Cloud NetApp Volumes Flex
Cargas de trabalho baseadas em iSCSI

A partir do o Trident 26.10, o driver SAN oferece suporte ao Google Cloud Workload Identity Federation (WIF) na plataforma autogerenciada OpenShift Container Platform (OCP, incluindo implantações IPI) e em clusters OpenShift Dedicated (OSD) executados no GCP. Para conhecer os pré-requisitos do WIF e a configuração do backend, consulte "Use a Federação de Identidade da Carga de Trabalho no OpenShift". Use o nome do driver SAN e as configurações de armazenamento do o Flex Unified nesta página.

Configure a WIF para SAN

O WIF troca um token de conta de serviço projetado do Kubernetes por credenciais de curta duração do Google Cloud. O Trident usa essas credenciais para se passar por uma conta de serviço do Google Cloud ao chamar a API do Google Cloud NetApp Volumes.

Configure um pool de identidades de workload do Google Cloud e um provedor OIDC para o cluster OpenShift. O emissor do provedor deve corresponder ao claim iss do token, e o mapeamento de atributos deve mapear assertion.sub para google.subject.

Instale o Trident com o nome do recurso do provedor como o público do WIF. Isso fará com que o Trident projete o token da conta de serviço do controlador em /var/run/secrets/wif-token/token.

Operador Trident

apiVersion: trident.netapp.io/v1
kind: TridentOrchestrator
metadata:
  name: trident
spec:
  namespace: trident
  cloudProvider: GCP
  gcpWIFAudience: "//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>"

Leme

helm install trident <trident-operator-package> \
  --namespace trident \
  --create-namespace \
  --set cloudProvider=GCP \
  --set-string gcpWIFAudience="//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>"

tridentctl

tridentctl install \
  --namespace trident \
  --cloud-provider GCP \
  --gcp-wif-audience "//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>"

Use o mesmo público-alvo para a instalação do Trident e wipCredentialConfig.audience. Também não configure o GKE cloudIdentity ou --cloud-identity. Não aplique patches no Deployment do controlador para adicionar o token projetado; o operador do Trident pode sobrescrever essa alteração.

No OpenShift Dedicated, o provedor OIDC pode ser compartilhado com outros componentes do OpenShift. Se a lista do provedor allowedAudiences estiver vazia, o Google aceita o nome canônico do recurso do provedor, com ou sem o https:// prefixo, portanto nenhuma alteração no provedor é necessária para o público acima. Não defina uma lista de público explícita apenas para o Trident. Se o provedor já tiver públicos explícitos, acrescente o público do Trident, preservando todos os valores existentes. Substituir a lista pode impedir que outros componentes do OpenShift troquem tokens.

Conceda à entidade principal do WIF da conta de serviço do controlador do Trident a função roles/iam.workloadIdentityUser na conta de serviço do Google Cloud que o Trident representará. Para a conta de serviço padrão do controlador do Trident, o assunto do token é system:serviceaccount:trident:trident-controller; use o assunto configurado para sua instalação. Conceda à conta de serviço representada a função roles/netapp.admin, ou permissões equivalentes, no projeto que contém os recursos do Google Cloud NetApp Volumes.

Adicione o seguinte bloco ao spec do backend SAN:

wipCredentialConfig:
  type: external_account
  audience: "//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>"
  subject_token_type: urn:ietf:params:oauth:token-type:jwt
  token_url: https://sts.googleapis.com/v1/token
  credential_source:
    file: /var/run/secrets/wif-token/token
  service_account_impersonation_url: https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<service-account-email>:generateAccessToken

A configuração WIF é a mesma para os dois drivers GCNV. O backend SAN ainda deve usar google-cloud-netapp-volumes-san e um pool de storage Flex Unified compatível.

Pools de storage unificado Flex

Os pools de armazenamento Flex Unified fornecem armazenamento em bloco usando o protocolo iSCSI e são necessários para o provisionamento de SAN:

Os pools regionais Flex Unified são suportados.
Os pools Zonais unificados Flex são suportados a partir do Trident 26.02.1.
Apenas o nível de serviço Flex é compatível com cargas de trabalho SAN.

O backend location deve corresponder à região do pool Flex Unified. Se o Trident não encontrar o pool, verifique a região, a rede e o caminho do recurso do pool.

Configurar um backend Trident SAN

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-san
  namespace: trident
spec:
  version: 1
  storageDriverName: google-cloud-netapp-volumes-san
  projectNumber: "<project-number>"
  location: "<region>"
  sdkTimeout: "600"
  storage:
  - labels:
      cloud: gcp
      performance: flex
    network: "<vpc-network>"
    serviceLevel: Flex

Crie um StorageClass

Após configurar o backend SAN, crie um StorageClass que faça referência ao google-cloud-netapp-volumes-san driver.

Especifique o tipo de sistema de arquivos no StorageClass, não no backend.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcnv-san
provisioner: csi.trident.netapp.io
parameters:
  backendType: "google-cloud-netapp-volumes-san"
  fsType: "ext4"
allowVolumeExpansion: true

O driver é compatível com os seguintes tipos de sistema de arquivos:

ext4 (padrão)
ext3
xfs

O driver SAN suporta apenas o nível de serviço Flex e não utiliza parâmetros de backend específicos do NAS, como exportRule, unixPermissions, nasType, snapshotDir, nfsMountOptions ou configurações relacionadas ao tiering.

Verificar o provisionamento de WIF

Aplique o backend e verifique se o TridentBackendConfig está vinculado e se sua última operação foi bem-sucedida:

oc apply -f <backend-file>.yaml
oc -n trident get tridentbackendconfig <backend-name> -o yaml

Crie um PVC usando a gcnv-san StorageClass desta página e verifique se ele chega a Bound. Isso valida em conjunto a troca de WIF, a representação da conta de serviço, as permissões do Google Cloud NetApp Volumes e a seleção do pool SAN. Exclua o PVC de teste quando terminar.

Se a reconciliação do backend falhar, inspecione os logs do controlador do Trident:

oc -n trident logs deploy/trident-controller -c trident-main --tail=400

Verifique o seguinte quanto a erros comuns:

Para um invalid_grant erro de público-alvo, compare a declaração aud do token com os públicos-alvo permitidos pelo provedor OIDC e wipCredentialConfig.audience.
Para um iam.serviceAccounts.getAccessToken erro de permissão, verifique se o principal WIF do controlador do Trident tem roles/iam.workloadIdentityUser na conta de serviço representada.
Em caso de netapp.storagePools.list erro de permissão, verifique se a conta de serviço representada tem as permissões necessárias do Google Cloud NetApp Volumes no projeto correto.
Caso o pool não seja encontrado, verifique se sua localização e tipo são compatíveis, se a região do backend corresponde à região do pool e se o backend está referenciando a rede e o pool corretos.

Provisionar volumes de bloco

ReadWriteOnce (RWO)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rwo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

ReadWriteOncePod (RWOP)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rwop
spec:
  accessModes:
    - ReadWriteOncePod
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

ReadOnlyMany (ROX)

Um padrão comum para o ROX é clonar um volume ReadWriteOnce existente e montar o clone como somente leitura.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rox
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san
  dataSource:
    kind: PersistentVolumeClaim
    name: gcnv-san-rwo

ReadWriteMany (RWX) — somente bloco bruto

ReadWriteMany é suportado somente quando volumeMode: Block.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-raw-rwx
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Block
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

Comportamento do volume do bloco

Os volumes de bloco são provisionados como LUNs iSCSI e apresentados aos nós do Kubernetes como dispositivos de bloco.

Volumes de bloco:

Use o protocolo iSCSI
Suporte ao sistema de arquivos e apresentação de blocos brutos
Estão anexados e gerenciados pela Trident
Suporte a múltiplos modos de acesso do Kubernetes

Modos de acesso

Os volumes de bloco provisionados pelo Trident suportam os seguintes modos de acesso:

ReadWriteOnce (RWO)
ReadOnlyMany (ROX)
ReadWriteOncePod (RWOP)
ReadWriteMany (RWX), suportado somente quando volumeMode: Block

Comportamento do volumeMode

O volumeMode campo controla como um volume de bloco é exposto:

Filesystem Trident formata e monta o volume.
Block Trident conecta o dispositivo e o expõe como um dispositivo de bloco raw.

Operações suportadas

Volumes de bloco provisionados usando o driver google-cloud-netapp-volumes-san oferecem suporte a:

Criar
Excluir
Clonar
Snapshot
Redimensionar
Importar

Sobrecarga do tamanho do volume

Os volumes em bloco do Google Cloud NetApp Volumes incluem sobrecarga de metadados internos. Como resultado, o tamanho do dispositivo visível para o kernel é menor do que a capacidade provisionada.

Sobrecarga observada:

Aproximadamente 300 KiB quando um volume é criado
Até aproximadamente 107 MiB após um redimensionamento

O Google Cloud NetApp Volumes aceita alocações de capacidade em GiB inteiros. Para garantir que o tamanho utilizável do dispositivo atenda ou exceda a solicitação do PVC, o Trident:

Arredonda o tamanho solicitado para o próximo GiB inteiro.
Adiciona um buffer de 1 GiB.

Por exemplo:

Pedido de PVC: 100 GiB.
Capacidade provisionada: 101 GiB.
Capacidade utilizável visível para a aplicação: pelo menos 100 GiB.

Exemplos de pods

Volume de bloco montado no sistema de arquivos (RWO)

apiVersion: v1
kind: Pod
metadata:
  name: app-rwo
spec:
  containers:
  - name: app
    image: ubuntu:22.04
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: data
      mountPath: /mnt/data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: gcnv-san-rwo

Dispositivo de bloco bruto (RWX)

apiVersion: v1
kind: Pod
metadata:
  name: app-raw-rwx
spec:
  containers:
  - name: app
    image: ubuntu:22.04
    command: ["sleep", "infinity"]
    volumeDevices:
    - name: data
      devicePath: /dev/xda
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: gcnv-san-raw-rwx

Comportamento de attach e montagem

Para volumes SAN provisionados a partir do Google Cloud NetApp Volumes:

Trident cria um Número de Unidade Lógica (LUN) em um pool de storage Flex Unified.
Durante a publicação, Trident mapeia o LUN para um grupo de hosts por nó.
Durante o preparo do nó, Trident:
- Faz login no destino iSCSI
- Descobre o LUN
- Configura multipath
Se volumeMode: Filesystem, o Trident formata o dispositivo, se necessário, e o monta.
Se `volumeMode: Block`Trident anexar o dispositivo e expô-lo diretamente ao pod sem formatar ou montar.

Os volumes de bloco SAN não oferecem bloqueio distribuído nem coordenação de gravação. Quando um volume de bloco é acessado por vários nós (ReadWriteMany com volumeMode: Block), o aplicativo ou o sistema de arquivos deve gerenciar a concorrência.