En esta guía se muestra cómo configurar recursos para el contenedor sidecar del controlador CSI de Cloud Storage FUSE, como configurar una imagen privada, un búfer de escritura personalizado y un volumen de caché de lectura personalizado. Por lo general, no es necesario que cambies estos ajustes.
El controlador de CSI de Cloud Storage FUSE usa un contenedor sidecar personalizable para montar y acceder de forma eficiente a los segmentos de Cloud Storage. Al configurar el sidecar, puedes optimizar el rendimiento de la aplicación y el uso de los recursos, lo que puede dar lugar a un acceso a los datos más rápido, 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 quieran 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 que conoces los conceptos básicos de Cloud Storage, Kubernetes y la creación de contenedores.
Cómo funciona el contenedor sidecar
El controlador CSI de Cloud Storage FUSE usa un contenedor sidecar para montar segmentos de Cloud Storage y hacer que sean accesibles como sistemas de archivos locales para las aplicaciones de Kubernetes. Este contenedor auxiliar, llamado gke-gcsfuse-sidecar, se ejecuta junto con el contenedor de carga de trabajo en el mismo pod. Cuando el controlador detecta la anotación gke-gcsfuse/volumes: "true" en una especificación de Pod, inserta automáticamente el contenedor sidecar. Este enfoque de contenedor auxiliar ayuda a garantizar la seguridad y a gestionar los recursos de forma eficaz.
El contenedor sidecar gestiona las complejidades del montaje de los contenedores de Cloud Storage y proporciona acceso al sistema de archivos a las aplicaciones sin que tengas que gestionar directamente el tiempo de ejecución de Cloud Storage FUSE. Puedes configurar límites de recursos para el contenedor sidecar mediante anotaciones como gke-gcsfuse/cpu-limit y gke-gcsfuse/memory-limit. El modelo de contenedor sidecar también asegura que la instancia de Cloud Storage FUSE esté vinculada al ciclo de vida de la carga de trabajo, lo que evita que consuma recursos innecesariamente. Esto significa que el contenedor sidecar finaliza automáticamente cuando se cierran los contenedores de la carga de trabajo, especialmente en las cargas de trabajo de tipo Job o en los pods con un RestartPolicy de Never.
Compatibilidad con Istio
El contenedor sidecar del controlador CSI de FUSE de Cloud Storage e Istio pueden coexistir y ejecutarse simultáneamente en tu pod. El proxy sidecar de Istio gestiona 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 forma eficiente con Google Cloud Storage con un rendimiento y una observabilidad mejorados.
Configurar un búfer de escritura personalizado
Cloud Storage FUSE pone en el área de stage las escrituras en un directorio local y, a continuación, las sube a Cloud Storage en las 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. Este caso puede darse si necesitas sustituir el volumen emptyDir predeterminado de Cloud Storage FUSE para organizar los archivos en operaciones de escritura. Esto resulta ú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 CSI de Cloud Storage FUSE para el almacenamiento en caché de archivos, como una unidad SSD local, almacenamiento basado en discos persistentes y un disco RAM (memoria). GKE usará el volumen especificado para el almacenamiento en búfer de escritura de archivos. Para obtener más información sobre estas opciones, consulta Seleccionar el almacenamiento para crear una copia de seguridad de la caché de archivos.
Para usar el volumen de búfer personalizado, debe especificar un fsGroup distinto de 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
Haz los cambios siguientes:
- FS_GROUP: el ID de fsGroup.
- BUFFER_VOLUME_PVC: nombre de la PVC predefinida.
Configurar un volumen de caché de lectura personalizado
En esta sección se describe cómo configurar un volumen de caché personalizado para la caché de lectura de Cloud Storage FUSE.
Este caso puede darse si necesitas sustituir el volumen emptyDir predeterminado para que Cloud Storage FUSE almacene en caché los archivos en 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 almacenar 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 distinto de 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
Haz los cambios siguientes:
FS_GROUP: el ID defsGroup.CACHE_VOLUME_PVC: nombre de PersistentVolumeClaim predefinido.
Configurar una imagen privada para el contenedor sidecar
En esta sección se describe cómo usar la imagen del contenedor sidecar si la aloja en un registro de contenedores privado. Este caso puede darse si necesitas usar nodos privados por motivos de seguridad.
Para configurar y consumir la imagen del contenedor sidecar privado, sigue estos pasos:
- Consulta esta tabla de compatibilidad de GKE para encontrar una imagen de contenedor sidecar pública compatible.
- Descárgala en tu entorno local y súbela a tu registro de contenedores privado.
En el archivo de manifiesto, especifica un contenedor llamado
gke-gcsfuse-sidecarcon solo el campo de imagen. GKE usará la imagen de contenedor sidecar especificada para preparar la inyección del contenedor 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.Haz los cambios siguientes:
PRIVATE_REGISTRY: tu registro de contenedores privado. Por ejemplo,us-central1-docker.pkg.dev/my-project/my-registry.PRIVATE_IMAGE_TAG: etiqueta de imagen de tu contenedor sidecar privado. Por ejemplo,v1.17.1-gke.1.
Configurar recursos de contenedores sidecar
De forma predeterminada, el contenedor gke-gcsfuse-sidecar se configura con las siguientes solicitudes y límites de recursos para los clústeres Standard y Autopilot:
Solicitudes:
- CPU de 250 m
- 256 MiB de memoria
- 5 GiB de almacenamiento efímero
Límites (versión 1.29.1-gke.1670000 de GKE y posteriores):
- CPU ilimitada
- Memoria ilimitada
- Almacenamiento efímero ilimitado
Límites (antes de la versión 1.29.1-gke.1670000 de GKE):
- CPU de 250 m
- 256 MiB de memoria
- 5 GiB de almacenamiento efímero
De forma predeterminada, el contenedor gke-gcsfuse-metadata-prefetch se configura con las siguientes solicitudes y límites de recursos para los clústeres Standard y Autopilot:
Solicitudes:
- CPU de 10 minutos
- 10 MiB de memoria
- 10 MiB de almacenamiento efímero
Límites:
- CPU de 50 m
- 250 MiB de memoria
- Almacenamiento efímero ilimitado
En los clústeres Standard y Autopilot, puedes sobrescribir los valores predeterminados. La forma en que GKE gestiona los recursos de los contenedores depende del modo de funcionamiento del clúster:
- Clústeres estándar: si se define una de las solicitudes o uno de los límites y no se define el otro, los límites y las solicitudes de recursos de los pods serán los mismos. Si se definen tanto las solicitudes como los límites, los pods usarán las solicitudes y los límites de recursos exactos que especifiques. Si no define ningún valor, se aplicarán directamente los recursos predeterminados (descritos anteriormente).
- Clústeres Autopilot: si se define una de las solicitudes o límites y no se define otra, los límites y las solicitudes de recursos de los pods se establecerán como iguales. Consulta Cómo definir límites de recursos en Autopilot para saber cómo afectan al comportamiento de los pods las anulaciones de recursos y los valores de recursos predeterminados definidos.
Para sobrescribir los valores predeterminados del contenedor gke-gcsfuse-sidecar, puede especificar la anotación gke-gcsfuse/[cpu-limit|memory-limit|ephemeral-storage-limit|cpu-request|memory-request|ephemeral-storage-request], como se muestra en el siguiente ejemplo:
Para sobrescribir los valores predeterminados del contenedor gke-gcsfuse-metadata-prefetch (a partir de la versión 1.32.3-gke.1717000 de GKE), puedes especificar 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 los límites o las solicitudes 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, si estableces estos límites en "0" en un clúster con la versión 1.32.3-gke.1717000 de GKE o una posterior, no se realizará ninguna operación.
Por ejemplo, si se define gke-gcsfuse/metadata-prefetch-memory-limit: "0", se indica que se quiere anular el límite de memoria del contenedor gke-gcsfuse-metadata-prefetch.
Esto resulta útil cuando no puedes decidir la cantidad de recursos que necesita la función de prefetrado de metadatos para tus cargas de trabajo y quieres que el prefetrado de metadatos consuma todos los recursos disponibles en un nodo.
Configurar la verbosidad del registro
De forma predeterminada, el contenedor gke-gcsfuse-sidecar genera registros en los niveles info y error.
Sin embargo, para depurar o hacer un análisis más detallado, es posible que tengas que ajustar el nivel de detalle del registro. En esta sección se explica cómo aumentar o reducir el nivel de registro.
Puede usar opciones de montaje para configurar el nivel de detalle de los registros o usar la capacidad del controlador CSI para traducir los valores del atributo de volumen en los ajustes de configuración de gcsfuse necesarios.
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 montaje, incluye la siguiente configuración en el manifiesto del pod de destino:
mountOptions: "logging:severity:LOGGING_SEVERITY"
Haz los cambios siguientes:
BUCKET_NAME: el nombre de tu segmento de Cloud Storage.LOGGING_SEVERITY: uno de los siguientes valores, en función de tus requisitos:tracedebuginfowarningerror
Una vez que se ha implementado el pod, el controlador CSI inicia gcsfuse con el nivel de registro recién configurado.
Puedes usar el siguiente filtro para verificar si se ha aplicado la gravedad del registro:
resource.labels.container_name="gke-gcsfuse-sidecar"
resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
"severity:"
Solucionar problemas
Para obtener más información sobre cómo solucionar problemas con el controlador CSI de Cloud Storage FUSE, consulta la guía de solución de problemas en la documentación del proyecto de GitHub.
Siguientes pasos
- Consulta cómo optimizar el rendimiento del controlador CSI de Cloud Storage FUSE.
- Consulta más ejemplos de uso del controlador CSI en GitHub.
- Consulta más información sobre Cloud Storage FUSE.