Partager via

Créer et utiliser un volume avec Stockage Blob Azure dans Azure Kubernetes Service (AKS)

  • Article

Les applications basées sur des conteneurs doivent souvent consulter et conserver des données dans un volume de données externe. Si plusieurs pods ont besoin d’un accès simultané au même volume de stockage, vous pouvez utiliser le Stockage Blob Azure pour vous connecter à l’aide de blobfuse ou du système de fichiers réseau (NFS).

Cet article vous montre comment :

  • Utilisez un volume persistant dynamique en installant le pilote CSI (Container Storage Interface) et en créant dynamiquement un conteneur de stockage Blob Azure à attacher à un pod.
  • Utilisez un volume persistant statique en créant un conteneur de stockage Blob Azure, ou bien utilisez un conteneur existant et attachez-le à un pod.

Pour plus d’informations sur les volumes Kubernetes, consultez Options de stockage pour les applications dans AKS.

Avant de commencer

  • Activez le pilote CSI de Stockage Blob sur votre cluster AKS.

  • Pour prendre en charge un compte de stockage Azure DataLake Gen2 lors de l’utilisation du montage blobfuse, vous devez effectuer les opérations suivantes :

    • Pour créer un compte ADLS en tirant parti du pilote dans un approvisionnement dynamique, spécifiez isHnsEnabled: "true" dans les paramètres de classe de stockage.
    • Pour activer un accès blobfuse sur un compte ADLS dans un approvisionnement statique, spécifiez l’option de montage --use-adls=true dans le volume persistant.
    • Si vous allez activer un compte de stockage avec un espace de noms hiérarchique, les volumes persistants existants doivent être remontés avec l’option de montage --use-adls=true .

  • À propos du cache blobfuse

    • Par défaut, le cache blobfuse se trouve dans le répertoire /mnt. Si la référence SKU de machine virtuelle fournit un disque temporaire, le répertoire /mnt est monté sur le disque temporaire. Toutefois, si la référence SKU de machine virtuelle ne fournit pas de disque temporaire, le répertoire /mnt est monté sur le disque du système d’exploitation, vous pouvez définir l’option de montage --tmp-path= pour spécifier un autre répertoire de cache

Provisionner un volume de manière dynamique

Cette section fournit des conseils aux administrateurs de clusters qui veulent provisionner un ou plusieurs volumes persistants qui incluent des détails sur le stockage Blob utilisé par une charge de travail. Une revendication de volume persistant utilise l’objet de classe de stockage pour provisionner dynamiquement un conteneur de stockage Blob Azure.

Paramètres de classe de stockage pour les volumes persistants dynamiques

Le tableau suivant contient des paramètres que vous pouvez utiliser pour définir une classe de stockage personnalisée pour votre revendication de volume persistant.

Nom Description Exemple Obligatoire Valeur par défaut
skuName Spécifiez un type de compte de stockage de Azure (alias : storageAccountType). Standard_LRS, Premium_LRS, Standard_GRS, Standard_RAGRS Non Standard_LRS
location Spécifiez un emplacement Azure. eastus No Si le paramètre est vide, le pilote utilise le même nom d’emplacement que le cluster actuel.
resourceGroup Spécifiez un nom groupe de ressources Azure. myResourceGroup No Si le paramètre est vide, le pilote utilise le même nom de groupe de ressources que le cluster actuel.
storageAccount Spécifiez un type de compte de stockage de Azure. storageAccountName Aucune Lorsque aucun nom de compte de stockage spécifique n’est fourni, le pilote recherche un compte de stockage approprié qui correspond aux paramètres du compte au sein du même groupe de ressources. S’il ne trouve pas de compte de stockage correspondant, il en crée un nouveau. Toutefois, si un nom de compte de stockage est spécifié, le compte de stockage doit déjà exister.
networkEndpointType Spécifiez le type de point de terminaison réseau pour le compte de stockage créé par le pilote. Si privateEndpoint est spécifié, un point de terminaison privé est créé pour le compte de stockage. Dans d’autres cas, un point de terminaison de service est créé pour le protocole NFS.1 privateEndpoint Non Pour un cluster AKS, ajoutez le nom du cluster AKS au rôle de contributeur dans le groupe de ressources hébergeant le réseau virtuel.
protocol Spécifiez le montage blobfuse ou le montage NFSv3. fuse, nfs Non fuse
containerName Spécifiez le nom du conteneur (répertoire) existant. conteneur No S’il est vide, le pilote crée un nom de conteneur, en commençant par pvc-fuse blobfuse ou pvc-nfs pour NFS v3.
containerNamePrefix Spécifiez le préfixe du répertoire de stockage Azure créé par le pilote. my Ne peut contenir que des lettres minuscules, des chiffres, des traits d’union et une longueur inférieure à 21 caractères. Non
server Spécifiez le nom de domaine du compte de stockage Azure. Nom de domaine DNS du compte de stockage existant, par exemple <storage-account>.privatelink.blob.core.windows.net. No S’il est vide, le pilote utilise par défaut <storage-account>.blob.core.windows.net ou un autre nom de domaine DNS du compte de stockage cloud souverain.
allowBlobPublicAccess Autoriser ou interdire l’accès public à tous les objets blob ou conteneurs pour le compte de stockage créé par le pilote. true,false Non false
storageEndpointSuffix Spécifiez le suffixe de point de terminaison de stockage Azure. core.windows.net No S’il est vide, le pilote utilise le suffixe de point de terminaison de stockage par défaut en fonction de l’environnement cloud.
tags Des étiquettes sont créées dans un nouveau compte de stockage. Format de balise : « foo=aaa,bar=bbb » Non ""
matchTags Correspondance des balises lorsque le pilote tente de trouver un compte de stockage approprié. true,false Non false
--- Les paramètres suivants sont uniquement pour blobfuse --- --- ---
subscriptionID Spécifiez l’ID d’abonnement Azure dans lequel le répertoire de stockage d’objets blob sera créé. ID d’abonnement Azure Non Si le paramètre n’est pas vide, resourceGroup doit être fourni.
storeAccountKey Spécifiez la clé de compte de magasin sur le secret Kubernetes.

Remarque :
false signifie que le pilote utilise l’identité kubelet pour obtenir la clé de compte.		 true,false Non true
secretName Spécifiez le nom du secret pour stocker la clé de compte. No
secretNamespace Spécifiez l’espace de noms de secret pour stocker la clé de compte. default,kube-system, etc. No Espace de noms de contenu de volume persistant
isHnsEnabled Activez Hierarchical namespace pour le compte Azure Data Lake Storage. true,false Non false
--- Les paramètres suivants sont uniquement pour le protocole NFS --- --- ---
mountPermissions Spécifiez les autorisations de dossier montés. Par défaut, il s’agit de 0777. Si la valeur est définie à 0, le pilote n’exécute pas chmod après le montage. 0777 Non

1 Si le compte de stockage est créé par le pilote, vous devez uniquement spécifier le paramètre networkEndpointType: privateEndpoint dans la classe de stockage. Le pilote CSI crée le point de terminaison privé avec le compte. Si vous apportez votre propre compte de stockage, vous devez créer le point de terminaison privé pour le compte de stockage.

Créer une revendication de volume persistant à l’aide de la classe de stockage intégrée

Une revendication de volume persistant utilise l’objet de classe de stockage pour provisionner dynamiquement un conteneur de stockage Blob Azure. Le code YAML suivant permet de créer une revendication de volume persistant d’une taille de 5 Go avec un accès ReadWriteMany, en utilisant la classe de stockage prédéfinie. Pour plus d’informations sur les modes d’accès, consultez la documentation Kubernetes sur les volumes persistants.

  1. Créez un fichier nommé blob-nfs-pvc.yaml et copiez-y le YAML suivant.

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-blob-storage
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: azureblob-nfs-premium
  resources:
    requests:
      storage: 5Gi

  2. Créez la revendication de volume persistant avec la commande kubectl create :

    kubectl create -f blob-nfs-pvc.yaml

Une fois terminé, le conteneur de stockage d’objets blob est créé. Vous pouvez utiliser la commande kubectl get pour voir l’état de la revendication de volume persistant :

kubectl get pvc azure-blob-storage

La sortie de la commande ressemble à l’exemple suivant :

NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                AGE
azure-blob-storage   Bound    pvc-b88e36c5-c518-4d38-a5ee-337a7dda0a68   5Gi        RWX            azureblob-nfs-premium       92m

Utiliser la revendication de volume persistant

Le code YAML ci-après crée un pod qui utilise la revendication de volume persistant azure-blob-storage pour monter le Stockage Blob Azure dans le chemin « /mnt/azure ».

  1. Créez un fichier nommé blob-nfs-pv et copiez-y le code YAML suivant. Vérifiez que claimName correspond à la revendication de volume persistant créée à l’étape précédente.

    kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.17.3-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi
    volumeMounts:
    - mountPath: "/mnt/blob"
      name: volume
      readOnly: false
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-blob-storage

  2. Créez le pod avec la commande kubectl apply :

    kubectl apply -f blob-nfs-pv.yaml

  3. Une fois le pod en cours d’exécution, exécutez la commande suivante pour créer un fichier nommé test.txt.

    kubectl exec mypod -- touch /mnt/blob/test.txt

  4. Pour contrôler que le disque est correctement monté, exécutez la commande suivante et vérifiez la présence du fichier test.txt dans la sortie :

    kubectl exec mypod -- ls /mnt/blob

    La sortie de la commande ressemble à l’exemple suivant :

    test.txt

Créer une classe de stockage personnalisée

Les classes de stockage par défaut sont adaptées aux scénarios les plus courants, mais pas à tous. Dans certains cas, vous souhaiterez probablement personnaliser votre propre classe de stockage avec vos propres paramètres. Dans cette section, nous fournissons deux exemples. Le premier utilise le protocole NFS, tandis que le second utilise blobfuse.

Classe de stockage à l’aide du protocole NFS

Dans cet exemple, le manifeste suivant configure le montage d’un conteneur de stockage Blob à l’aide du protocole NFS. Utilisez-le pour ajouter le paramètre étiquettes .

  1. Créez un fichier nommé blob-nfs-sc.yaml et copiez-y l’exemple de manifeste suivant :

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azureblob-nfs-premium
provisioner: blob.csi.azure.com
parameters:
  protocol: nfs
  tags: environment=Development
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - nconnect=4

  2. Créez la classe de stockage avec la commande kubectl apply :

    kubectl apply -f blob-nfs-sc.yaml

    La sortie de la commande ressemble à l’exemple suivant :

    storageclass.storage.k8s.io/blob-nfs-premium created

Classe de stockage à l’aide de blobfuse

Dans cet exemple, le manifeste suivant configure l’utilisation de blobfuse et monte un conteneur de stockage Blob. Utilisez-le pour mettre à jour le paramètre skuName.

  1. Créez un fichier nommé blobfuse-sc.yaml et copiez-y l’exemple de manifeste suivant :

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azureblob-fuse-premium
provisioner: blob.csi.azure.com
parameters:
  skuName: Standard_GRS  # available values: Standard_LRS, Premium_LRS, Standard_GRS, Standard_RAGRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - -o allow_other
  - --file-cache-timeout-in-seconds=120
  - --use-attr-cache=true
  - --cancel-list-on-mount-seconds=10  # prevent billing charges on mounting
  - -o attr_timeout=120
  - -o entry_timeout=120
  - -o negative_timeout=120
  - --log-level=LOG_WARNING  # LOG_WARNING, LOG_INFO, LOG_DEBUG
  - --cache-size-mb=1000  # Default will be 80% of available memory, eviction will happen beyond that.

  2. Créez la classe de stockage avec la commande kubectl apply :

    kubectl apply -f blobfuse-sc.yaml

    La sortie de la commande ressemble à l’exemple suivant :

    storageclass.storage.k8s.io/blob-fuse-premium created

Provisionner un volume de manière statique

Cette section fournit des conseils aux administrateurs de clusters qui veulent créer un ou plusieurs volumes persistants qui incluent des détails sur le stockage Blob utilisé par une charge de travail.

Paramètres d’approvisionnement statique pour les volumes persistants

Le tableau suivant contient des paramètres à utiliser pour définir un volume persistant.

Nom Description Exemple Obligatoire Valeur par défaut
volumeHandle Spécifiez une valeur que le pilote peut utiliser pour identifier de manière unique le conteneur d’objets blob de stockage dans le cluster. Une méthode recommandée pour produire une valeur unique consiste à combiner le nom du compte de stockage global unique et le nom du conteneur : {account-name}_{container-name}.
Remarque : les caractères # et / sont réservés à un usage interne. Ils ne peuvent pas être utilisés dans un descripteur de volume.		 Oui
volumeAttributes.resourceGroup Spécifiez un nom groupe de ressources Azure. myResourceGroup No Si le paramètre est vide, le pilote utilise le même nom de groupe de ressources que le cluster actuel.
volumeAttributes.storageAccount Spécifiez un nom de compte de stockage Azure existant. storageAccountName Yes
volumeAttributes.containerName Spécifiez un nom de conteneur existant. conteneur Oui
volumeAttributes.protocol Spécifiez le montage blobfuse ou le montage NFS v3. fuse, nfs Non fuse
--- Les paramètres suivants sont uniquement pour blobfuse --- --- ---
volumeAttributes.secretName Nom du secret qui stocke le nom et la clé du compte de stockage (s’applique uniquement à SMB). No
volumeAttributes.secretNamespace Spécifiez l’espace de noms du secret pour stocker la clé de compte. default No Espace de noms de contenu de volume persistant
nodeStageSecretRef.name Spécifiez le nom du secret qui stocke l’un des éléments suivants :
azurestorageaccountkey
azurestorageaccountsastoken
msisecret
azurestoragespnclientsecret.		 Non Nom de secret Kubernetes existant
nodeStageSecretRef.namespace Spécifiez l’espace de noms du secret. Espace de noms Kubernetes Yes
--- Les paramètres suivants sont uniquement pour le protocole NFS --- --- ---
volumeAttributes.mountPermissions Spécifiez les autorisations de dossiers montés. 0777 No
--- Les paramètres suivants sont uniquement pour le paramètre de réseau virtuel NFS --- --- ---
vnetResourceGroup Spécifiez le groupe de ressources de réseau virtuel hébergeant le réseau virtuel. myResourceGroup No Si le paramètre est vide, le pilote utilise la valeur vnetResourceGroup spécifiée dans le fichier config du cloud Azure.
vnetName Spécifiez le nom du réseau virtuel. aksVNet No Si le paramètre est vide, le pilote utilise la valeur vnetName spécifiée dans le fichier config du cloud Azure.
subnetName Spécifiez le nom de sous-réseau existant du nœud de l’agent. aksSubnet No S’il est vide, le pilote utilise la valeur subnetName dans le fichier config du cloud Azure.
--- Les paramètres suivants sont uniquement pour la fonctionnalité : blobfuse
Authentification de l’identité managée et du principal de service		 --- --- ---
volumeAttributes.AzureStorageAuthType Spécifiez le type d’authentification. Key, SAS, MSI, SPN No Key
volumeAttributes.AzureStorageIdentityClientID Spécifiez l’ID client d’identité. Non
volumeAttributes.AzureStorageIdentityResourceID Spécifiez l’ID de ressource d’identité. No
volumeAttributes.MSIEndpoint Spécifiez le point de terminaison MSI. No
volumeAttributes.AzureStorageSPNClientID Spécifiez l’ID client du nom du principal du service (SPN) Azure. No
volumeAttributes.AzureStorageSPNTenantID Spécifiez l’ID de locataire SPN Azure. No
volumeAttributes.AzureStorageAADEndpoint Spécifier le point de terminaison Microsoft Entra. Non
--- Les paramètres suivants sont uniquement destinés à la fonctionnalité : clé de compte de lecture blobfuse ou jeton SAP à partir du coffre de clés --- --- ---
volumeAttributes.keyVaultURL Spécifiez le nom DNS d’Azure Key Vault. {vault-name}.vault.azure.net No
volumeAttributes.keyVaultSecretName Spécifiez le nom du secret Azure Key Vault. Nom de secret Azure Key Vault existant. No
volumeAttributes.keyVaultSecretVersion Version du secret Azure Key Vault. Version existante No Si ce paramètre est vide, le pilote utilise la version actuelle.

Création d'un conteneur d'objets blob

Lorsque vous créez une ressource Stockage Blob Azure pour une utilisation avec AKS, vous pouvez créer la ressource dans le groupe de ressources des nœuds. Cette approche permet au cluster AKS d’accéder et de gérer la ressource Stockage Blob.

Pour cet article, créez le conteneur dans le groupe de ressources de nœuds. Tout d’abord, obtenez le nom du groupe de ressources avec la commande az aks show et ajoutez le paramètre de requête --query nodeResourceGroup. L’exemple suivant obtient le groupe de ressources de nœud pour le cluster AKS nommé myAKSCluster dans le groupe de ressources nommé myResourceGroup :

az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv

La sortie de la commande ressemble à l’exemple suivant :

MC_myResourceGroup_myAKSCluster_eastus

Ensuite, créez un conteneur pour stocker des objets blob en suivant les étapes décrites dans Gérer le stockage blob pour autoriser l’accès, puis créez le conteneur.

Monter le volume

Dans cette section, vous montez le volume persistant à l’aide du protocole NFS ou de Blobfuse.

Le montage du stockage blob à l’aide du protocole NFS v3 ne s’authentifie pas à l’aide d’une clé de compte. Votre cluster AKS doit résider dans le même réseau virtuel que le nœud d’agent ou un réseau virtuel qui y est appairé. La seule façon de sécuriser les données de votre compte de stockage consiste à utiliser un réseau virtuel et d’autres paramètres de sécurité réseau. Pour plus d’informations sur la configuration de l’accès NFS à votre compte de stockage, consultez Monter le stockage blob à l’aide du protocole NFS (Network File System) 3.0.

L’exemple suivant montre comment monter un conteneur de stockage blob en tant que volume persistant à l’aide du protocole NFS.

  1. Créez un fichier nommé pv-blob-nfs.yaml et copiez-y le YAML suivant. Sous storageClass, mettez à jour resourceGroup, storageAccountet containerName.

    Notes

    La valeur volumeHandle doit être un ID de volume unique pour chaque conteneur d’objets blob de stockage identique dans le cluster. Les caractères # et / sont réservés à un usage interne et ne peuvent pas être utilisés.

    apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: blob.csi.azure.com
  name: pv-blob
spec:
  capacity:
    storage: 1Pi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain  # If set as "Delete" container would be removed after pvc deletion
  storageClassName: azureblob-nfs-premium
  mountOptions:
    - nconnect=4
  csi:
    driver: blob.csi.azure.com
    # make sure volumeid is unique for every identical storage blob container in the cluster
    # character `#` and `/` are reserved for internal use and cannot be used in volumehandle
    volumeHandle: account-name_container-name
    volumeAttributes:
      resourceGroup: resourceGroupName
      storageAccount: storageAccountName
      containerName: containerName
      protocol: nfs

    Remarque

    Bien que l’attribut API Kubernetes capacity soit obligatoire, cette valeur n’est pas utilisée par le pilote CSI du stockage Blob Azure, car vous pouvez écrire des données de manière flexible jusqu’à ce que vous atteigniez la limite de capacité de votre compte de stockage. La valeur de l’attribut capacity est utilisée uniquement pour la correspondance de la taille entre PersistentVolumes et PersistentVolumeClaims. Nous vous recommandons d’utiliser une valeur élevée fictive. Le pod voit un volume monté avec une taille fictive de 5 pétaoctets.

  2. Exécutez la commande suivante pour créer le volume persistant à l’aide de la commande kubectl create faisant référence au fichier YAML créé précédemment :

    kubectl create -f pv-blob-nfs.yaml

  3. Créez un fichier pvc-blob-nfs.yaml avec un PersistentVolumeClaim. Par exemple :

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-blob
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  volumeName: pv-blob
  storageClassName: azureblob-nfs-premium

  4. Exécutez la commande suivante pour créer la revendication de volume persistant à l’aide de la commande kubectl create faisant référence au fichier YAML créé précédemment :

    kubectl create -f pvc-blob-nfs.yaml

Utiliser le volume persistant

Le code YAML ci-après crée un pod qui utilise le volume persistent ou la revendication de volume persistant nommée pvc-blob créée plus tôt pour monter le stockage Blob Azure dans le chemin /mnt/blob.

  1. Créez un fichier nommé nginx-pod-blob.yaml et copiez-y le code YAML suivant. Assurez-vous que le champ claimName correspond au PVC créé à l’étape précédente lors de la création d’un volume persistant pour NFS ou Blobfuse.

    kind: Pod
apiVersion: v1
metadata:
  name: nginx-blob
spec:
  nodeSelector:
    "kubernetes.io/os": linux
  containers:
    - image: mcr.microsoft.com/oss/nginx/nginx:1.17.3-alpine
      name: nginx-blob
      volumeMounts:
        - name: blob01
          mountPath: "/mnt/blob"
          readOnly: false
  volumes:
    - name: blob01
      persistentVolumeClaim:
        claimName: pvc-blob

  2. Exécutez la commande suivante pour créer le pod et monter la revendication de volume persistant à l’aide de la commande kubectl create faisant référence au fichier YAML créé précédemment :

    kubectl create -f nginx-pod-blob.yaml

  3. Exécutez la commande suivante pour créer une session d’interpréteur de commandes interactive avec le pod afin de vérifier le stockage Blob monté :

    kubectl exec -it nginx-blob -- df -h

    La sortie de la commande ressemble à l’exemple suivant :

    Filesystem      Size  Used Avail Use% Mounted on
...
blobfuse         14G   41M   13G   1% /mnt/blob
...

Étapes suivantes