Teilen über

Erstellen und Verwenden eines Volumes mit Azure Blob Storage in Azure Kubernetes Service (AKS)

  • Artikel

Containerbasierte Anwendungen müssen häufig auf Daten in einem externen Datenvolume zugreifen und diese dauerhaft speichern. Wenn mehrere Pods gleichzeitigen Zugriff auf dasselbe Speichervolume benötigen, können Sie Azure Blob Storage verwenden, um eine Verbindung mit Blobfuse oder Network File System (NFS) herzustellen.

In diesem Artikel lernen Sie Folgendes:

  • Sie arbeiten mit einem dynamischen persistenten Volume (PV), indem Sie den CSI-Treiber (Container Storage Interface) installieren und dynamisch einen Azure Blob Storage-Container erstellen, der an einen Pod angefügt werden soll.
  • Sie arbeiten mit einem statischen PV, indem Sie einen Azure Blob Storage-Container erstellen oder einen vorhandenen verwenden und ihn an einen Pod anfügen.

Weitere Informationen zu Kubernetes-Volumes finden Sie unter Speicheroptionen für Anwendungen in AKS.

Voraussetzungen

  • Aktivieren Sie den CSI-Treiber für Blobspeicher für Ihren AKS-Cluster.

  • Um ein Azure DataLake Gen2-Speicherkonto bei Verwendung der BlobFuse-Einbindung zu unterstützen, müssen Sie die folgenden Schritte ausführen:

    • Um bei der dynamischen Bereitstellung ein ADLS-Konto mit dem Treiber zu erstellen, geben Sie isHnsEnabled: "true" in den Speicherklassenparametern an.
    • Um bei der statischen Bereitstellung den BlobFuse-Zugriff auf ein ADLS-Konto zu aktivieren, geben Sie im persistenten Volume die Bereitstellungsoption --use-adls=true an.
    • Wenn Sie ein Speicherkonto mit hierarchischem Namespace aktivieren möchten, sollten Sie vorhandene persistente Volumes mit der Einbindungsoption --use-adls=true erneut einbinden.

  • Informationen zum BlobFuse-Cache

    • Standardmäßig befindet sich der BlobFuse-Cache im Verzeichnis /mnt. Wenn die VM-SKU einen temporären Datenträger bereitstellt, wird das Verzeichnis /mnt auf dem temporären Datenträger eingebunden. Stellt die VM-SKU dagegen keinen temporären Datenträger, wird das Verzeichnis /mnt auf dem Betriebssystemdatenträger eingebunden. In diesem Fall können Sie die Einbindungsoption --tmp-path= festlegen, um ein anderes Cacheverzeichnis anzugeben.

Dynamisches Bereitstellen eines Volumes

Dieser Abschnitt enthält Anleitungen für Clusteradministratoren, die ein oder mehrere persistente Volumes mit Details zu Blob Storage bereitstellen möchten, wobei diese von einem Workload verwendet werden sollen. Ein Persistent Volume Claim (PVC) verwendet das Speicherklassenobjekt, um einen Azure Blob Storage-Container dynamisch bereitzustellen.

Speicherklassenparameter für dynamische persistente Volumes

Die folgende Tabelle enthält Parameter, die Sie zum Definieren einer benutzerdefinierten Speicherklasse für Ihren dauerhaften Volumeanspruch verwenden können.

Name Beschreibung des Dataflows Beispiel Obligatorisch. Standardwert
skuName Geben Sie einen Azure-Speicherkontotyp an (Alias: storageAccountType). Standard_LRS, Premium_LRS, Standard_GRS, Standard_RAGRS No Standard_LRS
location Geben Sie einen Azure-Standort an. eastus No Wenn leer, verwendet der Treiber denselben Standortnamen wie der aktuelle Cluster.
resourceGroup Geben Sie einen Azure-Ressourcengruppennamen an. myResourceGroup No Wenn leer, verwendet der Treiber denselben Ressourcengruppennamen wie der aktuelle Cluster.
storageAccount Geben Sie einen Azure-Speicherkontonamen an. storageAccountName Nein Wenn kein bestimmter Speicherkontoname angegeben wird, sucht der Treiber nach einem geeigneten Speicherkonto, das den Kontoeinstellungen innerhalb derselben Ressourcengruppe entspricht. Wenn kein übereinstimmende Speicherkonto gefunden werden kann, wird ein neues Konto erstellt. Falls jedoch ein Speicherkontoname angegeben wird, muss das Speicherkonto bereits vorhanden sein.
networkEndpointType Geben Sie den Netzwerkendpunkttyp für das vom Treiber erstellte Speicherkonto an. Wenn privateEndpoint angegeben wird, dann wird ein privater Endpunkt für das Speicherkonto erstellt. In anderen Fällen wird standardmäßig ein Dienstendpunkt für das NFS-Protokoll erstellt.1 privateEndpoint Nein Für einen AKS-Cluster fügen Sie der Rolle „Mitwirkender“ in der Ressourcengruppe, die das VNET hostet, den Namen des AKS-Clusters hinzu.
Protokoll Geben Sie den Blobfuse-Mount oder den NFSv3-Mount an. fuse, nfs Nein fuse
containerName Geben Sie den Namen des vorhandenen Containers (Verzeichnisses) an. Container Nein Wenn leer, erstellt der Treiber einen neuen Containernamen, beginnend mit pvc-fuse für blobfuse oder pvc-nfs für NFS v3.
containerNamePrefix Geben Sie das Präfix des vom Treiber erstellten Azure-Speicherverzeichnisses an. my Darf nur Kleinbuchstaben, Ziffern und Bindestriche enthalten und sollte weniger als 21 Zeichen lang sein. Nein
server Geben Sie den Domänennamen des Azure-Speicherkontos an. Vorhandener DNS-Domänenname des Speicherkontos, z. B. <storage-account>.privatelink.blob.core.windows.net. Nein Wenn leer, verwendet der Treiber standardmäßig <storage-account>.blob.core.windows.net oder einen anderen souveränen Cloud-Speicherkonto-DNS-Domänennamen.
allowBlobPublicAccess Erlauben oder verweigern Sie den öffentlichen Zugriff auf alle Blobs oder Container für das vom Treiber erstellte Speicherkonto. true,false Nein false
storageEndpointSuffix Geben Sie das Suffix für den Azure-Speicherendpunkt an. core.windows.net Nein Wenn leer, verwendet der Treiber das standardmäßige Speicherendpunkt-Suffix gemäß der Cloud-Umgebung.
tags Tags würden im neuen Speicherkonto erstellt. Tagformat: „foo=aaa,bar=bbb“ Nein ""
matchTags Tags abgleichen, wenn der Treiber versucht, ein geeignetes Speicherkonto zu finden. true,false Nein false
--- Folgende Parameter sind nur für blobfuse --- --- ---
subscriptionID Geben Sie die Azure-Abonnement-ID an, unter der das Blob-Speicherverzeichnis erstellt wird. Azure-Abonnement-ID Nein Ist dieser Wert nicht leer, muss resourceGroup angegeben werden.
storeAccountKey Geben Sie den Speicherkontoschlüssel für das Kubernetes-Geheimnis an.

Hinweis:
false bedeutet, dass der Treiber die Kubelet-Identität verwendet, um den Kontoschlüssel zu erhalten.		 true,false Nein true
secretName Geben Sie den geheimen Namen zum Speichern des Kontoschlüssels an. No
secretNamespace Geben Sie den Namespace des Geheimnisses zum Speichern des Kontoschlüssels an. default,kube-system, usw. Nein PVC-Namespace
isHnsEnabled Aktivieren Sie Hierarchical namespace für das Azure DataLake-Speicherkonto. true,false Nein false
--- Die folgenden Parameter gelten nur für das NFS-Protokoll --- --- ---
mountPermissions Geben Sie Berechtigungen für bereitgestellte Ordner an. Der Standardwert lautet 0777. Wenn auf 0 gesetzt, führt der Treiber chmod nach dem Mounten nicht aus. 0777 Nein

1 Wenn das Speicherkonto vom Treiber erstellt wird, müssen Sie nur den Parameter networkEndpointType: privateEndpoint in der Speicherklasse angeben. Der CSI-Treiber erstellt den privaten Endpunkt zusammen mit dem Konto. Wenn Sie Ihr eigenes Speicherkonto verwenden, müssen Sie den privaten Endpunkt für das Speicherkonto erstellen.

Erstellen Sie einen persistenten Volume-Claim mit der integrierten Speicherklasse

Ein Persistent Volume Claim (PVC) verwendet das Speicherklassenobjekt, um einen Azure Blob Storage-Container dynamisch bereitzustellen. Die folgende YAML-Datei kann verwendet werden, um einen persistenten Volume-Claim mit einer Größe von 5 GB mit ReadWriteMany-Zugriff unter Verwendung der integrierten Speicherklasse zu erstellen. Weitere Informationen zu Zugriffsmodi finden Sie in der Dokumentation zu persistenten Kubernetes-Volumes.

  1. Erstellen Sie eine Datei namens „blob-nfs-pvc.yaml“, und fügen Sie den folgenden YAML-Code ein.

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

  2. Erstellen Sie mit dem Befehl kubectl create den persistenten Volumeanspruch.

    kubectl create -f blob-nfs-pvc.yaml

Nach Abschluss wird der Blob Storage-Container erstellt. Mit dem Befehl kubectl get können Sie den Status des PVC anzeigen:

kubectl get pvc azure-blob-storage

Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

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

Verwenden Sie den persistenten Volume-Claim

Die folgende YAML-Datei erstellt einen Pod, der den persistenten Volume-Anspruch azure-blob-storage verwendet, um den Azure-Blobspeicher im Pfad „/mnt/blob“ bereitzustellen.

  1. Erstellen Sie eine Datei mit dem Namen blob-nfs-pv, und fügen Sie den folgenden YAML-Code ein. Stellen Sie sicher, dass der claimName mit dem im vorherigen Schritt erstellten PVC übereinstimmt.

    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. Erstellen Sie den Pod mit dem Befehl kubectl apply.

    kubectl apply -f blob-nfs-pv.yaml

  3. Warten Sie, bis der Pod ausgeführt wird, und führen Sie anschließend den folgenden Befehl aus, um eine neue Datei mit dem Namen test.txt zu erstellen:

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

  4. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Festplatte korrekt gemountet ist, und vergewissern Sie sich, dass die test.txt Datei in der Ausgabe angezeigt wird:

    kubectl exec mypod -- ls /mnt/blob

    Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

    test.txt

Erstellen einer benutzerdefinierten Speicherklasse

Die Standardspeicherklassen eignen sich für die gängigsten Szenarien, aber nicht für alle. In einigen Fällen möchten Sie möglicherweise Ihre eigene Speicherklasse mit eigenen Parametern anpassen. In diesem Abschnitt werden zwei Beispiele vorgestellt. Im ersten wird das NFS-Protokoll verwendet, und im zweiten wird Blobfuse verwendet.

Speicherklasse mit NFS-Protokoll

In diesem Beispiel konfiguriert das folgende Manifest das Mounten eines Blob Storage-Containers mithilfe des NFS-Protokolls. Verwenden Sie es, um den tags-Parameter hinzuzufügen.

  1. Erstellen Sie eine Datei mit dem Namen blob-nfs-sc.yaml, und fügen Sie das folgende Beispielmanifest ein:

    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. Verwenden Sie den Befehl kubectl apply zum Erstellen der Speicherklasse:

    kubectl apply -f blob-nfs-sc.yaml

    Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

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

Speicherklasse mithilfe von blobfuse

In diesem Beispiel wird mit dem folgenden Manifest ein Blob Storage-Container mithilfe von blobfuse konfiguriert und eingebunden. Verwenden Sie es, um den skuName-Parameter zu aktualisieren.

  1. Erstellen Sie eine Datei mit dem Namen blobfuse-sc.yaml, und fügen Sie das folgende Beispielmanifest ein:

    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. Verwenden Sie den Befehl kubectl apply zum Erstellen der Speicherklasse:

    kubectl apply -f blobfuse-sc.yaml

    Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

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

Statisches Bereitstellen eines Volumes

Dieser Abschnitt enthält Anleitungen für Clusteradministratoren, die ein oder mehrere persistente Volumes mit Details zu Blob Storage erstellen möchten, wobei diese von einem Workload verwendet werden sollen.

Statische Bereitstellungsparameter für dauerhafte Volumes

Die folgende Tabelle enthält Parameter, die Sie zum Definieren eines persistenten Volumens verwenden können.

Name Beschreibung des Dataflows Beispiel Obligatorisch. Standardwert
volumeHandle Geben Sie einen Wert an, mit dem der Treiber den Speicherblobcontainer im Cluster eindeutig identifizieren kann. Eine empfohlene Methode zur Erzeugung eines eindeutigen Werts ist das Kombinieren des global eindeutigen Speicherkontonamens mit dem Containernamen: {account-name}_{container-name}.
Hinweis: Die Zeichen # und / sind für die interne Verwendung reserviert und können nicht in einem Volumehandle verwendet werden.		 Ja
volumeAttributes.resourceGroup Geben Sie einen Azure-Ressourcengruppennamen an. myResourceGroup Nein Ohne Angabe verwendet der Treiber den gleichen Ressourcengruppennamen wie der aktuelle Cluster.
volumeAttributes.storageAccount Geben Sie den Namen eines vorhandenen Azure-Speicherkontos an. storageAccountName Ja
volumeAttributes.containerName Vorhandenen Containernamen verwenden. Container Ja
volumeAttributes.protocol Geben Sie den Blobfuse-Mount oder den NFS v3-Mount an. fuse, nfs Nein fuse
--- Folgende Parameter sind nur für Blobfuse --- --- ---
volumeAttributes.secretName Geheimer Name, der Speicherkontoname und -schlüssel speichert (gilt nur für SMB). Nein
volumeAttributes.secretNamespace Geben Sie den Namespace des Geheimnisses zum Speichern des Kontoschlüssels an. default Nein PVC-Namespace
nodeStageSecretRef.name Geben Sie den Namen des Geheimnisses an, das eins der folgenden Elemente speichert:
azurestorageaccountkey
azurestorageaccountsastoken
msisecret
azurestoragespnclientsecret.		 Nein Vorhandener geheimer Name in Kubernetes
nodeStageSecretRef.namespace Geben Sie den Namespace des geheimen Schlüssels an. Kubernetes-Namespace Ja
--- Die folgenden Parameter gelten nur für das NFS-Protokoll --- --- ---
volumeAttributes.mountPermissions Geben Sie Berechtigungen für bereitgestellte Ordner an. 0777 Nein
--- Die folgenden Parameter gelten nur für die NFS VNET-Einstellung --- --- ---
vnetResourceGroup Geben Sie die VNet-Ressourcengruppe an, die das virtuelle Netzwerk hostet. myResourceGroup Nein Wenn leer, verwendet der Treiber den vnetResourceGroup in der Azure-Cloudkonfigurationsdatei angegebenen Wert.
vnetName Geben Sie den Namen des virtuellen Netzwerks an. aksVNet Nein Wenn leer, verwendet der Treiber den vnetName-Wert in der Azure-Cloudkonfigurationsdatei.
subnetName Geben Sie den vorhandenen Subnetznamen des Agentknotens an. aksSubnet Nein Wenn leer, verwendet der Treiber den subnetNameWert in der Azure-Cloudkonfigurationsdatei.
--- Die folgenden Parameter sind nur für das Feature: Blobfuse
Authentifizierung von verwaltete Identität und Dienstprinzipalname		 --- --- ---
volumeAttributes.AzureStorageAuthType Gibt den Authentifizierungstyp an. Key, SAS, MSI, SPN Nein Key
volumeAttributes.AzureStorageIdentityClientID Geben Sie die Identitätsclient-ID an. No
volumeAttributes.AzureStorageIdentityResourceID Geben Sie die Identitätsressourcen-ID an. Nein
volumeAttributes.MSIEndpoint Geben Sie den MSI-Endpunkt an. Nein
volumeAttributes.AzureStorageSPNClientID Geben Sie die Client-ID von Azure Service Principal Name (SPN) an. Nein
volumeAttributes.AzureStorageSPNTenantID Geben Sie die Mandanten-ID von Azure SPN an. Nein
volumeAttributes.AzureStorageAADEndpoint Geben Sie den Microsoft Entra-Endpunkt an. Nein
--- Die folgenden Parameter sind nur für folgendes Features vorgesehen: Lesen des Kontoschlüssels durch Blobfuse oder SAS-Token aus Schlüsseltresor --- --- ---
volumeAttributes.keyVaultURL Geben Sie den DNS-Namen von Azure Key Vault an. {vault-name}.vault.azure.net Nein
volumeAttributes.keyVaultSecretName Geben Sie den geheimen Namen von Azure Key Vault an. Vorhandener geheimer Name von Azure Key Vault. Nein
volumeAttributes.keyVaultSecretVersion Version des Azure Key Vault-Geheimnisses. Vorhandene Version Nein Wenn leer, verwendet der Treiber die aktuelle Version.

Erstellen eines Blobspeicher-Containers

Wenn Sie einen Azure-Datenträger für die Verwendung mit AKS erstellen, können Sie die Datenträgerressource in der Knoten-Ressourcengruppe erstellen. Diese Vorgehensweise ermöglicht es dem AKS-Cluster, auf die Datenträgerressource zuzugreifen und diese zu verwalten.

In diesem Artikel erstellen Sie den Container in der Knoten-Ressourcengruppe. Rufen Sie zunächst den Namen der Ressourcengruppe mit dem Befehl az aks show ab, und fügen Sie den Abfrageparameter --query nodeResourceGroup hinzu. Im folgenden Beispiel wird die Knoten-Ressourcengruppe für den AKS-Cluster namens myAKSCluster in der Ressourcengruppe myResourceGroup abgerufen:

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

Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

MC_myResourceGroup_myAKSCluster_eastus

Erstellen Sie als Nächstes einen Container zum Speichern von Blobs, indem Sie die Schritte im Blobspeicher verwalten, um den Zugriff zu autorisieren und dann den Container zu erstellen.

Volume einbinden

In diesem Abschnitt binden Sie das persistente Volume mithilfe des NFS-Protokolls oder mit Blobfuse bereit.

Die Bereitstellung von Blob-Speicher mithilfe des NFS v3-Protokolls authentifiziert sich nicht mit einem Kontoschlüssel. Ihr AKS-Cluster muss sich auf demselben virtuellen Netzwerk mit Peering wie der Agentknoten befinden. Derzeit besteht die einzige Möglichkeit zum Sichern der Daten in Ihrem Speicherkonto in der Verwendung eines virtuellen Netzwerks und anderer Netzwerksicherheitseinstellungen. Weitere Informationen zum Einrichten des NFS-Zugriffs auf Ihr Speicherkonto finden Sie unter Blobspeicher einbinden mithilfe des Network File System (NFS) 3.0-Protokolls.

Im folgenden Beispiel wird veranschaulicht, wie ein Blob-Speichercontainer mithilfe des NFS-Protokolls als beständiges Volume bereitgestellt wird.

  1. Erstellen Sie eine Datei namens „pv-blob-nfs.yaml“, und fügen Sie den folgenden YAML-Code ein. Unter storageClass, aktualisieren Sie resourceGroup, storageAccountund containerName.

    Hinweis

    Der Wert volumeHandle sollte eine eindeutige volumeID für jeden identischen Speicherblobcontainer im Cluster sein. Die Zeichen # und / sind für die interne Verwendung reserviert und können nicht verwendet werden.

    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

    Hinweis

    Obwohl das capacity-Attribut (Kapazität) der Kubernetes-API obligatorisch ist, wird dieser Wert nicht vom Azure Blob Storage-CSI-Treiber verwendet, da Sie Daten flexibel schreiben können, bis Sie das Kapazitätslimit Ihres Speicherkontos erreicht haben. Der Wert des capacity-Attributs wird nur für den Größenabgleich zwischen PersistentVolumes und PersistentVolumeClaims verwendet. Es wird empfohlen, einen fiktiven hohen Wert zu verwenden. Der Pod sieht ein eingebundenes Volume mit einer fiktiven Größe von 5 Petabyte.

  2. Führen Sie den folgenden Befehl aus, um das persistente Volume mithilfe des Befehls kubectl create zu erstellen, der auf die zuvor erstellte YAML-Datei verweist:

    kubectl create -f pv-blob-nfs.yaml

  3. Erstellen Sie eine pvc-blob-nfs.yaml-Datei mit einem PersistentVolumeClaim. Beispiel:

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

  4. Führen Sie den folgenden Befehl aus, um den persistenten Volumeanspruch mithilfe des Befehls kubectl create zu erstellen, der auf die zuvor erstellte YAML-Datei verweist:

    kubectl create -f pvc-blob-nfs.yaml

Verwenden des persistenten Volumes

Im folgenden YAML wird ein Pod erstellt, das den beständigen Volume- oder beständigen Volume-Anspruch namens pvc-blob verwendet, der zuvor erstellt wurde, um den Azure Blob Storage im Pfad /mnt/blob einzubinden.

  1. Erstellen Sie eine Datei mit dem Namen nginx-pod-blob.yaml, und fügen Sie den folgenden YAML-Code ein. Stellen Sie sicher, dass der AnspruchName dem im vorherigen Schritt erstellten PVC entspricht, wenn Sie ein beständiges Volume für NFS oder Blobfuse erstellen.

    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. Führen Sie den folgenden Befehl aus, um mithilfe des Befehls kubectl create, der auf die zuvor erstellte YAML-Datei verweist, den Pod zu erstellen und den PVC einzubinden:

    kubectl create -f nginx-pod-blob.yaml

  3. Führen Sie den folgenden Befehl aus, um eine interaktive Shellsitzung mit dem Pod zu erstellen, um den eingebundenen Blob-Speicher zu überprüfen:

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

    Die Ausgabe des Befehls sieht in etwa wie im folgenden Beispiel aus:

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

Nächste Schritte