Permanente volumes (V's) maken en beheren met Azure Blob Storage in Azure Kubernetes Service (AKS)

Als meerdere pods gelijktijdige toegang tot hetzelfde opslagvolume nodig hebben, kunt u Azure Blob Storage gebruiken om verbinding te maken via blobfuse of Network File System (NFS).

In dit artikel leest u hoe u dynamisch en statisch Azure Blob Storage-containers kunt maken voor gebruik door meerdere pods in een AKS-cluster (Azure Kubernetes Service).

Vereiste voorwaarden

• Het CSI-stuurprogramma voor Azure Blob Storage ingeschakeld op uw AKS-cluster.

• Een opslagaccount waarvoor NFS v3 is ingeschakeld, zodat u een permanent volume kunt koppelen met behulp van het NFS-protocol. U kunt NFS v3 niet inschakelen voor een bestaand opslagaccount. Zie Een NFS v3-account maken voor meer informatie.

• Voer de volgende taken uit om een Azure Data Lake Storage-account te ondersteunen bij het gebruik van blobfuse-koppeling:

  • Als u een Data Lake Storage-account wilt maken met behulp van het stuurprogramma voor dynamische inrichting, geeft u isHnsEnabled: "true" op in de parameters van de opslagklasse.
  • Als u blobfuse-toegang tot een Data Lake Storage-account in statische inrichting wilt inschakelen, geeft u de koppelingsoptie --use-adls=true op in het permanente volume.
  • Als u een opslagaccount met hiërarchische naamruimte wilt inschakelen, moeten bestaande permanente volumes opnieuw worden gekoppeld met --use-adls=true de koppelingsoptie.

• De blobfuse-cache bevindt zich standaard in de /mnt map. Als de VM-SKU een tijdelijke schijf biedt, wordt de /mnt map gekoppeld op de tijdelijke schijf. Als de VM-SKU echter geen tijdelijke schijf biedt, wordt de /mnt map gekoppeld op de besturingssysteemschijf, kunt u de koppelingsoptie instellen om een andere cachemap op te geven --tmp-path= .

Gebruik ingebouwde opslagklassen om dynamische PV's te maken met Azure Blob Storage

Er wordt een opslagklasse gebruikt om te definiëren hoe een Azure Blob Storage-container wordt gemaakt. Er wordt automatisch een opslagaccount gemaakt in de knooppuntresourcegroep voor gebruik met de opslagklasse voor het opslaan van de Azure Blob Storage-container. Wanneer u CSI-stuurprogramma's voor opslag in AKS gebruikt, zijn er twee extra ingebouwde stuurprogramma's die gebruikmaken van het CSI-stuurprogramma StorageClasses voor Azure Blob Storage.

Het terugneembeleid voor beide opslagklassen zorgt ervoor dat de onderliggende Azure Blob-opslag wordt verwijderd wanneer het respectieve PV wordt verwijderd. De opslagklassen configureren de container ook zodat deze standaard kan worden uitgebreid, omdat de set allowVolumeExpansion parameter is ingesteld op waar.

U kunt een van de volgende Azure Storage-redundantie-SKU's selecteren voor de skuname parameter in de definitie van de opslagklasse:

• Standard_LRS: Lokaal redundante standaardopslag
• Premium_LRS: Premium lokaal redundante opslag
• Standard_ZRS: Standaard zone-redundante opslag
• Premium_ZRS: Premium-zone-redundante opslag
• Standard_GRS: Standaard geografisch redundante opslag
• Standard_RAGRS: Georedundante opslag met leestoegang

Aangepaste opslagklassen maken voor dynamische tv's met Azure Blob Storage

De standaardopslagklassen zijn geschikt voor de meeste scenario's. In sommige gevallen wilt u mogelijk uw eigen opslagklasse aanpassen met uw eigen parameters. In deze sectie geven we twee voorbeelden: één met het NFS-protocol en één met behulp van blobfuse.

Voorbeeld van aangepaste opslagklasse met behulp van het NFS-protocol

Het manifest in dit voorbeeld koppelt een Blob Storage-container met behulp van het NFS-protocol. U kunt deze gebruiken om de tags parameter toe te voegen.

1. Maak een bestand met de naam blob-nfs-sc.yaml en plak het volgende voorbeeldmanifest:

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

2. Maak de opslagklasse met behulp van de kubectl apply opdracht:

   kubectl apply -f blob-nfs-sc.yaml
   

   De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

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

Voorbeeld van aangepaste opslagklasse met behulp van blobfuse

Het manifest in dit voorbeeld maakt gebruik van blobfuse en koppelt een Blob Storage-container. U kunt deze gebruiken om de skuName parameter bij te werken.

1. Maak een bestand met de naam blobfuse-sc.yaml en plak het volgende voorbeeldmanifest:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: blob-fuse
   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. Maak de opslagklasse met behulp van de kubectl apply opdracht:

   kubectl apply -f blobfuse-sc.yaml
   

   De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

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

Parameters van Opslagklasse voor dynamische PV's met Azure Blob Storage

Gebruik de volgende parametergroepen om een aangepaste opslagklasse te definiëren voor uw permanente volumeclaims (PVC's) met Azure Blob Storage:

• Opslagaccount: skuName, location, resourceGroup, subscriptionID, , storageAccount, accessTiernetworkEndpointType, , allowBlobPublicAccess, allowSharedKeyAccess, requireInfraEncryption, publicNetworkAccess, en matchTagstags.
• Container en eindpunt: protocol, , containerName, containerNamePrefix, server, storageEndpointSuffix, useDataPlaneAPI, , softDeleteBlobs, , en softDeleteContainersenableBlobVersioning.
• BlobFuse: storeAccountKey, getLatestAccountKey, secretName, en secretNamespaceisHnsEnabled.
• NFS: mountPermissions en fsGroupChangePolicy.
• Virtueel netwerk: vnetResourceGroup, vnetName, en subnetNamevnetLinkName.

Parameters voor opslagaccounts configureren voor dynamische tv's met Azure Blob-opslag

Gebruik de volgende parameters om het Azure opslagaccount te configureren voor een dynamisch ingerichte HW:

Container- en eindpuntparameters configureren voor dynamische TV's met Azure Blob Storage

Gebruik de volgende parameters voor het configureren van de container, het koppelingsprotocol, het opslageindpunt en tags voor een dynamisch ingerichte HW:

BlobFuse-parameters configureren voor dynamische tv's met Azure Blob Storage

De volgende parameters zijn alleen van toepassing wanneer u BlobFuse gebruikt voor een dynamisch ingerichte HW:

NFS-parameters configureren voor dynamische TV's met Azure Blob Storage

De volgende parameter is alleen van toepassing wanneer u NFS gebruikt voor een dynamisch ingerichte HW:

Parameters voor virtuele netwerken configureren voor dynamischeV's met Azure Blob Storage

Gebruik de volgende parameters wanneer het stuurprogramma de toegang tot een virtueel netwerk configureert voor een dynamisch ingerichte HW:

Privé-eindpunten configureren voor dynamische tv's met Azure Blob-opslag

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: blob-fuse
provisioner: blob.csi.azure.com
parameters:
  skuName: Premium_LRS  # available values: Standard_LRS, Premium_LRS, Standard_GRS, Standard_RAGRS, Standard_ZRS, Premium_ZRS
  protocol: fuse2
  networkEndpointType: privateEndpoint
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.

Een PVC maken voor dynamische inrichting

Een PVC maakt gebruik van het opslagklasseobject om een Azure Blob-opslag dynamisch in te richten. U kunt het YAML-voorbeeldmanifest in deze sectie gebruiken om een PVC te maken dat 5 GB groot is met ReadWriteMany-toegang . Zie Kubernetes PV-toegangsmodi voor meer informatie over toegangsmodi.

1. Maak een bestand met de naam blob-nfs-pvc.yaml en plak het volgende YAML-manifest:

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

2. Maak het PVC met behulp van de kubectl create opdracht:

   kubectl create -f blob-nfs-pvc.yaml
   

3. Bekijk de status van het PVC met de kubectl get opdracht:

   kubectl get pvc azure-blob-storage
   

   De uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer, waarin wordt aangegeven dat het PVC zich in een Bound status bevindt:

   NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                AGE
   azure-blob-storage   Bound    pvc-aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb   5Gi        RWX            azureblob-nfs-premium       92m
   

Een dynamisch ingericht blob-opslagvolume in een pod koppelen

Met de volgende YAML maakt u een pod die gebruikmaakt van de permanente volumeclaim azure-blob-storage om de Azure Blob-opslag aan het /mnt/blob pad te koppelen.

1. Maak een bestand met de naam blob-nfs-pv en plak het volgende YAML-manifest. Zorg ervoor dat de claimName PVC overeenkomt met het PVC dat u eerder hebt gemaakt (azure-blob-storage).

   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. Maak de pod met behulp van de kubectl apply opdracht:

   kubectl apply -f blob-nfs-pv.yaml
   

3. Zodra de pod met succes draait, maakt u een nieuw bestand met de naam test.txt met behulp van de volgende opdracht:

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

4. Controleer of de schijf correct is gekoppeld met behulp van de volgende opdracht om de bestanden in de gekoppelde map weer te geven:

   kubectl exec mypod -- ls /mnt/blob
   

   Uw uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer, waarin het test.txt bestand wordt weergegeven dat u hebt gemaakt in de gekoppelde Azure Blob-opslag:

   test.txt
   

Een StatefulSet gebruiken om de levenscyclus van een volume te beheren met Azure Blob Storage

Als u een opslagvolume wilt behouden voor uw workload, kunt u een StatefulSet gebruiken. Deze status maakt het gemakkelijker om bestaande volumes te koppelen aan nieuwe pods die eventuele mislukte pods vervangen. In de volgende voorbeelden ziet u hoe u een StatefulSet instelt voor Blob Storage met behulp van het NFS-protocol of Blobfuse.

Een statische PV maken met Azure Blob storage

De volgende secties bevatten instructies voor het maken van een statische PV met Azure Blob storage. Een statische PV is een permanent volume dat een beheerder handmatig maakt. Deze PV is beschikbaar voor gebruik van pods in het cluster. Als u een statische PV wilt gebruiken, maakt u een PVC dat verwijst naar de PV en maakt u vervolgens een pod die verwijst naar het PVC.

CSI-volumeparameters voor statische tv's met Azure Blob Storage

De volgende tabel bevat parameters die u kunt gebruiken in de CSI-volumebron voor een statische HW met Azure Blob Storage:

Een Blob Storage-container maken

Wanneer u een Azure Blob Storage-resource maakt voor gebruik met AKS, kunt u de resource maken in de knooppuntresourcegroep. Met deze methode kan het AKS-cluster toegang krijgen tot de blobopslagresource en deze beheren.

1. Haal de naam van de knooppuntresourcegroep van uw AKS-cluster op met behulp van de az aks show opdracht met de --query nodeResourceGroup parameter.

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

   De uitvoer van de opdracht lijkt op het volgende voorbeeld:

   MC_myResourceGroup_myAKSCluster_eastus
   

2. Als u het opslagaccount in de knooppuntresourcegroep maakt, gebruikt u de naam van de knooppuntresourcegroep die in de vorige stap is geretourneerd (bijvoorbeeld MC_myResourceGroup_myAKSCluster_eastus). Volg vervolgens de stappen in Blob Storage beheren om toegang te verlenen en een container in dat opslagaccount te maken.

Volume koppelen

In deze sectie koppelt u het permanente volume met behulp van het NFS-protocol of Blobfuse.

Het permanente volume gebruiken

Met de volgende YAML maakt u een pod die gebruikmaakt van de PV of PVC met de naam pvc-blob die u eerder hebt gemaakt om de Azure Blob-opslag aan het /mnt/blob pad te koppelen.

1. Maak een bestand met de naam nginx-pod-blob.yaml en plak het volgende YAML-manifest. Zorg ervoor dat de claimName pvc die eerder is gemaakt (pvc-blob) overeenkomt.

   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. Maak de pod en koppel het PVC met behulp van de kubectl create opdracht:

   kubectl create -f nginx-pod-blob.yaml
   

3. Maak een interactieve shellsessie met de pod om te controleren of de Blob-opslag correct is gekoppeld met behulp van de volgende kubectl exec opdracht:

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

   Uw uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer, waarin wordt weergegeven dat de Blob-opslag is gekoppeld aan het /mnt/blob pad:

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

Verwante inhoud

• Azure-tags gebruiken in Azure Kubernetes Service (AKS)
• Bekende problemen met NFS-protocolondersteuning (Network File System) 3.0 voor Azure Blob Storage