Configura el contenedor de sidecar del controlador de CSI del FUSE de Cloud Storage para GKE

En esta guía, se muestra cómo configurar recursos para el contenedor del archivo adicional del controlador CSI de Cloud Storage FUSE, lo que incluye la configuración de una imagen privada, un búfer de escritura personalizado y un volumen de caché de lectura personalizado. Por lo general, no es necesario cambiar esta configuración.

El controlador de CSI del FUSE de Cloud Storage usa un contenedor de sidecar personalizable para activar y acceder de manera eficiente a los buckets de Cloud Storage. Si configuras el conjunto de herramientas secundario, puedes ajustar el rendimiento de la aplicación y el uso de recursos, lo que puede generar un acceso a los datos más rápido, tiempos de procesamiento más rápidos y, posiblemente, un consumo de recursos general más bajo para tu aplicación.

Esta guía está dirigida a desarrolladores, administradores y arquitectos que deseen optimizar el rendimiento, la seguridad y la eficiencia de sus aplicaciones que interactúan con GKE.

Antes de leer esta página, asegúrate de estar familiarizado con los conceptos básicos de Cloud Storage, Kubernetes y la contenedorización.

Cómo funciona el contenedor Sidecar

El controlador CSI de Cloud Storage FUSE usa un contenedor lateral para activar los buckets de Cloud Storage y permitir que las aplicaciones de Kubernetes accedan a ellos como sistemas de archivos locales. Este contenedor de sidecar, llamado gke-gcsfuse-sidecar, se ejecuta junto con el contenedor de carga de trabajo dentro del mismo Pod. Cuando el controlador detecta la anotación gke-gcsfuse/volumes: "true" en una especificación de Pod, inserta automáticamente el contenedor de sidecar. Este enfoque de contenedor lateral ayuda a garantizar la seguridad y administrar los recursos de manera eficaz.

El contenedor de sidecar controla las complejidades de activar los buckets de Cloud Storage y proporciona acceso al sistema de archivos a las aplicaciones sin necesidad de que administres el entorno de ejecución de Cloud Storage FUSE directamente. Puedes configurar los límites de recursos del contenedor de sidecar con anotaciones como gke-gcsfuse/cpu-limit y gke-gcsfuse/memory-limit. El modelo de contenedor de sidecar también garantiza que la instancia de Cloud Storage FUSE esté vinculada al ciclo de vida de la carga de trabajo, lo que evita que consuma recursos de forma innecesaria. Esto significa que el contenedor de sidecar se finaliza automáticamente cuando se cierran los contenedores de carga de trabajo, en especial en las cargas de trabajo de Job o en Pods con un RestartPolicy de Never.

Compatibilidad con Istio

El contenedor de sidecar del controlador de CSI del FUSE de Cloud Storage y Istio pueden coexistir y ejecutarse de forma simultánea en tu pod. Proxy de sidecar de Istio administra el tráfico de red, mientras que el contenedor secundario de CSI optimiza el acceso al almacenamiento, lo que permite que tus aplicaciones interactúen de manera eficiente con Google Cloud Storage con un rendimiento y una observabilidad mejorados.

Configura un búfer de escritura personalizado

Cloud Storage FUSE pone en cola las operaciones de escritura en un directorio local y, luego, las sube a Cloud Storage en operaciones close o fsync. El almacenamiento en búfer de escritura no está habilitado de forma predeterminada.

En esta sección, se describe cómo configurar un volumen de búfer personalizado para el almacenamiento en búfer de escritura de Cloud Storage FUSE. Esta situación puede aplicarse si necesitas reemplazar el volumen emptyDir predeterminado para Cloud Storage FUSE a fin de almacenar en etapa intermedia los archivos en las operaciones de escritura. Esto es útil si necesitas escribir archivos de más de 10 GiB en clústeres de Autopilot.

Puedes especificar cualquier tipo de almacenamiento compatible con el controlador de CSI de Cloud Storage FUSE para el almacenamiento en caché de archivos, como un SSD local, almacenamiento basado en Persistent Disk y disco de RAM (memoria). GKE usará el volumen especificado para el almacenamiento en búfer de la escritura de archivos. Para obtener más información sobre estas opciones, consulta Cómo seleccionar el almacenamiento para crear una copia de seguridad de la caché de archivos.

Para usar el volumen de búfer personalizado, debes especificar un fsGroup que no sea cero.

En el siguiente ejemplo, se muestra cómo puedes usar un PersistentVolumeClaim predefinido como volumen de búfer:

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

Reemplaza lo siguiente:

  • FS_GROUP: es el ID de fsGroup.
  • BUFFER_VOLUME_PVC: Es el nombre predefinido de la PVC.

Configura el volumen de caché de lectura personalizado

En esta sección, se describe cómo configurar un volumen de caché personalizado para el almacenamiento en caché de lectura de Cloud Storage FUSE.

Esta situación puede aplicarse si necesitas reemplazar el volumen emptyDir predeterminado para Cloud Storage FUSE a fin de almacenar en caché los archivos en las operaciones de lectura. Puedes especificar cualquier tipo de almacenamiento compatible con GKE, como un PersistentVolumeClaim, y GKE usará el volumen especificado para el almacenamiento en caché de archivos. Esto es útil si necesitas guardar en caché archivos de más de 10 GiB en clústeres de Autopilot. Para usar el volumen de caché personalizado, debes especificar un fsGroup que no sea cero.

En el siguiente ejemplo, se muestra cómo puedes usar un PersistentVolumeClaim predefinido como volumen de caché:

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

Reemplaza lo siguiente:

  • FS_GROUP: El ID de fsGroup.
  • CACHE_VOLUME_PVC: Es el nombre predefinido de PersistentVolumeClaim.

Configura una imagen privada para el contenedor del archivo adicional

En esta sección, se describe cómo usar la imagen del contenedor del archivo adicional si la alojas en un Container Registry privado. Esta situación podría aplicarse si necesitas usar nodos privados por motivos de seguridad.

Para configurar y consumir la imagen privada del contenedor del archivo adicional, sigue estos pasos:

  1. Consulta esta tabla de compatibilidad de GKE para encontrar una imagen pública del contenedor del archivo adicional compatible.
  2. Extráelo a tu entorno local y envíalo a tu registro de contenedores privado.

  3. En el manifiesto, especifica un contenedor llamado gke-gcsfuse-sidecar solo con el campo de imagen. GKE usará la imagen de contenedor de sidecar especificada para prepararse para la inserción del contenedor de sidecar.

    A continuación, se muestra un ejemplo:

    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.

    Reemplaza lo siguiente:

    • PRIVATE_REGISTRY: Es tu registro de contenedores privado.
    • PRIVATE_IMAGE_TAG: Es tu etiqueta privada de la imagen del contenedor del archivo adicional.

¿Qué sigue?