Aceda a instâncias do Filestore com o controlador CSI do Filestore

O controlador CSI do Filestore é a principal forma de usar instâncias do Filestore com o Google Kubernetes Engine (GKE). O controlador CSI do Filestore oferece uma experiência totalmente gerida com tecnologia do Google Cloud controlador CSI do Filestore de código aberto.

A versão do controlador CSI do Filestore está associada aos números de versão secundária do Kubernetes. Normalmente, a versão do controlador CSI do Filestore é o controlador mais recente disponível no momento do lançamento da versão secundária do Kubernetes. Os controladores são atualizados automaticamente quando o cluster é atualizado para o patch do GKE mais recente.

Vantagens

O controlador CSI do Filestore oferece as seguintes vantagens:

• Tem acesso ao armazenamento NFS totalmente gerido através das APIs Kubernetes (kubectl).

• Pode usar o controlador CSI do GKE Filestore para aprovisionar dinamicamente os seus PersistentVolumes.

• Pode usar instantâneos de volume com o controlador CSI do GKE Filestore. As cópias instantâneas de volumes da CSI podem ser usadas para criar cópias de segurança do Filestore.

  Uma cópia de segurança do Filestore cria uma cópia diferencial da partilha de ficheiros, incluindo todos os dados e metadados dos ficheiros, e armazena-a separadamente da instância. Só pode restaurar esta cópia para uma nova instância do Filestore. A restauração para uma instância do Filestore existente não é suportada. Pode usar a API de instantâneo de volume da CSI para acionar cópias de segurança do Filestore, adicionando um campo type:backup na classe de instantâneo de volume.

• Pode usar a expansão de volume com o controlador CSI do GKE Filestore. A expansão de volume permite-lhe redimensionar a capacidade do volume.

• Pode aceder a instâncias do Filestore existentes usando instâncias do Filestore pré-aprovisionadas em cargas de trabalho do Kubernetes. Também pode criar ou eliminar dinamicamente instâncias do Filestore e usá-las em cargas de trabalho do Kubernetes com uma StorageClass ou uma Deployment.

• Suporta partilhas múltiplas do Filestore para o GKE. Esta funcionalidade permite-lhe criar uma instância do Filestore e atribuir vários volumes persistentes montados em NFS mais pequenos em simultâneo em qualquer número de clusters do GKE.

• Suporta o nível de HDD básico com uma capacidade mínima de 100 GiB.

Requisitos

• Para usar o controlador CSI do Filestore, os seus clusters têm de usar o número de versão do GKE adequado aplicável ao seu nível de serviço. Apenas são suportados os seguintes níveis de serviço:

  • HDD básico com a versão 1.21 ou posterior do GKE
  • HDD básico (100 GiB a 63,9 TiB) com a versão 1.33 ou posterior do GKE
  • SSD básico com a versão 1.21 ou posterior do GKE
  • Zonal (1 TiB a 9,75 TiB) com o GKE versão 1.31 ou posterior
  • Zonal (10 TiB a 100 TiB) com a versão 1.27 ou posterior do GKE
  • Enterprise com a versão 1.25 ou posterior do GKE
  • Para usar a capacidade de partilhas múltiplas do Filestore, os seus clusters têm de usar a versão 1.25 ou posterior do GKE.

• O controlador CSI do Filestore só é suportado para clusters que usam o Linux; os nós do Windows Server não são suportados.

• O tamanho mínimo da instância depende do nível de serviço do Filestore que selecionou:

  • Pelo menos, 100 GiB para HDD básico
  • Pelo menos 1 TiB para outros níveis do Filestore

  Para saber mais, consulte Níveis de serviço.

• O Filestore usa o protocolo do sistema de ficheiros NFSv3 na instância do Filestore por predefinição e suporta qualquer cliente compatível com NFSv3.

• O protocolo do sistema de ficheiros NFSv4.1 na instância do Filestore é suportado para a versão 1.33 ou posterior do GKE.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Cloud Filestore e a API Google Kubernetes Engine.
Ativar APIs
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

• Se quiser usar o Filestore numa rede VPC partilhada, consulte as instruções de configuração adicionais em Use o Filestore com a VPC partilhada.

Ative o controlador CSI do Filestore num novo cluster

Para ativar o controlador CSI do Filestore ao criar um novo cluster Standard, siga estes passos com a CLI do Google Cloud ou a Google Cloud consola.

gcloud container clusters create CLUSTER_NAME \
    --addons=GcpFilestoreCsiDriver \
    --cluster-version=VERSION

Se quiser usar o Filestore numa rede de VPC partilhada, consulte o artigo Ative o controlador CSI do Filestore num novo cluster com VPC partilhada.

Depois de ativar o controlador CSI do Filestore, pode usar o controlador em volumes do Kubernetes com o nome do controlador e do aprovisionador: filestore.csi.storage.gke.io.

Ative o controlador CSI do Filestore num cluster existente

Para ativar o controlador CSI do Filestore em clusters existentes, use a CLI do Google Cloud ou a Google Cloud consola.

Para ativar o controlador num cluster existente, conclua os seguintes passos:

gcloud container clusters update CLUSTER_NAME \
   --update-addons=GcpFilestoreCsiDriver=ENABLED

Desative o controlador CSI do Filestore

Pode desativar o controlador CSI do Filestore num cluster do Autopilot ou Standard existente através da CLI Google Cloud ou da Google Cloud consola.

gcloud container clusters update CLUSTER_NAME \
    --update-addons=GcpFilestoreCsiDriver=DISABLED \
    --region REGION

Aceda a instâncias do Filestore pré-existentes através do controlador CSI do Filestore

Esta secção descreve o processo típico de utilização de um volume do Kubernetes para aceder a instâncias do Filestore pré-existentes através do controlador CSI do Filestore no GKE:

Crie um PersistentVolume e um PersistentVolumeClaim para aceder à instância

1. Crie um ficheiro de manifesto como o apresentado no exemplo seguinte e atribua-lhe o nome preprov-filestore.yaml:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: PV_NAME
   spec:
     storageClassName: ""
     capacity:
       storage: 1Ti
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     volumeMode: Filesystem
     csi:
       driver: filestore.csi.storage.gke.io
       volumeHandle: "modeInstance/FILESTORE_INSTANCE_LOCATION/FILESTORE_INSTANCE_NAME/FILESTORE_SHARE_NAME"
       volumeAttributes:
         ip: FILESTORE_INSTANCE_IP
         volume: FILESTORE_SHARE_NAME
         protocol: FILESYSTEM_PROTOCOL
     claimRef:
       name: PVC_NAME
       namespace: NAMESPACE
   ---
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: PVC_NAME
     namespace: NAMESPACE
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: ""
     resources:
       requests:
         storage: 1Ti
   

2. Para criar os recursos PersistentVolumeClaim e PersistentVolume com base no ficheiro de manifesto preprov-filestore.yaml, execute o seguinte comando:

   kubectl apply -f preprov-filestore.yaml
   

Para especificar o protocolo do sistema de ficheiros NFSv4.1, defina o campo protocol como NFS_V4_1 no campo volumeAttributes de um objeto PersistentVolume. Para usar o protocolo do sistema de ficheiros NFSv3, defina o campo protocol como NFS_V3 ou omita o campo protocol.

Em seguida, avance para criar uma implementação que consuma o volume.

Crie um volume com o controlador CSI do Filestore

As secções seguintes descrevem o processo típico de utilização de um volume do Kubernetes suportado por um controlador CSI do Filestore no GKE:

• Crie uma StorageClass
• Use um PersistentVolumeClaim para aceder ao volume
• Crie uma implementação que consuma o volume

Crie uma StorageClass

Depois de ativar o controlador CSI do Filestore, o GKE instala automaticamente as seguintes StorageClasses para o aprovisionamento de instâncias do Filestore:

• zonal-rwx, usando o nível zonal do Filestore.
• enterprise-rwx, usando o nível empresarial do Filestore, em que cada PersistentVolume do Kubernetes é mapeado para uma instância do Filestore.
• enterprise-multishare-rwx, usando o nível empresarial do Filestore, em que cada PersistentVolume do Kubernetes é mapeado para uma partilha de uma determinada instância do Filestore. Para saber mais, consulte o artigo Partilhas múltiplas do Filestore para o Google Kubernetes Engine.
• standard-rwx, usando o nível de serviço HDD básico do Filestore.
• premium-rwx, usando o nível de serviço SSD básico do Filestore.

Cada StorageClass só está disponível em clusters do GKE executados nos respetivos números de versão do GKE suportados. Para ver uma lista das versões suportadas necessárias para cada nível de serviço, consulte os Requisitos.

Pode encontrar o nome do seu StorageClass instalado executando o seguinte comando:

kubectl get sc

Também pode instalar um StorageClass diferente que use o controlador CSI do Filestore adicionando filestore.csi.storage.gke.io no campo provisioner.

O Filestore precisa de saber em que rede criar a nova instância. As StorageClasses instaladas automaticamente usam a rede predefinida criada para clusters do GKE. Se tiver eliminado esta rede ou quiser usar uma rede diferente, tem de criar uma nova StorageClass, conforme descrito nos passos seguintes. Caso contrário, as StorageClasses instaladas automaticamente não funcionam.

1. Guarde o seguinte manifesto como filestore-example-class.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: filestore-example
   provisioner: filestore.csi.storage.gke.io
   volumeBindingMode: Immediate
   allowVolumeExpansion: true
   parameters:
     tier: standard
     network: default
   

   No manifesto, considere a seguinte configuração de parâmetros:

   • Definir volumeBindingMode como Immediate permite que o aprovisionamento do volume comece imediatamente. Isto é possível porque as instâncias do Filestore são acessíveis a partir de qualquer zona. Por conseguinte, o GKE não precisa de saber a zona onde o pod está agendado, ao contrário do disco persistente do Compute Engine. Quando definido como WaitForFirstConsumer, o GKE começa o aprovisionamento apenas depois de o pod ser agendado. Para mais informações, consulte o artigo VolumeBindingMode.
   • Pode especificar qualquer nível do Filestore suportado no parâmetrotier (por exemplo, BASIC_HDD, BASIC_SSD, ZONAL ou ENTERPRISE).
   • O parâmetro network pode ser usado quando aprovisiona instâncias do Filestore em VPCs não predefinidas. As VPCs não predefinidas requerem a configuração de regras de firewall especiais.
   • O protocol parâmetro pode ser usado para definir o protocolo do sistema de ficheiros da instância do Filestore. Pode assumir os seguintes valores: NFS_V3 (predefinição) e NFS_V4_1. O protocolo predefinido é NFS_V3.

2. Para criar um recurso StorageClass com base no ficheiro de manifesto filestore-example-class.yaml, execute o seguinte comando:

   kubectl create -f filestore-example-class.yaml
   

Se quiser usar o Filestore numa rede de VPC partilhada, consulte o artigo Crie uma StorageClass quando usar o controlador CSI do Filestore com a VPC partilhada.

Use um PersistentVolumeClaim para aceder ao volume

Pode criar um recurso PersistentVolumeClaim que faça referência ao StorageClass do controlador CSI do Filestore.

Pode usar um StorageClass pré-instalado ou personalizado.

O ficheiro de manifesto de exemplo seguinte cria um PersistentVolumeClaim que faz referência ao StorageClass com o nome filestore-example.

1. Guarde o seguinte ficheiro de manifesto como pvc-example.yaml:

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: podpvc
   spec:
     accessModes:
     - ReadWriteMany
     storageClassName: filestore-example
     resources:
       requests:
         storage: 1Ti
   

2. Para criar um recurso PersistentVolumeClaim com base no ficheiro de manifesto pvc-example.yaml, execute o seguinte comando:

   kubectl create -f pvc-example.yaml
   

Crie uma implementação que consuma o volume

O seguinte manifesto de implementação consome o recurso PersistentVolume denominado pvc-example.yaml.

Vários pods podem partilhar o mesmo recurso PersistentVolumeClaim.

1. Guarde o seguinte manifesto como filestore-example-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-server-deployment
     labels:
       app: nginx
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx
           volumeMounts:
           - mountPath: /usr/share/nginx/html
             name: mypvc
         volumes:
         - name: mypvc
           persistentVolumeClaim:
             claimName: podpvc
   ---
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: podpvc
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: filestore-example
     resources:
       requests:
         storage: 1Ti
   

2. Para criar uma implementação com base no ficheiro de manifesto filestore-example-deployment.yaml, execute o seguinte comando:

   kubectl apply -f filestore-example-deployment.yaml
   

3. Confirme que a implementação foi criada com êxito:

   kubectl get deployment
   

   As instâncias do Filestore podem demorar algum tempo a concluir o aprovisionamento. Antes disso, as implementações não comunicam um estado READY. Pode verificar o progresso monitorizando o estado do PVC através da execução do seguinte comando:

   kubectl get pvc
   

   Deve ver o PVC atingir o estado BOUND quando o aprovisionamento de volume estiver concluído.

Etiquete instâncias do Filestore

Pode usar etiquetas para agrupar instâncias relacionadas e armazenar metadados sobre uma instância. Uma etiqueta é um par de chave-valor que ajuda a organizar as suas instâncias do Filestore. Pode anexar uma etiqueta a cada recurso e, em seguida, filtrar os recursos com base nas respetivas etiquetas.

Pode fornecer etiquetas através da chave labels em StorageClass.parameters. Pode etiquetar uma instância do Filestore com informações sobre o motivo pelo qual PersistentVolumeClaim/PersistentVolume a instância foi criada. As chaves e os valores das etiquetas personalizadas têm de estar em conformidade com a convenção de nomenclatura de etiquetas. Consulte o exemplo de classe de armazenamento do Kubernetes para aplicar etiquetas personalizadas à instância do Filestore.

Use o protocolo do sistema de ficheiros NFSv4.1 com o Filestore

O controlador CSI do Filestore suporta o protocolo do sistema de ficheiros NFSv4.1 com a versão 1.33 ou posterior do GKE. No caso do aprovisionamento estático, defina o campo protocol como NFS_V4_1 no campo volumeAttributes de um objeto PersistentVolume.

Para o aprovisionamento dinâmico, defina o campo protocol como NFS_V4_1 nos parâmetros de um objeto StorageClass.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: enterprise-multishare-rwx
provisioner: filestore.csi.storage.gke.io
parameters:
  tier: enterprise
  multishare: "true"
  instance-storageclass-label: "enterprise-multishare-rwx"
  protocol: NFS_V4_1
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Não pode montar a instância do Filestore com o protocolo NFSv4.1 com mountOptions definido como nfsvers=3 no objeto StorageClass.

Use fsgroup com volumes do Filestore

O Kubernetes usa o fsGroup para alterar as autorizações e a propriedade do volume de forma a corresponder a um fsGroup pedido pelo utilizador no SecurityContext do pod. Um fsGroup é um grupo suplementar que se aplica a todos os contentores num agrupamento. Pode aplicar um fsgroup a volumes aprovisionados pelo controlador CSI do Filestore.

Configure regras de acesso IP com volumes do Filestore

O Filestore suporta regras de controlo de acesso com base no IP para volumes. Esta funcionalidade está disponível em clusters do GKE com a versão 1.29.5 ou posterior.

Esta funcionalidade permite que os administradores especifiquem que intervalos de endereços IP têm autorização para aceder a uma instância do Filestore aprovisionada dinamicamente através do GKE. Isto melhora a segurança ao restringir o acesso apenas a clientes autorizados, especialmente em cenários em que o intervalo de IP do cluster do GKE é demasiado amplo, expondo potencialmente a instância do Filestore a utilizadores ou aplicações não autorizados.

Estas regras podem ser configuradas diretamente através da API Filestore ou através do controlador CSI do Filestore quando é criado um volume. Pode fornecer a configuração selecionada no formato JSON na StorageClass através do parâmetro nfs-export-options-on-create.

O manifesto de exemplo seguinte mostra como especificar a configuração:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  tier: "enterprise"
  nfs-export-options-on-create: '[
    {
      "accessMode": "READ_WRITE",
      "ipRanges": [
        "10.0.0.0/24"
      ],
      "squashMode": "ROOT_SQUASH",
      "anonUid": "1003",
      "anonGid": "1003"
    },
    {
      "accessMode": "READ_WRITE",
      "ipRanges": [
        "10.0.0.0/28"
      ],
      "squashMode": "NO_ROOT_SQUASH"
    }
  ]'

Opções de segurança

As regras de acesso por IP do Filestore simplificam a configuração das autorizações de armazenamento de ficheiros partilhado para as suas cargas de trabalho do GKE. No entanto, para compreender como gere a propriedade e o acesso aos ficheiros, é necessário compreender alguns conceitos importantes:

• NFS e mapeamentos de utilizadores O NFS (Network File System) é o protocolo usado pelo Filestore. Funciona ao mapear os utilizadores nos sistemas cliente (os seus pods do GKE) para os utilizadores no servidor do Filestore. Se um ficheiro no servidor for propriedade do ID de utilizador 1003 e um cliente estabelecer ligação com o ID de utilizador 1003, tem acesso ao ficheiro.

• Root squashing e anonUid:

  • A compressão de acesso máximoROOT_SQUASH é uma funcionalidade de segurança que impede que os clientes acedam à instância do Filestore com privilégios de acesso máximo completos. Quando a restrição de acesso root está ativada, os utilizadores root nos sistemas cliente são mapeados para um utilizador não privilegiado especificado pela definição anonUid.

  • No Root Squashing (NO_ROOT_SQUASH) permite que os clientes acedam à instância do Filestore com privilégios de acesso total, o que é conveniente para a configuração inicial, mas menos seguro para as operações normais.

• Configuração inicial e autorizações: por predefinição, uma nova instância do Filestore é totalmente propriedade do utilizador root. Se ativar a restrição de acesso root sem primeiro configurar as autorizações para outros utilizadores, perde o acesso. É por isso que precisa de, pelo menos, uma regra de exportação NFS com NO_ROOT_SQUASH para configurar inicialmente o acesso para outros utilizadores e grupos.

Recomendações

• Configuração inicial: comece sempre com, pelo menos, uma regra de exportação do NFS que especifique um intervalo de administrador com autorizações READ_WRITE e permita o acesso NO_ROOT_SQUASH. Use este acesso para criar diretórios, definir autorizações e atribuir a propriedade conforme necessário.
• Segurança: ative a restrição de acesso de root (ROOT_SQUASH) para melhorar a segurança. Tenha em atenção que, depois de criar um volume, só pode modificar as regras de acesso através da API Filestore.
• Acesso partilhado: use fsGroup nos contextos de segurança dos pods para gerir a propriedade de grupos de volumes partilhados. Certifique-se de que não sobrepõe a sua definição ao modo ROOT_SQUASH. Se o fizer, é devolvida uma Access denied mensagem de erro.

Use o Filestore com a VPC partilhada

Esta secção aborda como usar uma instância do Filestore numa rede de VPC partilhada a partir de um projeto de serviço.

Configure um cluster com a VPC partilhada

Para configurar os clusters com uma rede de VPC partilhada, siga estes passos:

1. Crie um projeto anfitrião e um projeto de serviço.
2. Ative a API Google Kubernetes Engine nos projetos anfitrião e de serviço.
3. No projeto anfitrião, crie uma rede e uma sub-rede.
4. Ative a VPC partilhada no projeto anfitrião.
5. No projeto anfitrião, conceda a associação da função de utilizador para a conta de serviço do GKE do projeto de serviço.HostServiceAgent
6. Ative o acesso a serviços privados na rede VPC partilhada.

Ative o controlador CSI do Filestore num novo cluster com VPC partilhada

Para ativar o controlador CSI do Filestore num novo cluster com VPC partilhada, siga estes passos:

1. Valide as sub-redes utilizáveis e os intervalos secundários. Quando cria um cluster, tem de especificar uma sub-rede e os intervalos de endereços IP secundários a usar para os pods e o serviço do cluster.

   gcloud container subnets list-usable \
      --project=SERVICE_PROJECT_ID \
      --network-project=HOST_PROJECT_ID
   

   O resultado é semelhante ao seguinte:

   PROJECT                   REGION       NETWORK     SUBNET  RANGE
   HOST_PROJECT_ID  us-central1  shared-net  tier-1  10.0.4.0/22
   ┌──────────────────────┬───────────────┬─────────────────────────────┐
   │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
   ├──────────────────────┼───────────────┼─────────────────────────────┤
   │ tier-1-pods          │ 10.4.0.0/14   │ usable for pods or services │
   │ tier-1-services      │ 10.0.32.0/20  │ usable for pods or services │
   └──────────────────────┴───────────────┴─────────────────────────────┘
   

2. Crie um cluster do GKE. Os exemplos seguintes mostram como pode usar a CLI gcloud para criar um cluster do Autopilot ou Standard configurado para VPC partilhada. Os exemplos seguintes usam os nomes de rede, sub-rede e intervalo de Criar uma rede e duas sub-redes.

   Piloto automático

   gcloud container clusters create-auto tier-1-cluster \
      --project=SERVICE_PROJECT_ID \
      --region=COMPUTE_REGION \
      --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \
      --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \
      --cluster-secondary-range-name=tier-1-pods \
      --services-secondary-range-name=tier-1-services
   

   Standard

   gcloud container clusters create tier-1-cluster \
      --project=SERVICE_PROJECT_ID \
      --zone=COMPUTE_REGION \
      --enable-ip-alias \
      --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \
      --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \
      --cluster-secondary-range-name=tier-1-pods \
      --services-secondary-range-name=tier-1-services \
      --addons=GcpFilestoreCsiDriver
   

3. Crie regras de firewall para permitir a comunicação entre nós, pods e serviços no seu cluster. O exemplo seguinte mostra como pode criar uma regra de firewall denominada my-shared-net-rule-2.

   gcloud compute firewall-rules create my-shared-net-rule-2 \
      --project HOST_PROJECT_ID \
      --network=NETWORK_NAME \
      --allow=tcp,udp \
      --direction=INGRESS \
      --source-ranges=10.0.4.0/22,10.4.0.0/14,10.0.32.0/20
   

   No exemplo, os valores de IP dos intervalos de origem provêm do passo anterior, no qual validou as sub-redes utilizáveis e os intervalos secundários.

Crie uma StorageClass quando usar o controlador CSI do Filestore com a VPC partilhada

O exemplo seguinte mostra como pode criar uma StorageClass quando usa o controlador CSI do Filestore com a VPC partilhada:

cat <<EOF | kubectl apply -f -

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-sharedvpc-example
provisioner: filestore.csi.storage.gke.io
parameters:
  network: "projects/HOST_PROJECT_ID/global/networks/SHARED_VPC_NAME"
  connect-mode: PRIVATE_SERVICE_ACCESS
  reserved-ip-range: RESERVED_IP_RANGE_NAME
allowVolumeExpansion: true

EOF

Substitua o seguinte:

• HOST_PROJECT_ID: o ID ou o nome do projeto anfitrião da rede VPC partilhada.
• SHARED_VPC_NAME: o nome da rede VPC partilhada que criou anteriormente.
• RESERVED_IP_RANGE_NAME: o nome do intervalo de endereços IP reservados específico para aprovisionar a instância do Filestore. Este campo é opcional. Se for especificado um intervalo de endereços IP reservado, tem de ser um intervalo de endereços denominado em vez de um valor CIDR direto.

Se quiser aprovisionar um volume com base em partilhas múltiplas do Filestore em clusters do GKE com a versão 1.23 ou posterior, consulte o artigo Otimize o armazenamento com partilhas múltiplas do Filestore para o GKE.

Volte a ligar volumes de partilha única do Filestore

Se estiver a usar o Filestore com o nível básico de HDD, básico de SSD ou empresarial (partilha única), pode seguir estas instruções para voltar a ligar a instância do Filestore existente às cargas de trabalho do GKE.

1. Encontre os detalhes da sua instância do Filestore pré-aprovisionada seguindo as instruções em Obter informações sobre uma instância específica.

2. Volte a implementar a especificação PersistentVolume. No campo volumeAttributes, modifique os seguintes campos para usar os mesmos valores que a instância do Filestore do passo 1:

   • ip: modifique este valor para o endereço IP da instância do Filestore pré-aprovisionada.
   • volume: modifique este valor para o nome da partilha da instância do Filestore pré-aprovisionada. No claimRef, certifique-se de que faz referência ao mesmo PersistentVolumeClaim no passo 2.

3. Volte a implementar a especificação PersistentVolumeClaim.

4. Verifique o estado de associação do PersistentVolumeClaim e do PersistentVolume executando kubectl get pvc.

5. Volte a implementar a especificação do pod e certifique-se de que o pod consegue aceder novamente à partilha do Filestore.

O que se segue?

• Saiba como implementar uma carga de trabalho com estado do Filestore no GKE.
• Saiba como partilhar uma instância empresarial do Filestore com vários volumes persistentes.
• Saiba como usar a expansão do volume.
• Saiba como usar as capturas instantâneas de volume.
• Leia mais sobre o controlador CSI no GitHub.