Crie e use um volume suportado por uma instância do Parallelstore no Google Kubernetes Engine

A Parallelstore está disponível apenas por convite. Se quiser pedir acesso à Parallelstore no seu Google Cloud projeto, contacte o seu representante de vendas.

Este guia descreve como pode criar um novo volume do Kubernetes com base num controlador CSI do Parallelstore no GKE com aprovisionamento dinâmico. Isto permite-lhe criar armazenamento com base em instâncias do Parallelstore totalmente geridas a pedido e aceder a elas como volumes para as suas cargas de trabalho com estado.

Antes de começar

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

  • Ative a API Parallelstore 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.

Crie um novo volume com o controlador CSI Parallelstore

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

  1. (Opcional) Crie uma StorageClass.
  2. Use um PersistentVolumeClaim para aceder ao volume.
  3. (Opcional) Configure recursos para o contentor auxiliar.
  4. Crie uma carga de trabalho que consuma o volume.

(Opcional) Crie uma classe de armazenamento

Quando o controlador CSI Parallelstore está ativado, o GKE cria automaticamente uma StorageClass denominada parallelstore-rwx para o aprovisionamento de instâncias do Parallelstore. Esta StorageClass direciona o controlador CSI para aprovisionar instâncias do Parallelstore na mesma região que o cluster do GKE para garantir um desempenho de E/S ideal.

Opcionalmente, pode criar uma StorageClass personalizada com uma topologia específica. Para o fazer, siga estes passos:

  1. Guarde o manifesto StorageClass seguinte num ficheiro denominado parallelstore-class.yaml:

    Montagem de agrupamento

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: parallelstore-class
provisioner: parallelstore.csi.storage.gke.io
volumeBindingMode: Immediate
reclaimPolicy: Delete
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
      LOCATION

    Substitua o seguinte:

    • LOCATION: a zona do Compute Engine que contém o cluster. Tem de especificar uma zona suportada para o controlador CSI Parallelstore.

    Para ver a lista completa de campos suportados na StorageClass, consulte a documentação de referência da CSI Parallelstore.

    Montagem de nós

    O controlador CSI Parallelstore permite-lhe montar volumes diretamente nos seus nós. A montagem de nós é suportada em clusters do GKE na versão 1.32.3 e posteriores.

    A montagem ao nível do nó permite que todos os pods num nó partilhem o mesmo ponto de montagem. A partilha do mesmo ponto de montagem melhora a escalabilidade porque o número de montagens aumenta com o número de nós e não com o número de pods (como no modo sidecar).

    Como resultado, pode executar mais pods enquanto partilha a mesma instância do Parallelstore.

    Nota: esta funcionalidade é ativada especificando o parâmetro mountLocality: node. O valor predefinido para a localidade de montagem do pod é mountLocality: pod. A CPU, os pedidos de memória e os flags de limite do dfuse só funcionam com a definição mountLocality: node.

    Se o valor do pedido ou o limite for definido e o outro não for definido, ambos são definidos com o mesmo valor especificado.

    Pode usar "0" como valor para anular a definição de quaisquer limites de recursos. Por exemplo, dfuseMemoryLimit: '0' remove o limite de memória para o processo dfuse. 
      apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: parallelstore-class
  provisioner: parallelstore.csi.storage.gke.io
  volumeBindingMode: Immediate
  reclaimPolicy: Delete
  allowedTopologies:
  - matchLabelExpressions:
    - key: topology.gke.io/zone
      values:
        LOCATION
  parameters:
    mountLocality: node
    dfuseCPURequest: DFUSE_CPU_REQUEST
    dfuseMemoryRequest: DFUSE_MEMORY_REQUEST
    dfuseCPULimit: DFUSE_CPU_LIMIT
    dfuseMemoryLimit: DFUSE_MEMORY_LIMIT

    Substitua o seguinte:

    • LOCATION: a zona do Compute Engine que contém o cluster. Tem de especificar uma zona suportada para o controlador CSI Parallelstore.
    • DFUSE_CPU_REQUEST: o pedido de CPU para o processo dfuse. A predefinição é 250m.
    • DFUSE_MEMORY_REQUEST: o pedido de memória para o processo dfuse. A predefinição é 512Mi.
    • DFUSE_CPU_LIMIT: o limite da CPU para o processo dfuse. Por predefinição, o valor não está definido.
    • DFUSE_MEMORY_LIMIT: o limite de memória para o processo dfuse. A predefinição é 10Gi.

    Para ver a lista completa de campos suportados na StorageClass, consulte a documentação de referência da CSI Parallelstore.

  2. Execute este comando para criar a StorageClass:

    kubectl create -f parallelstore-class.yaml

Use um PersistentVolumeClaim para aceder ao volume

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

O ficheiro de manifesto seguinte mostra um exemplo de como criar um PersistentVolumeClaim no ReadWriteMany modo de acesso que faz referência à StorageClass que criou anteriormente.

  1. Guarde o seguinte manifesto num ficheiro com o nome parallelstore-pvc.yaml:

      apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: parallelstore-pvc
  spec:
    accessModes:
    - ReadWriteMany
    resources:
      requests:
        storage: STORAGE_SIZE
    storageClassName: parallelstore-class

    Substitua STORAGE_SIZE pelo tamanho do armazenamento; por exemplo, 12000Gi. O valor tem de estar no intervalo de 12 000 GiB a 100 000 GiB (em múltiplos de 4000 GiB).

  2. Execute este comando para criar o PersistentVolumeClaim:

      kubectl create -f parallelstore-pvc.yaml

(Opcional) Configure recursos para o contentor sidecar

Nota: só pode configurar recursos para o contentor sidecar se usar a localidade de montagem do pod, ou seja, o atributo de volume mountLocality no seu PersistentVolume não estiver definido ou estiver definido como pod

Quando cria um pod de carga de trabalho que usa volumes suportados por Parallelstore, o controlador CSI determina se o seu volume se baseia em instâncias do Parallelstore.

Se o controlador detetar que o seu volume se baseia no Parallelstore ou se especificar a anotação gke-parallelstore/volumes: "true", o controlador CSI injeta automaticamente um contentor sidecar denominado gke-parallelstore-sidecar no seu pod. Este contentor auxiliar monta a instância do Parallelstore na sua carga de trabalho.

Por predefinição, o GKE configura o contentor sidecar com os seguintes pedidos de recursos, com os limites de recursos não definidos:

  • 250 m CPU
  • 512 MiB de memória
  • 10 MiB de armazenamento temporário

Para substituir estes valores, pode especificar opcionalmente a anotação gke-parallelstore/[cpu-request|memory-request|cpu-limit|memory-limit|ephemeral-storage-request] conforme mostrado no exemplo seguinte:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-parallelstore/volumes: "true"
    gke-parallelstore/cpu-request: 500m
    gke-parallelstore/memory-request: 1Gi
    gke-parallelstore/ephemeral-storage-request: 500Mi
    gke-parallelstore/cpu-limit: 1000m
    gke-parallelstore/memory-limit: 2Gi
    gke-parallelstore/ephemeral-storage-limit: 1Gi

Use as seguintes considerações quando decidir a quantidade de recursos a atribuir:

  • Se um dos valores de pedido ou limite for definido e outro não for definido, ambos os valores são definidos com o mesmo valor especificado.
  • Atribua mais CPU ao contentor auxiliar se as suas cargas de trabalho precisarem de um débito mais elevado. A CPU insuficiente causa a limitação de E/S.
  • Pode usar "0" como valor para anular a definição de quaisquer limites de recursos em clusters padrão; por exemplo, gke-parallelstore/memory-limit: "0"remove o limite de memória para o contentor sidecar. Isto é útil quando não consegue decidir a quantidade de recursos que o gke-parallelstore-sidecar precisa para as suas cargas de trabalho e quer permitir que o sidecar consuma todos os recursos disponíveis num nó.

Crie uma carga de trabalho que consuma o volume

Esta secção mostra um exemplo de como criar um Pod que consuma o recurso PersistentVolumeClaim que criou anteriormente.

Vários pods podem partilhar o mesmo recurso PersistentVolumeClaim.

  1. Guarde o seguinte manifesto num ficheiro com o nome my-pod.yaml.

      apiVersion: v1
  kind: Pod
  metadata:
    name: my-pod
  spec:
    containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: parallelstore-volume
          mountPath: /data
    volumes:
    - name: parallelstore-volume
      persistentVolumeClaim:
        claimName: parallelstore-pvc

  2. Execute o seguinte comando para aplicar o manifesto ao cluster.

      kubectl apply -f my-pod.yaml

    O pod aguarda até que o PersistentVolumeClaim seja aprovisionado antes de começar a ser executado. Esta operação pode demorar alguns minutos a ser concluída.

Faça a gestão do controlador CSI do Parallelstore

Esta secção aborda como pode ativar e desativar o controlador CSI Parallelstore, se necessário.

Ative o controlador CSI Parallelstore num novo cluster

Para ativar o controlador CSI Parallelstore quando criar um novo cluster Standard, execute o seguinte comando com a CLI gcloud:

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --network=NETWORK_NAME \
    --addons=ParallelstoreCsiDriver \
    --cluster-version=VERSION

Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: a zona do Compute Engine que contém o cluster. Tem de especificar uma zona suportada para o controlador CSI Parallelstore.
  • NETWORK_NAME: nome da rede VPC que criou em Configure uma rede VPC.
  • VERSION: o número da versão do GKE. Tem de especificar um número de versão suportado para usar esta funcionalidade, como a versão 1.29 ou posterior do GKE. Em alternativa, pode usar a flag --release-channel e especificar um canal de lançamento.

Ative o controlador CSI Parallelstore num cluster existente

Para ativar o controlador num cluster padrão do GKE existente, execute o seguinte comando com a CLI do Google Cloud:

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --update-addons=ParallelstoreCsiDriver=ENABLED

Substitua o seguinte:

  • CLUSTER_NAME : o nome do seu cluster.
  • LOCATION: a zona do Compute Engine que contém o cluster. Tem de especificar uma zona suportada para o controlador CSI Parallelstore.

Certifique-se de que o cluster do GKE está a ser executado na mesma rede de VPC que configurou em Configure uma rede de VPC. Para validar a rede VPC de um cluster do GKE, pode verificar naGoogle Cloud consola ou através do comando gcloud container clusters describe $(CLUSTER) --format="value(networkConfig.network)" --location=$(LOCATION).

Desative o controlador CSI Parallelstore

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

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --update-addons=ParallelstoreCsiDriver=DISABLED

Substitua o seguinte:

  • CLUSTER_NAME : o nome do seu cluster.
  • LOCATION: a zona do Compute Engine que contém o cluster. Tem de especificar uma zona suportada para o controlador CSI Parallelstore.

Use fsGroup com volumes Parallelstore

O controlador CSI Parallelstore suporta a alteração da propriedade do grupo do diretório de nível raiz do sistema de ficheiros montado para corresponder a um fsGroup pedido pelo utilizador especificado no SecurityContext do pod. Esta funcionalidade só é suportada em clusters do GKE com a versão 1.29.5 ou posterior, ou a versão 1.30.1 ou posterior.

Resolução de problemas

Para orientações de resolução de problemas, consulte a página Resolução de problemas na documentação do Parallelstore.

O que se segue?