Configurer le conteneur side-car du pilote CSI Cloud Storage FUSE pour GKE

Ce guide vous explique comment configurer des ressources pour le conteneur side-car du pilote CSI Cloud Storage FUSE, y compris la configuration d'une image privée, d'une mémoire tampon d'écriture personnalisée et d'un volume de cache en lecture personnalisé. En règle générale, il n'est pas nécessaire de modifier ces paramètres.

Le pilote CSI Cloud Storage FUSE utilise un conteneur side-car personnalisable pour installer et accéder efficacement aux buckets Cloud Storage. En configurant le side-car, vous pouvez affiner les performances de l'application et l'utilisation des ressources, ce qui peut entraîner un accès plus rapide aux données, des temps de traitement plus rapides et potentiellement une consommation globale de ressources plus faible pour votre application.

Ce guide s'adresse aux développeurs, aux administrateurs et aux architectes qui souhaitent optimiser les performances, la sécurité et l'efficacité de leurs applications interagissant avec GKE.

Avant de lire cette page, assurez-vous de connaître les bases de Cloud Storage, de Kubernetes et des concepts de conteneurisation.

Fonctionnement du conteneur side-car

Le pilote CSI Cloud Storage FUSE utilise un conteneur side-car pour installer des buckets Cloud Storage et les rendre accessibles en tant que systèmes de fichiers locaux aux applications Kubernetes. Ce conteneur side-car, nommé gke-gcsfuse-sidecar, s'exécute parallèlement au conteneur de charge de travail dans le même pod. Lorsque le pilote détecte l'annotation gke-gcsfuse/volumes: "true" dans une spécification de pod, il injecte automatiquement le conteneur side-car. Cette approche de conteneur side-car permet d'assurer la sécurité et de gérer efficacement les ressources.

Le conteneur side-car gère la complexité du montage des buckets Cloud Storage et fournit un accès au système de fichiers aux applications sans que vous ayez à gérer directement l'exécution de Cloud Storage FUSE. Vous pouvez configurer des limites de ressources pour le conteneur side-car à l'aide d'annotations telles que gke-gcsfuse/cpu-limit et gke-gcsfuse/memory-limit. Le modèle de conteneur side-car garantit également que l'instance Cloud Storage FUSE est liée au cycle de vie de la charge de travail, ce qui l'empêche de consommer des ressources inutilement. Cela signifie que le conteneur side-car s'arrête automatiquement lorsque les conteneurs de charge de travail se ferment, en particulier dans les charges de travail Job ou les pods avec un RestartPolicy de Never.

Compatibilité avec Istio

Le conteneur side-car du pilote CSI Cloud Storage FUSE et Istio peuvent coexister et s'exécuter simultanément dans votre pod. Le proxy side-car d'Istio gère le trafic réseau, tandis que le side-car CSI optimise l'accès au stockage, ce qui permet à vos applications d'interagir efficacement avec Google Cloud Storage, avec des performances et une observabilité améliorées.

Configurer une mémoire tampon d'écriture personnalisée

Cloud Storage FUSE préproduit les écritures dans un répertoire local, puis les importe dans Cloud Storage lors des opérations close ou fsync.

Cette section explique comment configurer un volume de mémoire tampon personnalisé pour la mise en mémoire tampon d'écriture de Cloud Storage FUSE. Ce scénario peut s'appliquer si vous devez remplacer le volume par défaut emptyDir pour Cloud Storage FUSE afin de préparer les fichiers dans les opérations d'écriture. C'est utile si vous devez écrire des fichiers de plus de 10 Gio sur des clusters Autopilot.

Vous pouvez spécifier n'importe quel type de stockage compatible avec le pilote CSI Cloud Storage FUSE pour la mise en cache des fichiers, comme un SSD local, un stockage basé sur un disque persistant et un disque RAM (mémoire). GKE utilisera le volume spécifié pour la mise en mémoire tampon d'écriture des fichiers. Pour en savoir plus sur ces options, consultez Sélectionner le stockage pour la sauvegarde de votre cache de fichiers.

Pour utiliser le volume de tampon personnalisé, vous devez spécifier une valeur fsGroup non nulle.

L'exemple suivant montre comment utiliser un PersistentVolumeClaim prédéfini comme volume de mémoire tampon :

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

Remplacez les éléments suivants :

  • FS_GROUP : ID fsGroup.
  • BUFFER_VOLUME_PVC : nom de la PVC prédéfinie.

Configurer un volume de cache de lecture personnalisé

Cette section explique comment configurer un volume de cache personnalisé pour la mise en cache en lecture de Cloud Storage FUSE.

Ce scénario peut s'appliquer si vous devez remplacer le volume emptyDir par défaut pour Cloud Storage FUSE afin de mettre en cache les fichiers dans les opérations de lecture. Vous pouvez spécifier n'importe quel type de stockage compatible avec GKE, tel qu'une PersistentVolumeClaim. GKE utilisera le volume spécifié pour la mise en cache des fichiers. C'est utile si vous devez mettre en cache des fichiers de plus de 10 Gio sur des clusters Autopilot. Pour utiliser le volume de cache personnalisé, vous devez spécifier une valeur fsGroup non nulle.

L'exemple suivant montre comment utiliser une PersistentVolumeClaim prédéfinie comme 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

Remplacez les éléments suivants :

  • FS_GROUP : ID fsGroup.
  • CACHE_VOLUME_PVC : nom de la PersistentVolumeClaim prédéfinie.

Configurer une image privée pour le conteneur side-car

Cette section explique comment utiliser l'image de conteneur side-car si vous l'hébergez dans un registre de conteneurs privés. Ce scénario peut s'appliquer si vous devez utiliser des nœuds privés pour des raisons de sécurité.

Procédez comme suit pour configurer et utiliser l'image de conteneur side-car privé :

  1. Consultez ce tableau de compatibilité GKE pour trouver une image de conteneur side-car public compatible.
  2. Extrayez-la dans votre environnement local et transférez-la vers votre registre de conteneurs privés.

  3. Dans le fichier manifeste, spécifiez un conteneur nommé gke-gcsfuse-sidecar ne comportant que le champ d'image. GKE utilise l'image de conteneur side-car spécifiée pour préparer l'injection de conteneur side-car.

    Voici un exemple :

    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.

    Remplacez les éléments suivants :

    • PRIVATE_REGISTRY : votre registre de conteneurs privés.
    • PRIVATE_IMAGE_TAG : tag de l'image de votre conteneur side-car privé.

Configurer les ressources du conteneur side-car

Par défaut, le conteneur gke-gcsfuse-sidecar est configuré avec les demandes et limites de ressources suivantes pour les clusters Standard et Autopilot :

Demandes :

  • 250 mCPU
  • 256 Mio de mémoire
  • 5 Gio d'espace de stockage éphémère

Limites (GKE version 1.29.1-gke.1670000 et versions ultérieures) :

  • Processeur illimité
  • mémoire illimitée
  • un espace de stockage éphémère illimité.

Limites (avant la version 1.29.1-gke.1670000 de GKE) :

  • 250 mCPU
  • 256 Mio de mémoire
  • 5 Gio d'espace de stockage éphémère

Par défaut, le conteneur gke-gcsfuse-metadata-prefetch est configuré avec les demandes et limites de ressources suivantes pour les clusters Standard et Autopilot :

Demandes :

  • 10 mCPU
  • 10 Mio de mémoire
  • 10 Mio de stockage éphémère

Limites :

  • 50 mCPU
  • 250 Mio de mémoire
  • un espace de stockage éphémère illimité.

Dans les clusters Standard et Autopilot, vous pouvez remplacer les valeurs par défaut. La façon dont GKE gère les ressources de conteneur dépend du mode de fonctionnement de votre cluster :

  • Clusters standards : si l'une des valeurs de demande ou de limite est définie et qu'une autre ne l'est pas, les limites et les demandes de ressources des pods seront définies sur la même valeur. Si les demandes et les limites sont définies, les pods utilisent exactement les demandes et les limites de ressources que vous spécifiez. Si vous ne définissez aucune valeur, les ressources par défaut (décrites ci-dessus) sont appliquées directement.
  • Clusters Autopilot : si l'une des demandes ou limites est définie et qu'une autre ne l'est pas, les demandes et limites de ressources des pods seront définies comme identiques. Consultez Définir des limites de ressources dans Autopilot pour comprendre comment les remplacements de ressources et les valeurs de ressources par défaut définies affectent le comportement des pods.

Pour écraser les valeurs par défaut du conteneur gke-gcsfuse-sidecar, vous pouvez éventuellement spécifier l'annotation gke-gcsfuse/[cpu-limit|memory-limit|ephemeral-storage-limit|cpu-request|memory-request|ephemeral-storage-request] comme illustré dans l'exemple suivant :

Pour remplacer les valeurs par défaut du conteneur gke-gcsfuse-metadata-prefetch (à partir de la version 1.32.3-gke.1717000 de GKE), vous pouvez éventuellement spécifier l'annotation 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] comme illustré dans l'exemple suivant :

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

Vous pouvez utiliser la valeur "0" pour supprimer les limites ou les requêtes de ressources. Toutefois, notez que le conteneur gke-gcsfuse-sidecar n'a déjà aucune limite (cpu-limit, memory-limit et ephemeral-storage-limit), et que le conteneur gke-gcsfuse-metadata-prefetch n'a déjà aucune limite ephemeral-storage-limit. Par conséquent, définir ces limites sur "0" sur un cluster avec la version 1.32.3-gke.1717000 de GKE ou une version ultérieure n'aurait aucun effet.

Par exemple, définir gke-gcsfuse/metadata-prefetch-memory-limit: "0" indique que vous souhaitez que la limite de mémoire du conteneur gke-gcsfuse-metadata-prefetch ne soit pas définie. Cela s'avère utile lorsque vous ne pouvez pas déterminer la quantité de ressources dont la fonctionnalité de préchargement des métadonnées a besoin pour vos charges de travail et que vous souhaitez laisser le préchargement des métadonnées utiliser toutes les ressources disponibles sur un nœud.

Configurer la verbosité de la journalisation

Par défaut, le conteneur gke-gcsfuse-sidecar génère des journaux aux niveaux info et error. Toutefois, pour le débogage ou une analyse plus détaillée, vous devrez peut-être ajuster le niveau de détail de la journalisation. Cette section explique comment augmenter ou diminuer le niveau de journalisation.

Vous pouvez utiliser des options de montage pour configurer le niveau de détail de la journalisation ou utiliser la capacité du pilote CSI à traduire les valeurs des attributs de volume en paramètres de configuration gcsfuse nécessaires.

Dans le fichier manifeste du pod cible, incluez les configurations suivantes :

      volumeAttributes:
        bucketName: BUCKET_NAME
        mountOptions: "implicit-dirs"
        gcsfuseLoggingSeverity:  LOGGING_SEVERITY

Pour utiliser les options de montage, incluez la configuration suivante dans le fichier manifeste du pod cible :

  mountOptions: "logging:severity:LOGGING_SEVERITY"

Remplacez les éléments suivants :

  • BUCKET_NAME : nom de votre bucket Cloud Storage.
  • LOGGING_SEVERITY : l'une des valeurs suivantes, en fonction de vos besoins :
    • trace
    • debug
    • info
    • warning
    • error

Une fois le pod déployé, le pilote CSI lance gcsfuse avec le niveau de journalisation nouvellement configuré.

Vous pouvez utiliser le filtre suivant pour vérifier si le niveau de gravité de la journalisation est appliqué :

resource.labels.container_name="gke-gcsfuse-sidecar"
resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
"severity:"

Étapes suivantes