Configurar o contêiner secundário do driver CSI do Cloud Storage FUSE para o GKE

Este guia mostra como configurar recursos para o contêiner de sidecar do driver do CSI do Cloud Storage FUSE, incluindo a configuração de uma imagem particular, um buffer de gravação personalizado e um volume de cache de leitura personalizado. Normalmente, não é preciso mudar essas configurações.

O driver CSI do Cloud Storage FUSE usa um contêiner secundário personalizável para montar e acessar buckets do Cloud Storage de maneira eficiente. Ao configurar o sidecar, você pode ajustar o desempenho do aplicativo e o uso de recursos, o que pode resultar em acesso mais rápido aos dados, tempos de processamento mais rápidos e, potencialmente, menor consumo de recursos geral do aplicativo.

Este guia é destinado a desenvolvedores, administradores e arquitetos que querem otimizar a performance, a segurança e a eficiência dos aplicativos que interagem com o GKE.

Antes de ler esta página, confira se você conhece os conceitos básicos do Cloud Storage, do Kubernetes e do contêiner.

Como o contêiner sidecar funciona

O driver CSI do Cloud Storage FUSE usa um contêiner de sidecar para montar buckets do Cloud Storage e torná-los acessíveis como sistemas de arquivos locais para aplicativos do Kubernetes. Esse contêiner de sidecar, chamado gke-gcsfuse-sidecar, é executado junto com o contêiner de carga de trabalho no mesmo pod. Quando o driver detecta a anotação gke-gcsfuse/volumes: "true" em uma especificação de pod, ele injeta automaticamente o contêiner de sidecar. Essa abordagem de contêiner de sidecar ajuda a garantir a segurança e gerenciar recursos de maneira eficaz.

O contêiner secundário lida com as complexidades de montagem dos buckets do Cloud Storage e oferece acesso ao sistema de arquivos para os aplicativos sem exigir que você gerencie o runtime do Cloud Storage FUSE diretamente. É possível configurar limites de recursos para o contêiner de arquivos secundários usando anotações como gke-gcsfuse/cpu-limit e gke-gcsfuse/memory-limit. O modelo de contêiner sidecar também garante que a instância do Cloud Storage FUSE seja vinculada ao ciclo de vida da carga de trabalho, evitando que ela consuma recursos desnecessariamente. Isso significa que o contêiner secundário é encerrado automaticamente quando os contêineres de carga de trabalho são encerrados, principalmente em cargas de trabalho de jobs ou pods com um RestartPolicy de Never.

Compatibilidade com o Istio

O contêiner secundário do driver CSI do Cloud Storage FUSE e o Istio podem coexistir e ser executados simultaneamente no pod. O proxy sidecar do Istio gerencia o tráfego de rede, enquanto o sidecar CSI otimiza o acesso ao armazenamento, permitindo que seus aplicativos interajam de maneira eficiente com o Google Cloud Storage com melhor desempenho e observabilidade.

Configurar buffer de gravação personalizado

O Cloud Storage FUSE prepara gravações em um diretório local e faz o upload para o Cloud Storage em operações close ou fsync. O buffer de gravação não está ativado por padrão.

Esta seção descreve como configurar um volume de buffer personalizado para o armazenamento em buffer de gravação do Cloud Storage FUSE. Este cenário pode ser aplicável se você precisar substituir o volume emptyDir padrão do Cloud Storage FUSE para preparar os arquivos em operações de gravação. Isso é útil se você precisar gravar arquivos maiores que 10 GiB nos clusters do Autopilot.

É possível especificar qualquer tipo de armazenamento compatível com o driver CSI do Cloud Storage FUSE para armazenamento em cache de arquivos, como um SSD local, armazenamento baseado em Persistent Disk e disco RAM (memória). O GKE vai usar o volume especificado para armazenamento em buffer de gravação de arquivo. Para saber mais sobre essas opções, consulte Selecionar o armazenamento para fazer backup do cache de arquivos.

Para usar o volume de buffer personalizado, é necessário especificar um fsGroup diferente de zero.

O exemplo a seguir mostra como usar um PersistentVolumeClaim predefinido como o volume de buffer:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  securityContext:
    fsGroup: FS_GROUP
  containers:
  ...
  volumes:
  - name: gke-gcsfuse-buffer
    persistentVolumeClaim:
      claimName: BUFFER_VOLUME_PVC

Substitua:

  • FS_GROUP: o ID do fsGroup.
  • BUFFER_VOLUME_PVC: o nome da PVC predefinida.

Configurar volume de cache de leitura personalizado

Esta seção descreve como configurar um volume de cache personalizado para o armazenamento em cache de leitura do Cloud Storage FUSE.

Este cenário pode ser aplicável se você precisar substituir o volume emptyDir padrão do Cloud Storage FUSE para armazenar os arquivos em cache em operações de leitura. É possível especificar qualquer tipo de armazenamento compatível com o GKE, como um PersistentVolumeClaim, e o GKE usará o volume especificado para armazenamento em buffer de gravação de arquivo. Isso é útil se você precisar armazenar em cache arquivos maiores que 10 GiB em clusters do Autopilot. Para usar o volume de cache personalizado, é necessário especificar um fsGroup diferente de zero.

O exemplo a seguir mostra como usar um PersistentVolumeClaim predefinido como o volume de cache:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  securityContext:
    fsGroup: FS_GROUP
  containers:
  ...
  volumes:
  - name: gke-gcsfuse-cache
    persistentVolumeClaim:
      claimName: CACHE_VOLUME_PVC

Substitua:

  • FS_GROUP: o ID do fsGroup.
  • CACHE_VOLUME_PVC: o nome predefinido do PersistentVolumeClaim.

Configurar uma imagem particular para o contêiner sidecar

Nesta seção, descrevemos como usar a imagem do contêiner secundário quando você a hospeda em um registro de contêiner particular. Esse cenário pode ser aplicado se você precisar usar nós particulares para fins de segurança.

Para configurar e consumir a imagem do contêiner secundário particular, siga estas etapas:

  1. Consulte esta tabela de compatibilidade do GKE para encontrar uma imagem de contêiner secundário público compatível.
  2. Extraia-a para o ambiente local e envie para o registro de contêiner particular.

  3. No manifesto, especifique um contêiner chamado gke-gcsfuse-sidecar com apenas o campo de imagem. O GKE vai usar a imagem do contêiner sidecar especificada para se preparar para a injeção do contêiner sidecar.

    Veja um exemplo:

    apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  containers:
  - name: gke-gcsfuse-sidecar
    image: PRIVATE_REGISTRY/gcs-fuse-csi-driver-sidecar-mounter:PRIVATE_IMAGE_TAG
  - name: main # your main workload container.

    Substitua:

    • PRIVATE_REGISTRY: o registro de contêiner particular.
    • PRIVATE_IMAGE_TAG: a tag de imagem do contêiner secundário particular.

A seguir