Container Service for Kubernetes:Monter des buckets OSS à l'aide de volumes dynamiques ossfs 1.0

1. Créer une StorageClass

1. Créez un Secret dans le même namespace que votre application.

   Remplacez akId et akSecret par votre AccessKey ID et votre AccessKey Secret.

   kubectl create secret generic oss-secret --from-literal='akId=<yourAccessKey ID>' --from-literal='akSecret=<yourAccessKey Secret>'

2. Créez la StorageClass.

   1. Créez un fichier nommé sc-oss.yaml.

      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: sc-oss
      parameters:
        # Replace with the name of your OSS bucket.
        bucket: bucket
        # The mount path relative to the bucket's root directory. You can specify a subdirectory.
        path: /
        # The endpoint of the region where the bucket is located.
        url: "http://oss-cn-hangzhou-internal.aliyuncs.com" 
        # The name of the Secret that stores the AccessKey information.
        csi.storage.k8s.io/node-publish-secret-name: oss-secret
        # The namespace where the Secret that stores the AccessKey information is located.
        csi.storage.k8s.io/node-publish-secret-namespace: default
        # Custom parameters.
        otherOpts: "-o umask=022 -o max_stat_cache_size=100000 -o allow_other"
      # Fixed value for the Alibaba Cloud OSS CSI plug-in.
      provisioner: ossplugin.csi.alibabacloud.com
      # The reclaim policy for the dynamically provisioned persistent volume.
      reclaimPolicy: Retain
      # The volume binding mode.
      volumeBindingMode: Immediate
      

      Paramètre	Description
      name	Nom de la StorageClass.
      bucket	Le bucket OSS à monter.
      path	La version du composant CSI doit être v1.14.8.32-c77e277b-aliyun ou ultérieure. Chemin de montage relatif au répertoire racine du bucket. La valeur par défaut est /, ce qui monte l'intégralité du bucket. Si la version d'ossfs est antérieure à 1,91, le path spécifié doit exister dans le bucket OSS. Pour plus d'informations, consultez Nouvelles fonctionnalités d'ossfs 1,91 et versions ultérieures.
      url
      csi.storage.k8s.io/node-publish-secret-name	Nom du Secret contenant les informations d'AccessKey.
      csi.storage.k8s.io/node-publish-secret-namespace	Namespace où se trouve le Secret contenant les informations d'AccessKey.
      otherOpts	Paramètres personnalisés pour le volume persistant OSS, au format -o -o . Par exemple : -o umask=022 -o max_stat_cache_size=100000 -o allow_other. Développer pour plus de détails umask : définit le masque de permissions pour les fichiers et répertoires. Par exemple, umask=022 change les permissions des fichiers à 755. Cela résout le problème de permissions pour les fichiers téléchargés via d'autres méthodes, telles que les SDK ou la console OSS, qui ont une permission par défaut de 640. Nous recommandons de configurer ce paramètre pour la séparation lecture/écriture ou l'accès multi-utilisateurs. max_stat_cache_size : définit la limite supérieure des entrées de cache de métadonnées, par exemple 100000. Les métadonnées sont mises en cache en mémoire pour améliorer les performances des opérations telles que ls et stat. Cependant, ce cache ne peut pas détecter immédiatement les modifications de fichiers effectuées via la console OSS, les SDK ou ossutil. Cela peut amener les applications à lire des données incohérentes. Si vous avez des exigences strictes en matière de cohérence des données, définissez ce paramètre sur 0 pour désactiver le cache, ou réduisez le temps d'expiration du cache à l'aide du paramètre stat_cache_expire. Cela peut toutefois réduire les performances de lecture. allow_other : permet aux utilisateurs autres que celui ayant monté le volume d'accéder aux fichiers et répertoires du chemin de montage. Cela convient aux environnements partagés multi-utilisateurs où des utilisateurs non-monteurs doivent également accéder aux données. Pour plus d'informations sur les paramètres optionnels, consultez Options de montage et Meilleures pratiques pour la configuration d'ossfs 1.0.
      provisioner	Type de pilote. Cette valeur est fixée à ossplugin.csi.alibabacloud.com lors de l'utilisation du plug-in CSI OSS d'Alibaba Cloud.
      reclaimPolicy	Politique de récupération pour les volumes persistants provisionnés dynamiquement. Les volumes persistants OSS prennent uniquement en charge Retain, ce qui signifie que lorsque vous supprimez un PVC, le volume persistant correspondant et les données dans le bucket OSS ne sont pas supprimés.
      volumeBindingMode	Mode de liaison du volume. Les volumes persistants OSS ne nécessitent pas d'affinité de nœud basée sur la zone de disponibilité. Vous pouvez utiliser la valeur par défaut Immediate.
      volumeAs	Mode d'accès au volume. La valeur par défaut est sharepath. Valeurs valides : sharepath : tous les volumes persistants partagent le même chemin de montage. Les données sont stockées à <bucket>:<path>/. subpath : crée un sous-répertoire dédié pour chaque volume persistant afin d'isoler les données. Les données sont stockées à <bucket>:<path>/<pv-name>/. Ce paramètre prend effet uniquement lorsque la version du composant CSI est 1.31.3 ou ultérieure.
      sigVersion	Version de signature pour les requêtes envoyées au serveur OSS. "v1" (par défaut) : utilise la Signature Version 1 d'OSS. "v4" (recommandé) : utilise la Signature Version 4 d'OSS.

   2. Créez la StorageClass.

      kubectl apply -f sc-oss.yaml

1. Stockez l'AccessKey de l'Étape 1 sous forme de Secret pour le volume persistant.

   1. Sur la page ACK Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Configurations > Secrets.

   2. Cliquez sur Create from YAML et suivez les instructions à l'écran pour créer le Secret.

      apiVersion: v1
      kind: Secret
      metadata:
        name: oss-secret
        # Must match the namespace of the application.
        namespace: default
      stringData:
        # Replace with your AccessKey ID.
        akId: <your AccessKey ID>
        # Replace with your AccessKey secret.
        akSecret: <your AccessKey Secret>

2. Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Volumes > StorageClasses.

3. Sur la page StorageClasses, cliquez sur Create, définissez PV Type sur OSS, puis suivez les instructions à l'écran pour configurer la StorageClass.

   Paramètre	Description
   Certificat d'accès	Secret utilisé pour accéder à OSS, contenant l'AccessKey ID et l'AccessKey Secret.
   Bucket ID:	Bucket OSS à utiliser. La console affiche uniquement les buckets accessibles avec l'AccessKey configuré.
   Chemin OSS	La version du composant CSI doit être v1.14.8.32-c77e277b-aliyun ou ultérieure. Chemin de montage relatif au répertoire racine du bucket. La valeur par défaut est /, ce qui monte l'intégralité du bucket. Si la version d'ossfs est antérieure à 1,91, le path spécifié doit exister dans le bucket OSS. Pour plus d'informations, consultez Nouvelles fonctionnalités d'ossfs 1,91 et versions ultérieures.
   Volume Mode	Mode d'accès au volume. La valeur par défaut est Shared Directory. Valeurs valides : Le mode Subdirectory prend effet uniquement lorsque la version du composant CSI est 1.31.3 ou ultérieure. Sinon, le mode Shared Directory est utilisé. Shared Directory (sharepath) : tous les volumes persistants partagent le même chemin de montage. Les données sont stockées à <bucket>:<path>/. Subdirectory (subpath) : crée un sous-répertoire dédié pour chaque volume persistant afin d'isoler les données. Les données sont stockées à <bucket>:<path>/<pv-name>/.
   Endpoint	Par défaut, la console utilise HTTP pour accéder à OSS via un réseau interne. Pour utiliser HTTPS, vous devez créer le PV à l'aide de kubectl.
   Politique de récupération	Politique de récupération pour les volumes persistants provisionnés dynamiquement. Les volumes persistants OSS prennent uniquement en charge Retain, ce qui signifie que lorsque vous supprimez un PVC, le volume persistant correspondant et les données dans le bucket OSS ne sont pas supprimés.
   Optional Parameters:	Paramètres personnalisés pour le volume persistant OSS, au format -o -o . Par exemple : -o umask=022 -o max_stat_cache_size=100000 -o allow_other. Développer pour plus de détails umask : définit le masque de permissions pour les fichiers et répertoires. Par exemple, umask=022 change les permissions des fichiers à 755. Cela résout le problème de permissions pour les fichiers téléchargés via d'autres méthodes, telles que les SDK ou la console OSS, qui ont une permission par défaut de 640. Nous recommandons de configurer ce paramètre pour la séparation lecture/écriture ou l'accès multi-utilisateurs. max_stat_cache_size : définit la limite supérieure des entrées de cache de métadonnées, par exemple 100000. Les métadonnées sont mises en cache en mémoire pour améliorer les performances des opérations telles que ls et stat. Cependant, ce cache ne peut pas détecter immédiatement les modifications de fichiers effectuées via la console OSS, les SDK ou ossutil. Cela peut amener les applications à lire des données incohérentes. Si vous avez des exigences strictes en matière de cohérence des données, définissez ce paramètre sur 0 pour désactiver le cache, ou réduisez le temps d'expiration du cache à l'aide du paramètre stat_cache_expire. Cela peut toutefois réduire les performances de lecture. allow_other : permet aux utilisateurs autres que celui ayant monté le volume d'accéder aux fichiers et répertoires du chemin de montage. Cela convient aux environnements partagés multi-utilisateurs où des utilisateurs non-monteurs doivent également accéder aux données. Pour plus d'informations sur les paramètres optionnels, consultez Options de montage et Meilleures pratiques pour la configuration d'ossfs 1.0.