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 Google Cloud NetApp Volumes

Colaboradores netapp-aruldeepa joan-ing netapp-mwallis
PDFs

Você pode configurar o Google Cloud NetApp Volumes como um backend para Trident a fim de provisionar storage para cargas de trabalho do Kubernetes.

Visão geral

Trident oferece suporte ao Google Cloud NetApp Volumes para cargas de trabalho NAS (NFS e SMB) e em bloco (iSCSI).

  • As cargas de trabalho NAS usam o google-cloud-netapp-volumes backend

  • As cargas de trabalho em bloco (iSCSI) usam o `google-cloud-netapp-volumes-san`backend

Os volumes NAS fornecem armazenamento baseado em arquivos e são acessados usando os protocolos NFS ou SMB. Esses volumes suportam acesso compartilhado entre vários pods ou nós.

Os volumes de bloco fornecem armazenamento bruto em bloco e são acessados como dispositivos iSCSI conectados a nós do Kubernetes. Esses volumes são usados quando os aplicativos exigem acesso em nível de bloco.

Isso se aplica aos seguintes ambientes:

  • Trident 26.02 e posteriores

  • Google Kubernetes Engine (GKE) ou clusters do Red Hat OpenShift em execução no GCP

  • OpenShift A Federação de Identidade de Carga de Trabalho (WIF) requer o Trident 26.10 ou posterior

  • Pools de armazenamento do Google Cloud NetApp Volumes

Para configurar o armazenamento em bloco (iSCSI), consulte "Configurar armazenamento em bloco (iSCSI)".

Prepare-se para configurar

A identidade na nuvem permite que as cargas de trabalho do Kubernetes acessem recursos do Google Cloud autenticando-se como uma identidade de carga de trabalho em vez de usar credenciais estáticas.

Antes de configurar a identidade da carga de trabalho, use uma conta autorizada a criar os recursos de identidade necessários. Para o GKE, isso requer permissões do Google Cloud para criar e configurar uma conta de serviço do Google Cloud. Para o OpenShift, isso requer permissão para criar ou selecionar a configuração de WIF do cluster e para configurar o Google Cloud Workload Identity Pool e o provedor.

Usar a identidade de carga de trabalho do GKE

Para usar a identidade de workload do GKE com Google Cloud NetApp Volumes, você precisa ter:

  • Um cluster Kubernetes implantado usando Google Kubernetes Engine (GKE)

  • Identidade de carga de trabalho habilitada no cluster GKE e o servidor de metadados habilitado nos pools de nós

  • Uma conta de serviço do Google Cloud com a função de Administrador do Google Cloud NetApp Volumes (roles/netapp.admin) ou uma função personalizada equivalente

  • Trident instalado com o provedor de nuvem definido como GCP e a anotação de identidade da nuvem configurada

Operador Trident

Para instalar o Trident usando o operador Trident, edite tridentorchestrator_cr.yaml:

apiVersion: trident.netapp.io/v1
kind: TridentOrchestrator
metadata:
  name: trident
spec:
  namespace: trident
  cloudProvider: "GCP"
  cloudIdentity: "iam.gke.io/gcp-service-account: cloudvolumes-admin-sa@mygcpproject.iam.gserviceaccount.com"
Leme

Defina o provedor de nuvem e a identidade da nuvem ao instalar o Trident com o Helm:

helm install trident trident-operator-100.6.0.tgz \
  --set cloudProvider=GCP \
  --set cloudIdentity="iam.gke.io/gcp-service-account: cloudvolumes-admin-sa@mygcpproject.iam.gserviceaccount.com"
tridentctl

Instale Trident especificando o provedor de nuvem e a identidade de nuvem:

tridentctl install \
  --cloud-provider=GCP \
  --cloud-identity="iam.gke.io/gcp-service-account: cloudvolumes-admin-sa@mygcpproject.iam.gserviceaccount.com" \
  -n trident

Use a Federação de Identidade da Carga de Trabalho no OpenShift

A partir do Trident 26.10, você pode usar o Google Cloud Workload Identity Federation (WIF) para autenticar os drivers do Google Cloud NetApp Volumes em clusters do OpenShift executados no GCP. Isso se aplica ao OpenShift Container Platform (OCP, incluindo implantações IPI) autogerenciado e ao OpenShift Dedicated (OSD), e oferece suporte aos drivers NAS (google-cloud-netapp-volumes) e SAN (google-cloud-netapp-volumes-san).

O WIF troca um token projetado de conta de serviço do Kubernetes por credenciais de curta duração do Google Cloud. O Trident usa essas credenciais para representar uma conta de serviço do Google Cloud; as funções do IAM dessa conta de serviço autorizam suas chamadas de API do Google Cloud NetApp Volumes. Isso evita armazenar uma chave de conta de serviço de longa duração na configuração de backend.

Importante

No OpenShift Dedicated, o provedor OIDC pode ser compartilhado com outros componentes do OpenShift. Se a lista allowedAudiences do provedor 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 do Trident. Não defina uma lista explícita de público 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.

Prepare o cluster do OpenShift

Para OSD, crie ou selecione uma configuração WIF do GCP ao criar o cluster. Por exemplo, a OpenShift Cluster Manager CLI pode criar uma:

ocm gcp create wif-config --name <wif-name> --project <gcp-project-id>

Selecione Workload Identity Federation como o tipo de autenticação do cluster e associe a configuração WIF ao cluster. Para o OCP autogerenciado, configure um provedor OIDC do Google Cloud que confie no emissor do token da conta de serviço do cluster. As etapas de provisionamento do cluster e de projeção do token diferem entre o OSD e o OCP autogerenciado; siga as orientações aplicáveis da Red Hat e disponibilize o token projetado para o controlador do Trident em /var/run/secrets/wif-token/token.

A autenticação WIF do OSD é configurada quando você cria o cluster. O público WIF do Trident é uma configuração de instalação separada; você não precisa recriar o cluster para habilitar o WIF para o Trident.

Antes de instalar ou configurar o Trident, verifique se a identidade do OpenShift usada para a instalação tem as permissões de cluster exigidas pelo método de instalação que você escolheu. Após a instalação, confirme se os pods do controlador e dos nós estão saudáveis:

oc whoami
oc auth can-i create namespaces
oc auth can-i create csidrivers.storage.k8s.io
oc auth can-i create customresourcedefinitions.apiextensions.k8s.io
oc auth can-i create securitycontextconstraints.security.openshift.io

oc -n trident get pods
oc -n trident rollout status deploy/trident-controller --timeout=300s
oc -n trident rollout status ds/trident-node-linux --timeout=300s

Instale o Trident com o público do WIF

O Trident projeta o token para WIF somente quando você configura o público-alvo durante a instalação. Use o mesmo público-alvo no provedor do Google Cloud e no do backend wipCredentialConfig.audience:

//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>

Defina cloudProvider como GCP e configure gcpWIFAudience usando o método de instalação que você selecionou:

tridentctl
tridentctl install \
  --cloud-provider GCP \
  --gcp-wif-audience "<audience>" \
  --namespace trident
Operador Trident

Defina esses campos na TridentOrchestrator especificação:

spec:
  cloudProvider: GCP
  gcpWIFAudience: "<audience>"
Leme

Defina estes valores ao instalar o chart:

helm install trident netapp-trident/trident-operator \
  --set cloudProvider=GCP \
  --set-string gcpWIFAudience="<audience>"

Não configure também a opção GKE cloudIdentity / --cloud-identity para o WIF do OpenShift. Não aplique patch no Deployment do controlador do Trident após a instalação; o operador reverte as alterações manuais. O token projetado está disponível para o backend em /var/run/secrets/wif-token/token. O trident-main contêiner não inclui um shell, portanto inspecione a configuração de volume do Deployment do controlador em vez de usar oc exec para verificar o arquivo:

oc -n trident get deploy trident-controller -o yaml

Configure a confiança e as permissões do Google Cloud

Configure um Google Cloud Workload Identity Pool e um provedor OIDC para o cluster. O emissor do provedor deve corresponder ao claim iss do token, e o mapeamento de atributos deve mapear assertion.sub para google.subject. O público permitido do provedor deve corresponder ao claim aud do token projetado.

Os endpoints públicos .well-known/openid-configuration e JWKS são necessários apenas ao usar a descoberta OIDC. O Google também oferece suporte ao upload direto do JWKS usando jwksJson ou --jwk-json-path.

Atribua à entidade principal WIF a roles/iam.workloadIdentityUser`função na conta de serviço do Google Cloud que o Trident vai representar. Para um sujeito de token de `system:serviceaccount:trident:trident-controller, a entidade principal tem este formato:

principal://iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/subject/system:serviceaccount:trident:trident-controller

Conceda à conta de serviço representada roles/netapp.admin no projeto que contém os recursos do Google Cloud NetApp Volumes, ou uma função personalizada equivalente com as permissões necessárias. Essas são concessões separadas: a primeira permite a representação, e a segunda autoriza as operações da API de storage.

Se a configuração do público-alvo e do provedor do token não corresponder, o Serviço de Token de Segurança do Google poderá rejeitar a troca com um invalid_grant erro de público-alvo. Verifique a configuração do provedor com:

gcloud iam workload-identity-pools providers describe <provider-id> \
  --project=<wif-pool-project-id> \
  --location=global \
  --workload-identity-pool=<pool-id> \
  --format="yaml(oidc.allowedAudiences,oidc.issuerUri,attributeMapping)"

Ao diagnosticar a configuração do token, compare as declarações de iss, aud e sub do token com a configuração do provedor e do IAM. Não compartilhe nem registre o token projetado completo.

Prepare o armazenamento do Google Cloud NetApp Volumes

Crie ou identifique um pool de storage na região usada pelo backend. Os backends NAS exigem um pool FILE; os backends SAN usam os pools Flex Unified descritos em "Configurar armazenamento em bloco (iSCSI)". Certifique-se de que a configuração de VPC e Private Service Access (PSA) do pool seja adequada para a rede do cluster.

Por exemplo, liste os intervalos de peering VPC globais existentes para uma rede antes de selecionar o intervalo PSA para um pool:

gcloud compute addresses list \
  --project <gcnv-project-id> \
  --global \
  --filter="purpose=VPC_PEERING AND network:<network-name>" \
  --format="table(name,address,prefixLength,status,network,purpose)"

Use a região do pool em location e, quando necessário, selecione o pool explicitamente usando seu caminho de recurso completo em storagePools. Incompatibilidades entre a região e a localização do pool, uma rede incorreta ou um pool indisponível podem impedir a descoberta ou o provisionamento, mesmo quando a autenticação é bem-sucedida.

Configure o backend do Trident

Use o público-alvo projetado do token tanto na configuração do provedor quanto em wipCredentialConfig.audience. O projectNumber campo identifica o projeto do Google Cloud NetApp Volumes; o público-alvo usa o número do projeto que contém o Workload Identity Pool. Substitua os espaços reservados neste exemplo pelos valores do seu ambiente:

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-nas-wif
  namespace: trident
spec:
  version: 1
  storageDriverName: google-cloud-netapp-volumes
  projectNumber: "<project-number>"
  location: "<region>"
  sdkTimeout: "600"
  storage:
  - labels:
      cloud: gcp
    network: "<vpc-network>"
    serviceLevel: Premium
  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

Para um backend SAN, use google-cloud-netapp-volumes-san como storageDriverName e as configurações aplicáveis do pool Flex Unified. Fora isso, a configuração da credencial WIF é a mesma para ambos os drivers.

Aplique o backend e verifique o status observado:

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

Confirme se o backend está Bound e se a última operação foi bem-sucedida antes de testar o provisionamento. Inspecione o ambiente ativo spec e status a configuração; uma anotação de configuração aplicada anteriormente pode não refletir alterações posteriores. Não inclua credenciais estáticas apiKey ao usar o WIF.

Verifique o provisionamento completamente

Crie uma StorageClass que tenha como destino o backend e, em seguida, um pequeno PVC de teste. Por exemplo, uma StorageClass NAS pode selecionar um rótulo de backend:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcnv-wif-smoke
provisioner: csi.trident.netapp.io
parameters:
  backendType: "google-cloud-netapp-volumes"
  selector: "auth=wif"
allowVolumeExpansion: true

Adicione o rótulo correspondente auth: wif à entrada de storage do backend NAS, crie um PVC usando gcnv-wif-smoke e verifique se ele alcança Bound. Para um teste rápido de SAN, use google-cloud-netapp-volumes-san, as configurações do driver SAN e um pool Flex Unified apropriado. Exclua o PVC de teste e a StorageClass ao concluir.

Solucione falhas comuns

Sintoma O que verificar

invalid_grant ou incompatibilidade de público

Compare o token projetado aud com os públicos permitidos do provedor e wipCredentialConfig.audience.

iam.serviceAccounts.getAccessToken permissão negada

Verifique se a principal WIF exata do controlador do Trident sub tem roles/iam.workloadIdentityUser na conta de serviço representada.

netapp.storagePools.list permissão negada

Verifique se a conta de serviço representada possui as permissões do Google Cloud NetApp Volumes, como roles/netapp.admin, no projeto correto.

Nenhum pool de storage encontrado ou pool de storage não encontrado

Verifique o backend location, a região e o tipo do pool, a rede, a configuração do PSA e qualquer caminho de recurso do pool de storage configurado explicitamente.

O backend permanece desvinculado

Inspecione os logs do controlador do Trident e o status de TridentBackendConfig para identificar o erro subjacente de autenticação, permissão ou descoberta de pool.

Para inspecionar os logs do controlador em busca de erros de reconciliação no backend:

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

Configurar armazenamento NAS

Observação Para pools de armazenamento UNIFIED do Google Cloud NetApp Volumes, Trident aplica regras de nomenclatura e validação específicas do UNIFIED durante as operações de volume.

Ao localizar um volume, Trident pode avaliar várias variantes de nomes de volume compatíveis (por exemplo, formatos com hífen e sublinhado) para melhorar a confiabilidade da importação e da descoberta.

Detalhes do driver

Trident fornece o google-cloud-netapp-volumes driver para provisionar armazenamento NAS a partir do Google Cloud NetApp Volumes.

O driver suporta os seguintes modos de acesso:

  • ReadWriteOnce (RWO)

  • ReadOnlyMany (ROX)

  • ReadWriteMany (RWX)

  • ReadWriteOncePod (RWOP)

Condutor Protocolo VolumeMode Modos de acesso suportados Sistemas de arquivos suportados

google-cloud-netapp-volumes

NFS, SMB

Sistema de ficheiros

RWO, ROX, RWX, RWOP

nfs, smb

Configurar um backend NAS do Trident

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

Provisionar volumes NAS

Os volumes NAS são provisionados usando o google-cloud-netapp-volumes backend e suportam os protocolos NFS e SMB.

StorageClass para volumes NFS

Para provisionar volumes NFS, defina nasType para nfs.

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

StorageClass for volumes SMB

Para provisionar volumes SMB, defina nasType para smb e forneça as credenciais.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcnv-smb
provisioner: csi.trident.netapp.io
parameters:
  backendType: "google-cloud-netapp-volumes"
  trident.netapp.io/nasType: "smb"
  csi.storage.k8s.io/node-stage-secret-name: "smbcreds"
  csi.storage.k8s.io/node-stage-secret-namespace: "default"
allowVolumeExpansion: true

Exemplo de PersistentVolumeClaim (RWX)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-nas-rwx
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-nfs

Exemplo de PersistentVolumeClaim (RWO)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-nas-rwo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-nfs
Observação Volumes NAS usam volumeMode: Filesystem.