Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

Monte contentores do Cloud Storage como volumes persistentes

Autopilot Padrão

Este guia mostra como usar volumes persistentes do Kubernetes suportados pelos seus contentores do Cloud Storage para gerir recursos de armazenamento para os seus pods do Kubernetes no Google Kubernetes Engine (GKE). Considere usar esta opção de armazenamento se já estiver familiarizado com os PersistentVolumes e quiser consistência com as suas implementações existentes que dependem deste tipo de recurso.

Este guia destina-se a administradores e operadores da plataforma que querem simplificar a gestão do armazenamento para as respetivas aplicações do GKE.

Antes de ler esta página, certifique-se de que conhece os volumes persistentes do Kubernetes, os pods do Kubernetes e os contentores do Cloud Storage.

Se quiser uma interface simplificada baseada em pods que não exija experiência anterior com volumes persistentes do Kubernetes, consulte o artigo Montar contentores do Cloud Storage como volumes efémeros da CSI.

Antes de começar

Certifique-se de que concluiu estes pré-requisitos:

Compreenda os requisitos e as limitações do controlador CSI do FUSE do Cloud Storage.
Crie o contentor do Cloud Storage
Ative o controlador CSI FUSE do Cloud Storage
Configure o acesso a contentores do Cloud Storage

Como funcionam os volumes persistentes para contentores do Cloud Storage

Com o aprovisionamento estático, cria um ou mais objetos PersistentVolume que contêm os detalhes do sistema de armazenamento subjacente. Em seguida, os pods nos seus clusters podem consumir o armazenamento através de PersistentVolumeClaims.

A utilização de um volume persistente com base num contentor do Cloud Storage envolve as seguintes operações:

Definição de armazenamento: define um PersistentVolume no seu cluster do GKE, incluindo o controlador CSI a usar e todos os parâmetros necessários. Para o controlador CSI do FUSE do Cloud Storage, especifica o nome do contentor e outros detalhes relevantes.

Opcionalmente, pode otimizar o desempenho do controlador CSI através da funcionalidade de colocação em cache de ficheiros. A colocação em cache de ficheiros pode melhorar o desempenho da app do GKE através da colocação em cache de ficheiros do Cloud Storage acedidos frequentemente num disco local mais rápido.

Além disso, pode usar a funcionalidade de transferência paralela para acelerar a leitura de ficheiros grandes do Cloud Storage para transferências com várias linhas de execução. Pode usar esta funcionalidade para melhorar os tempos de carregamento do modelo, especialmente para leituras com mais de 1 GB.

Sugestão: para ver formas adicionais de otimizar o desempenho do seu controlador CSI, consulte o artigo Otimize o desempenho do controlador CSI do FUSE do Cloud Storage.
Invocações de controladores: quando um PersistentVolumeClaim pede armazenamento que corresponda à especificação do PersistentVolume, o GKE invoca o controlador CSI do FUSE do Google Cloud Storage.
Montagem de contentores: o controlador CSI monta o contentor no nó onde o pod de pedido está agendado. Isto torna o conteúdo do contentor acessível ao Pod como um diretório no sistema de ficheiros local do Pod. Para otimizar a forma como os contentores são montados no sistema de ficheiros, pode usar opções de montagem. Também pode usar atributos de volume para configurar o comportamento específico do controlador CSI do FUSE do Cloud Storage.
Nova associação: se o pod for reiniciado ou reagendado para outro nó, o controlador CSI volta a montar o mesmo contentor no novo nó, garantindo a acessibilidade aos dados.

Crie um PersistentVolume

Crie um manifesto PersistentVolume com a seguinte especificação:
Pod
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: gcs-fuse-csi-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 5Gi
  storageClassName: example-storage-class  
  mountOptions:
    - implicit-dirs
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: BUCKET_NAME
  claimRef:
    name: gcs-fuse-csi-static-pvc
    namespace: NAMESPACE  
```
Substitua os seguintes valores:
- NAMESPACE: o namespace do Kubernetes onde quer implementar o seu pod.
- BUCKET_NAME: o nome do contentor do Cloud Storage que especificou quando configurou o acesso aos contentores do Cloud Storage. Pode especificar um sublinhado (_) para montar todos os contentores aos quais a conta de serviço do Kubernetes pode aceder. Para saber mais, consulte o artigo Montagem dinâmica na documentação do Cloud Storage FUSE.
O manifesto de exemplo mostra estas definições obrigatórias:
- spec.csi.driver: use gcsfuse.csi.storage.gke.io como o nome do controlador CSI.
Opcionalmente, pode ajustar estas variáveis:
- spec.mountOptions: passe opções de montagem para o Cloud Storage FUSE. Especifique as flags numa única string separada por vírgulas, sem espaços.
- spec.csi.volumeAttributes: transmita atributos de volume adicionais para o Cloud Storage FUSE.
Agrupamento (colocação em cache de ficheiros)
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: gcs-fuse-csi-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 5Gi
  storageClassName: example-storage-class 
  mountOptions:
    - implicit-dirs
    - file-cache:max-size-mb:-1
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: BUCKET_NAME
  claimRef:
    name: gcs-fuse-csi-static-pvc
    namespace: NAMESPACE 
```
Substitua os seguintes valores:
- NAMESPACE: o namespace do Kubernetes onde quer implementar o seu pod.
- BUCKET_NAME: o nome do contentor do Cloud Storage que especificou ao configurar o acesso aos contentores do Cloud Storage. Pode especificar um caráter de sublinhado (_) para montar todos os contentores aos quais a conta de serviço do Kubernetes pode aceder. Para saber mais, consulte o artigo Montagem dinâmica na documentação do Cloud Storage FUSE.
Agrupamento (transferência paralela)
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: gcs-fuse-csi-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 5Gi
  storageClassName: example-storage-class 
  mountOptions:
    - implicit-dirs
    - file-cache:enable-parallel-downloads:true
    - file-cache:max-size-mb:-1
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: BUCKET_NAME
  claimRef:
    name: gcs-fuse-csi-static-pvc
    namespace: NAMESPACE 
```
Substitua os seguintes valores:
- NAMESPACE: o namespace do Kubernetes onde quer implementar o seu pod.
- BUCKET_NAME: o nome do contentor do Cloud Storage que especificou ao configurar o acesso aos contentores do Cloud Storage. Pode especificar um caráter de sublinhado (_) para montar todos os contentores aos quais a conta de serviço do Kubernetes pode aceder. Para saber mais, consulte o artigo Montagem dinâmica na documentação do Cloud Storage FUSE.
Aplique o manifesto ao cluster:
```
kubectl apply -f PV_FILE_PATH
```
Substitua PV_FILE_PATH pelo caminho para o seu ficheiro YAML.

Crie um PersistentVolumeClaim

Crie um manifesto PersistentVolumeClaim com a seguinte especificação:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcs-fuse-csi-static-pvc
  namespace: NAMESPACE
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: example-storage-class
```
Substitua NAMESPACE pelo espaço de nomes do Kubernetes onde quer implementar o seu pod.

Para associar o PersistentVolume a um PersistentVolumeClaim, verifique estas definições de configuração:
- Os campos spec.storageClassName nos manifestos PersistentVolume e PersistentVolumeClaim devem corresponder. O storageClassName não tem de fazer referência a um objeto StorageClass existente. Para associar a reivindicação a um volume, pode usar qualquer nome que quiser, mas não pode estar vazio.
- Os campos spec.accessModes nos manifestos PersistentVolume e PersistentVolumeClaim devem corresponder.
- spec.capacity.storage no manifesto PersistentVolume deve corresponder a spec.resources.requests.storage no manifesto PersistentVolumeClaim. Uma vez que os contentores do Cloud Storage não têm limites de tamanho, pode introduzir qualquer número para a capacidade, mas não pode estar vazio.
Aplique o manifesto ao cluster:
```
kubectl apply -f PVC_FILE_PATH
```
Substitua PVC_FILE_PATH pelo caminho para o seu ficheiro YAML.

Consuma o volume num agrupamento

Crie um manifesto de Pod com a seguinte especificação:
```
apiVersion: v1
kind: Pod
metadata:
  name: gcs-fuse-csi-example-static-pvc  
  namespace: NAMESPACE
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  containers:
  - image: busybox
    name: busybox
    command: ["sleep"]
    args: ["infinity"]
    volumeMounts:
    - name: gcs-fuse-csi-static
      mountPath: /data
      readOnly: true
  serviceAccountName: KSA_NAME
  volumes:
  - name: gcs-fuse-csi-static
    persistentVolumeClaim:
      claimName: gcs-fuse-csi-static-pvc
      readOnly: true  
```
Substitua os seguintes valores:
- NAMESPACE: o namespace do Kubernetes onde quer implementar o seu pod.
- KSA_NAME: o nome da conta de serviço do Kubernetes que criou quando configurou o acesso aos contentores do Cloud Storage.
O manifesto de exemplo mostra estas definições obrigatórias:
- metadata.annotations: a anotação gke-gcsfuse/volumes: "true" é obrigatória. Consulte o artigo Configure o contentor auxiliar para ver anotações opcionais.
Opcionalmente, pode ajustar estas variáveis:
- spec.containers[n].volumeMonts[n].readOnly: especifique true se apenas montagens de volume específicas forem só de leitura.
- spec.volumes[n].persistentVolumeClaim.readOnly: especifique true se todas as montagens de volume forem só de leitura.
Aplique o manifesto ao cluster:
```
kubectl apply -f POD_FILE_PATH
```
Substitua POD_FILE_PATH pelo caminho para o seu ficheiro YAML.

(Opcional) Monte o mesmo contentor do Cloud Storage com diferentes volumes persistentes

A partir da versão 1.33.0-gke.1932000 do GKE, pode usar vários PersistentVolumes suportados pelo mesmo contentor do Cloud Storage. Em cada objeto PersistentVolume, tem de usar um volumeHandle exclusivo no formato BUCKET_NAME:UNIQUE_SUFFIX.

Um exemplo de utilização pode ser a montagem de diferentes PersistentVolumes com diferentes opções de montagem no mesmo Pod, em que cada PersistentVolume se refere ao mesmo contentor do Cloud Storage.

Resolver problemas

Para mais informações sobre a resolução de problemas do controlador CSI do FUSE do Cloud Storage, consulte o guia de resolução de problemas na documentação do projeto do GitHub.