En esta guía, se muestra cómo configurar recursos para el contenedor secundario 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 estos parámetros de configuración.
El controlador CSI de Cloud Storage FUSE usa un contenedor de sidecar personalizable para activar y acceder de manera eficiente a los buckets de Cloud Storage. Si configuras el sidecar, puedes ajustar el rendimiento de la aplicación y el uso de recursos, lo que puede generar un acceso más rápido a los datos, tiempos de procesamiento más rápidos y, posiblemente, un menor consumo general de recursos para tu aplicación.
Esta guía está dirigida a desarrolladores, administradores y arquitectos que desean 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 conocer 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 secundario para activar buckets de Cloud Storage y hacerlos accesibles como sistemas de archivos locales para las aplicaciones de Kubernetes. 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 secundario ayuda a garantizar la seguridad y administrar los recursos de manera eficaz.
El contenedor de sidecar controla las complejidades de la activación de los buckets de Cloud Storage y proporciona acceso al sistema de archivos para las aplicaciones sin necesidad de que administres el tiempo de ejecución de Cloud Storage FUSE directamente. Puedes configurar límites de recursos para el 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 finaliza automáticamente cuando terminan los contenedores de carga de trabajo, en especial en las cargas de trabajo de Job o los 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. El proxy de sidecar de Istio administra el tráfico de red, mientras que el sidecar 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 almacena las escrituras en un directorio local y, luego, las sube a Cloud Storage en operaciones close o fsync.
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 un disco 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 Selecciona el almacenamiento para hacer una copia de seguridad de tu 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 un 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: Es el ID defsGroup.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:
- Consulta esta tabla de compatibilidad de GKE para encontrar una imagen pública del contenedor del archivo adicional compatible.
- Extráelo a tu entorno local y envíalo a tu registro de contenedores privado.
En el manifiesto, especifica un contenedor llamado
gke-gcsfuse-sidecarsolo 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.
Configura los recursos del contenedor de sidecar
De forma predeterminada, el contenedor gke-gcsfuse-sidecar está configurado con las siguientes solicitudes y límites de recursos para los clústeres de Standard y Autopilot:
Solicitudes:
- 250 m de CPU
- 256 MiB de memoria
- Almacenamiento efímero de 5 GiB
Límites (versión 1.29.1-gke.1670000 de GKE y versiones posteriores):
- CPU ilimitada
- Memoria ilimitada
- Almacenamiento efímero ilimitado
Límites (antes de la versión 1.29.1-gke.1670000 de GKE):
- 250 m de CPU
- 256 MiB de memoria
- Almacenamiento efímero de 5 GiB
De forma predeterminada, el contenedor gke-gcsfuse-metadata-prefetch está configurado con las siguientes solicitudes y límites de recursos para los clústeres de Standard y Autopilot:
Solicitudes:
- 10 m de CPU
- 10 MiB de memoria
- 10 MiB de almacenamiento efímero
Límites:
- 50 m de CPU
- 250 MiB de memoria
- Almacenamiento efímero ilimitado
En los clústeres de Standard y Autopilot, puedes anular los valores predeterminados. La forma en que GKE controla los recursos de los contenedores depende del modo de operación del clúster:
- Clústeres estándar: Si se establece uno de los límites o solicitudes y el otro no, los límites y las solicitudes de recursos de los Pods se establecerán como iguales. Si se configuran tanto la solicitud como los límites, los Pods usan las solicitudes y los límites de recursos exactos que especificas. Si no estableces ningún valor, se aplicarán directamente los recursos predeterminados (descritos anteriormente).
- Clústeres de Autopilot: Si se establece una de las solicitudes o el límite y no se establece otro, los límites y las solicitudes de recursos de los Pods se establecerán como iguales. Consulta Cómo establecer límites de recursos en Autopilot para comprender cómo las anulaciones de recursos y los valores de recursos predeterminados establecidos afectarán el comportamiento del pod.
Para reemplazar los valores predeterminados del contenedor gke-gcsfuse-sidecar, puedes especificar la anotación gke-gcsfuse/[cpu-limit|memory-limit|ephemeral-storage-limit|cpu-request|memory-request|ephemeral-storage-request] de manera opcional, como se muestra en el siguiente ejemplo:
Para reemplazar los valores predeterminados del contenedor gke-gcsfuse-metadata-prefetch (a partir de la versión 1.32.3-gke.1717000 de GKE y versiones posteriores), puedes especificar de forma opcional la anotación gke-gcsfuse/[metadata-prefetch-cpu-limit|metadata-prefetch-memory-limit|metadata-prefetch-ephemeral-storage-limit|metadata-prefetch-cpu-request|metadata-prefetch-memory-request|metadata-prefetch-ephemeral-storage-request], como se muestra en el siguiente ejemplo:
apiVersion: v1
kind: Pod
metadata:
annotations:
gke-gcsfuse/volumes: "true"
# gke-gcsfuse-sidecar overrides
gke-gcsfuse/cpu-limit: "10"
gke-gcsfuse/memory-limit: 10Gi
gke-gcsfuse/ephemeral-storage-limit: 1Ti
gke-gcsfuse/cpu-request: 500m
gke-gcsfuse/memory-request: 1Gi
gke-gcsfuse/ephemeral-storage-request: 50Gi
# gke-gcsfuse-metadata-prefetch overrides
gke-gcsfuse/metadata-prefetch-cpu-limit: "10"
gke-gcsfuse/metadata-prefetch-memory-limit: 10Gi
gke-gcsfuse/metadata-prefetch-ephemeral-storage-limit: 1Ti
gke-gcsfuse/metadata-prefetch-cpu-request: 500m
gke-gcsfuse/metadata-prefetch-memory-request: 1Gi
gke-gcsfuse/metadata-prefetch-ephemeral-storage-request: 50Gi
Puedes usar el valor "0" para anular cualquier límite o solicitud de recursos, pero ten en cuenta que el contenedor gke-gcsfuse-sidecar ya tiene todos los límites (cpu-limit, memory-limit y ephemeral-storage-limit) anulados, y el contenedor gke-gcsfuse-metadata-prefetch ya tiene ephemeral-storage-limit anulado, por lo que establecer estos límites en "0" en un clúster con la versión 1.32.3-gke.1717000 de GKE o posterior no tendría ningún efecto.
Por ejemplo, si configuras gke-gcsfuse/metadata-prefetch-memory-limit: "0", indicas que quieres que se anule el límite de memoria del contenedor gke-gcsfuse-metadata-prefetch.
Esto es útil cuando no puedes decidir la cantidad de recursos que la función de recuperación previa de metadatos necesita para tus cargas de trabajo y deseas permitir que la recuperación previa de metadatos consuma todos los recursos disponibles en un nodo.
Configura la verbosidad del registro
De forma predeterminada, el contenedor gke-gcsfuse-sidecar genera registros en los niveles info y error.
Sin embargo, para la depuración o un análisis más detallado, es posible que debas ajustar el nivel de detalle del registro. En esta sección, se describe cómo aumentar o disminuir el nivel de registro.
Puedes usar opciones de activación para configurar el nivel de detalle del registro o usar la capacidad del controlador de CSI para traducir los valores del atributo de volumen en la configuración necesaria de gcsfuse.
En el manifiesto del Pod de destino, incluye las siguientes configuraciones:
volumeAttributes:
bucketName: BUCKET_NAME
mountOptions: "implicit-dirs"
gcsfuseLoggingSeverity: LOGGING_SEVERITY
Para usar las opciones de activación, incluye la siguiente configuración en el manifiesto del Pod de destino:
mountOptions: "logging:severity:LOGGING_SEVERITY"
Reemplaza lo siguiente:
BUCKET_NAME: el nombre de tu bucket de Cloud Storage.LOGGING_SEVERITY: Uno de los siguientes valores, según tus requisitos:tracedebuginfowarningerror
Después de implementar el Pod, el controlador CSI inicia gcsfuse con el nivel de registro recién configurado.
Puedes usar el siguiente filtro para verificar si se aplica la gravedad del registro:
resource.labels.container_name="gke-gcsfuse-sidecar"
resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
"severity:"
¿Qué sigue?
- Obtén información para optimizar el rendimiento del controlador de CSI de Cloud Storage FUSE.
- Explora muestras adicionales para usar el controlador de CSI en GitHub.
- Obtén más información sobre Cloud Storage Fuse.