Delen via


Een volume maken en gebruiken met Azure Blob Storage in Azure Kubernetes Service (AKS)

Toepassingen op basis van containers hebben vaak toegang nodig tot en persistente gegevens in een extern gegevensvolume. Als meerdere pods gelijktijdige toegang tot hetzelfde opslagvolume nodig hebben, kunt u Azure Blob Storage gebruiken om verbinding te maken met behulp van blobfuse of Network File System (NFS).

Dit artikel laat het volgende zien:

  • Werk met een dynamisch permanent volume (PV) door het CSI-stuurprogramma (Container Storage Interface) te installeren en dynamisch een Azure Blob Storage-container te maken die aan een pod moet worden gekoppeld.
  • Werk met een statische HW door een Azure Blob Storage-container te maken of gebruik een bestaande container en koppel deze aan een pod.

Zie Opslagopties voor toepassingen in AKS voor meer informatie over Kubernetes-volumes.

Voordat u begint

  • Schakel het CSI-stuurprogramma voor Blob Storage in op uw AKS-cluster.

  • Als u een Azure DataLake Gen2-opslagaccount wilt ondersteunen wanneer u blobfuse-koppeling gebruikt, moet u het volgende doen:

    • Als u een ADLS-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 ADLS-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.
  • Over blobfuse-cache

    • 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 --tmp-path= om een andere cachemap op te geven

Een volume dynamisch inrichten

Deze sectie bevat richtlijnen voor clusterbeheerders die een of meer permanente volumes willen inrichten met details van Blob Storage voor gebruik door een workload. Een permanente volumeclaim (PVC) maakt gebruik van het opslagklasseobject om een Azure Blob Storage-container dynamisch in te richten.

Parameters van opslagklasse voor dynamische permanente volumes

De volgende tabel bevat parameters die u kunt gebruiken om een aangepaste opslagklasse te definiëren voor uw permanente volumeclaim.

Name Omschrijving Voorbeeld Verplicht Default value
skuName Geef een Azure Storage-accounttype (alias: storageAccountType) op. Standard_LRS, , , Premium_LRSStandard_GRSStandard_RAGRS Nee Standard_LRS
locatie Geef een Azure-locatie op. eastus Nee Als het stuurprogramma leeg is, gebruikt het stuurprogramma dezelfde locatienaam als het huidige cluster.
resourceGroup Geef een Azure-resourcegroepnaam op. myResourceGroup Nee Als het stuurprogramma leeg is, gebruikt het stuurprogramma dezelfde naam van de resourcegroep als het huidige cluster.
storageAccount Geef een Azure Storage-accountnaam op. storageAccountName -Nee Wanneer er geen specifieke opslagaccountnaam is opgegeven, zoekt het stuurprogramma naar een geschikt opslagaccount dat overeenkomt met de accountinstellingen binnen dezelfde resourcegroep. Als er geen overeenkomend opslagaccount wordt gevonden, wordt er een nieuw opslagaccount gemaakt. Als er echter een naam voor een opslagaccount is opgegeven, moet het opslagaccount al bestaan.
networkEndpointType Geef het type netwerkeindpunt op voor het opslagaccount dat door het stuurprogramma is gemaakt. Als privateEndpoint is opgegeven, wordt er een privé-eindpunt gemaakt voor het opslagaccount. In andere gevallen wordt een service-eindpunt gemaakt voor het NFS-protocol.1 privateEndpoint Nee Voor een AKS-cluster voegt u de naam van het AKS-cluster toe aan de rol Inzender in de resourcegroep die als host fungeert voor het VNET.
protocol Geef blobfuse-koppeling of NFSv3-koppeling op. fuse, nfs Nee fuse
containerName Geef de naam van de bestaande container (map) op. container Nee Als dit leeg is, maakt het stuurprogramma een nieuwe containernaam, te beginnen voor pvc-fuse blobfuse of pvc-nfs voor NFS v3.
containerNamePrefix Geef het voorvoegsel van de Azure Storage-map op dat door het stuurprogramma is gemaakt. mijn Mag alleen kleine letters, cijfers, afbreekstreepjes en lengte van minder dan 21 tekens bevatten. Nee
server Geef de domeinnaam van het Azure-opslagaccount op. Bestaande DNS-domeinnaam van opslagaccount, bijvoorbeeld <storage-account>.privatelink.blob.core.windows.net. Nee Als het stuurprogramma leeg is, wordt standaard <storage-account>.blob.core.windows.net of een andere DNS-domeinnaam voor het soevereine cloudopslagaccount gebruikt.
allowBlobPublicAccess Openbare toegang tot alle blobs of containers toestaan of toestaan voor het opslagaccount dat door het stuurprogramma is gemaakt. true,false Nee false
storageEndpointSuffix Geef het achtervoegsel van het Azure-opslageindpunt op. core.windows.net Nee Als het stuurprogramma leeg is, wordt het standaardachtervoegsel voor het opslageindpunt gebruikt volgens de cloudomgeving.
tags Tags worden gemaakt in een nieuw opslagaccount. Labelindeling: 'foo=aaa,bar=bbb' Nee ""
matchTags Koppel tags wanneer het stuurprogramma probeert een geschikt opslagaccount te vinden. true,false Nee false
--- De volgende parameters zijn alleen voor blobfuse --- --- ---
subscriptionID Geef de Azure-abonnements-id op waarin de blobopslagmap wordt gemaakt. Azure-abonnements-id Nee Indien niet leeg, resourceGroup moet worden opgegeven.
storeAccountKey Geef de sleutel van het archiefaccount op in het Kubernetes-geheim.

Notitie:
false betekent dat het stuurprogramma kubelet-identiteit gebruikt om accountsleutel op te halen.
true,false Nee true
secretName Geef de geheime naam op om de accountsleutel op te slaan. Nee
secretNamespace Geef de naamruimte van het geheim op om de accountsleutel op te slaan. default,kube-system, enz. Nee pvc-naamruimte
isHnsEnabled Schakel het Hierarchical namespace azure Data Lake-opslagaccount in. true,false Nee false
--- De volgende parameters zijn alleen voor het NFS-protocol --- --- ---
mountPermissions Geef gekoppelde mapmachtigingen op. De standaardwaarde is 0777. Als dit is ingesteld 0, wordt het stuurprogramma niet uitgevoerd chmod na het koppelen. 0777 Nee

1 Als het opslagaccount door het stuurprogramma wordt gemaakt, hoeft u alleen de parameter in de opslagklasse op te geven networkEndpointType: privateEndpoint . Het CSI-stuurprogramma maakt het privé-eindpunt samen met het account. Als u uw eigen opslagaccount gebruikt, moet u het privé-eindpunt voor het opslagaccount maken.

Een permanente volumeclaim maken met behulp van ingebouwde opslagklasse

Een permanente volumeclaim (PVC) maakt gebruik van het opslagklasseobject om een Azure Blob Storage-container dynamisch in te richten. De volgende YAML kan worden gebruikt om een permanente volumeclaim van 5 GB te maken met ReadWriteMany-toegang , met behulp van de ingebouwde opslagklasse. Zie de documentatie voor permanente Kubernetes-volumes voor meer informatie over toegangsmodi.

  1. Maak een bestand met de naam blob-nfs-pvc.yaml en kopieer dit in de volgende YAML.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: azure-blob-storage
    spec:
      accessModes:
      - ReadWriteMany
      storageClassName: azureblob-nfs-premium
      resources:
        requests:
          storage: 5Gi
    
  2. Maak de permanente volumeclaim met de opdracht kubectl create :

    kubectl create -f blob-nfs-pvc.yaml
    

Zodra dit is voltooid, wordt de Blob Storage-container gemaakt. U kunt de opdracht kubectl get gebruiken om de status van het PVC weer te geven:

kubectl get pvc azure-blob-storage

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

De permanente volumeclaim gebruiken

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

  1. Maak een bestand met de naam blob-nfs-pven kopieer het in de volgende YAML. Zorg ervoor dat de claimName overeenkomt met het PVC dat in de vorige stap is gemaakt.

    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 de opdracht kubectl apply :

    kubectl apply -f blob-nfs-pv.yaml
    
  3. Nadat de pod de status Actief heeft, voert u de volgende opdracht uit om een nieuw bestand met de naam test.txtte maken.

    kubectl exec mypod -- touch /mnt/blob/test.txt
    
  4. Als u wilt controleren of de schijf correct is gekoppeld, voert u de volgende opdracht uit en controleert u of het test.txt bestand in de uitvoer wordt weergegeven:

    kubectl exec mypod -- ls /mnt/blob
    

    De uitvoer van de opdracht lijkt op het volgende voorbeeld:

    test.txt
    

Een aangepaste opslagklasse maken

De standaardopslagklassen zijn geschikt voor de meest voorkomende scenario's, maar niet allemaal. In sommige gevallen wilt u mogelijk uw eigen opslagklasse aanpassen met uw eigen parameters. In deze sectie geven we twee voorbeelden. De eerste maakt gebruik van het NFS-protocol en de tweede maakt gebruik van blobfuse.

Opslagklasse met behulp van NFS-protocol

In dit voorbeeld configureert het volgende manifest het koppelen van een Blob Storage-container met behulp van het NFS-protocol. Gebruik deze om de parameter tags toe te voegen.

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

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

    kubectl apply -f blob-nfs-sc.yaml
    

    De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Opslagklasse met behulp van blobfuse

In dit voorbeeld configureert het volgende manifest met behulp van blobfuse en koppelt een Blob Storage-container. Gebruik deze om de parameter skuName bij te werken.

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

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

    kubectl apply -f blobfuse-sc.yaml
    

    De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Statisch een volume inrichten

Deze sectie bevat richtlijnen voor clusterbeheerders die een of meer permanente volumes willen maken die details van Blob Storage bevatten voor gebruik door een workload.

Statische inrichtingsparameters voor permanente volumes

De volgende tabel bevat parameters die u kunt gebruiken om een permanent volume te definiëren.

Name Omschrijving Voorbeeld Verplicht Default value
volumeHandle Geef een waarde op die het stuurprogramma kan gebruiken om de opslagblobcontainer in het cluster uniek te identificeren. Een aanbevolen manier om een unieke waarde te produceren, is door de wereldwijd unieke opslagaccountnaam en containernaam te combineren: {account-name}_{container-name}.
Opmerking: het #/ teken is gereserveerd voor intern gebruik en kan niet worden gebruikt in een volumegreep.
Ja
volumeAttributes.resourceGroup Geef de naam van de Azure-resourcegroep op. myResourceGroup Nee Als dit leeg is, gebruikt het stuurprogramma dezelfde resourcegroepnaam als het huidige cluster.
volumeAttributes.storageAccount Geef een bestaande azure-opslagaccountnaam op. storageAccountName Ja
volumeAttributes.containerName Geef de bestaande containernaam op. container Ja
volumeAttributes.protocol Geef blobfuse-koppeling of NFS v3-koppeling op. fuse, nfs Nee fuse
--- De volgende parameters zijn alleen voor blobfuse --- --- ---
volumeAttributes.secretName Geheime naam waarin de naam en sleutel van het opslagaccount worden opgeslagen (alleen van toepassing op SMB). Nee
volumeAttributes.secretNamespace Geef de naamruimte van het geheim op om de accountsleutel op te slaan. default Nee Pvc-naamruimte
nodeStageSecretRef.name Geef een geheime naam op waarin een van de volgende items wordt opgeslagen:
azurestorageaccountkey
azurestorageaccountsastoken
msisecret
azurestoragespnclientsecret.
Nee Bestaande kubernetes-geheime naam
nodeStageSecretRef.namespace Geef de naamruimte van het geheim op. Kubernetes-naamruimte Ja
--- De volgende parameters zijn alleen voor het NFS-protocol --- --- ---
volumeAttributes.mountPermissions Geef gekoppelde mapmachtigingen op. 0777 Nee
--- De volgende parameters zijn alleen bedoeld voor de NFS-VNet-instelling --- --- ---
vnetResourceGroup Geef de VNet-resourcegroep op die als host fungeert voor een virtueel netwerk. myResourceGroup Nee Als het stuurprogramma leeg is, wordt de vnetResourceGroup waarde gebruikt die is opgegeven in het Configuratiebestand van de Azure-cloud.
vnetName Geef de naam van het virtuele netwerk op. aksVNet Nee Als het stuurprogramma leeg is, wordt de vnetName waarde gebruikt die is opgegeven in het Configuratiebestand van de Azure-cloud.
subnetName Geef de bestaande subnetnaam van het agentknooppunt op. aksSubnet Nee Als het stuurprogramma leeg is, wordt de waarde gebruikt in het configuratiebestand van de subnetName Azure-cloud.
--- De volgende parameters zijn alleen voor functie: blobfuse
Verificatie van beheerde identiteit en service-principal-naam
--- --- ---
volumeAttributes.AzureStorageAuthType Geef het verificatietype op. Key, , , SASMSISPN Nee Key
volumeAttributes.AzureStorageIdentityClientID Geef de id van de identiteitsclient op. Nee
volumeAttributes.AzureStorageIdentityResourceID Geef de id van de identiteitsresource op. Nee
volumeAttributes.MSIEndpoint Geef het MSI-eindpunt op. Nee
volumeAttributes.AzureStorageSPNClientID Geef de SPN-client-id (Azure Service Principal Name) op. Nee
volumeAttributes.AzureStorageSPNTenantID Geef de Azure SPN-tenant-id op. Nee
volumeAttributes.AzureStorageAADEndpoint Geef het Microsoft Entra-eindpunt op. Nee
--- De volgende parameters zijn alleen bedoeld voor de functie: blobfuse leesaccountsleutel of SAS-token uit de sleutelkluis --- --- ---
volumeAttributes.keyVaultURL Geef de DNS-naam van Azure Key Vault op. {vault-name}.vault.azure.net Nee
volumeAttributes.keyVaultSecretName Geef de geheime naam van Azure Key Vault op. De naam van het bestaande Azure Key Vault-geheim. Nee
volumeAttributes.keyVaultSecretVersion Geheime versie van Azure Key Vault. Bestaande versie Nee Als het stuurprogramma leeg is, wordt de huidige versie gebruikt.

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.

Maak voor dit artikel de container in de knooppuntresourcegroep. Haal eerst de naam van de resourcegroep op met de opdracht az aks show en voeg de --query nodeResourceGroup queryparameter toe. In het volgende voorbeeld wordt de knooppuntresourcegroep opgehaald voor het AKS-cluster met de naam myAKSCluster in de resourcegroep met de naam myResourceGroup:

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

Maak vervolgens een container voor het opslaan van blobs volgens de stappen in blobopslag beheren om toegang te autoriseren en maak vervolgens de container.

Volume koppelen

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

Het koppelen van Blob Storage met behulp van het NFS v3-protocol wordt niet geverifieerd met behulp van een accountsleutel. Uw AKS-cluster moet zich in hetzelfde of gekoppelde virtuele netwerk bevinden als het agentknooppunt. De enige manier om de gegevens in uw opslagaccount te beveiligen, is door gebruik te maken van een virtueel netwerk en andere netwerkbeveiligingsinstellingen. Zie Blob Storage koppelen met behulp van het NFS 3.0-protocol (Network File System) 3.0 voor meer informatie over het instellen van NFS-toegang tot uw opslagaccount.

In het volgende voorbeeld ziet u hoe u een Blob Storage-container koppelt als een permanent volume met behulp van het NFS-protocol.

  1. Maak een bestand met de naam pv-blob-nfs.yaml en kopieer dit in de volgende YAML. Onder storageClass, bijwerken resourceGroup, en containerNamestorageAccount.

    Notitie

    volumeHandle de waarde moet een unieke volume-id zijn voor elke identieke opslagblobcontainer in het cluster. Het teken # en / zijn gereserveerd voor intern gebruik en kunnen niet worden gebruikt.

    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
    

    Notitie

    Hoewel het kubernetes API-capaciteitskenmerk verplicht is, wordt deze waarde niet gebruikt door het CSI-stuurprogramma voor Azure Blob Storage, omdat u flexibel gegevens kunt schrijven totdat u de capaciteitslimiet van uw opslagaccount hebt bereikt. De waarde van het capacity kenmerk wordt alleen gebruikt voor het aanpassen van de grootte tussen PersistentVolumes en PersistentVolumeClaims. U wordt aangeraden een fictieve hoge waarde te gebruiken. De pod ziet een gekoppeld volume met een fictieve grootte van 5 Petabytes.

  2. Voer de volgende opdracht uit om het permanente volume te maken met behulp van de kubectl create-opdracht die verwijst naar het YAML-bestand dat u eerder hebt gemaakt:

    kubectl create -f pv-blob-nfs.yaml
    
  3. Maak een pvc-blob-nfs.yaml bestand met een PersistentVolumeClaim. Voorbeeld:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: pvc-blob
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      volumeName: pv-blob
      storageClassName: azureblob-nfs-premium
    
  4. Voer de volgende opdracht uit om de permanente volumeclaim te maken met behulp van de kubectl create-opdracht die verwijst naar het YAML-bestand dat u eerder hebt gemaakt:

    kubectl create -f pvc-blob-nfs.yaml
    

Het permanente volume gebruiken

Met de volgende YAML maakt u een pod die gebruikmaakt van het permanente volume of de permanente volumeclaim 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.yamlen kopieer het in de volgende YAML. Zorg ervoor dat de claimName overeenkomt met het PVC dat in de vorige stap is gemaakt bij het maken van een permanent volume voor NFS of 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. Voer de volgende opdracht uit om de pod te maken en het PVC te koppelen met behulp van de kubectl create-opdracht die verwijst naar het YAML-bestand dat u eerder hebt gemaakt:

    kubectl create -f nginx-pod-blob.yaml
    
  3. Voer de volgende opdracht uit om een interactieve shellsessie met de pod te maken om te controleren of de blobopslag is gekoppeld:

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

    De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Volgende stappen