Azure Storage CSI-Treiber und Volumebereitstellung

Dieser Abschnitt enthält Anleitungen für Clusteradministratoren, die ein oder mehrere persistente Volumes bereitstellen möchten, die Details des Blob-Speichers für die Verwendung durch eine Workload enthalten. Ein persistenter Volumeanspruch (PVC) verwendet das Speicherklassenobjekt, um einen Azure Blob Storage-Container dynamisch bereitzustellen.

Führen Sie die folgenden Schritte aus, um ein persistentes Volume mit Azure Blob Storage mit der bereitgestellten Speicherklasse bereitzustellen:

1. Erstellen Sie das StorageClass Manifest, indem Sie das folgende YAML in einer Datei namens blob-fuse-sc.yamlspeichern:

   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 specified value.
   

2. Um die Speicherklasse in Ihrem Cluster zu erstellen, wenden Sie den StorageClass folgenden Befehl an:

   kubectl apply -f blob-fuse-sc.yaml
   

Erstellen Sie ein PVC mit integrierter Speicherklasse

Eine Speicherklasse wird verwendet, um zu definieren, wie ein Azure-Blobspeichercontainer erstellt wird. In der Knotenressourcengruppe wird automatisch ein Speicherkonto erstellt, das mit der Speicherklasse verwendet wird, um den Azure-Blobspeichercontainer aufzunehmen. Wählen Sie für skuName eine der folgenden Azure-Speicherredundanz-SKUs aus:

• Standard_LRS: Lokal redundanter Standardspeicher
• Premium_LRS: Lokal redundanter Premium-Speicher
• Standard_ZRS: zonenredundanter Standardspeicher
• Premium_ZRS: zonenredundanter Premiumspeicher
• Standard_GRS: Standardmäßiger georedundanter Speicher
• Standard_RAGRS: Standardmäßiger georedundanter Lesezugriffsspeicher

Wenn Sie Speicher-CSI-Treiber StorageClasses auf AKS verwenden, gibt es zwei andere integrierte Treiber, die den Azure Blob CSI-Speichertreiber verwenden.

Die Freigaberichtlinie für beide Speicherklassen stellt sicher, dass beim Löschen eines persistenten Volumes auch der zugrunde liegende Azure-Blobspeicher gelöscht wird. Die Speicherklassen konfigurieren den Container auch so, dass er standardmäßig erweiterbar ist, da der Parameter set allowVolumeExpansion auf true festgelegt ist.

Mit dem Befehl kubectl get sc können Sie die Speicherklassen anzeigen. Im folgenden Beispiel werden die in einem AKS-Cluster verfügbaren Speicherklassen azureblob-fuse-premium und azureblob-nfs-premium angezeigt:

NAME                     PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
azureblob-fuse-premium   blob.csi.azure.com   Delete          Immediate           true                   23h
azureblob-nfs-premium    blob.csi.azure.com   Delete          Immediate           true                   23h

Um diese Speicherklassen zu verwenden, erstellen Sie einen PVC und den entsprechenden Pod, der auf diesen verweist und ihn verwendet. Ein PVC wird verwendet, um die Lagerung basierend auf einer Speicherklasse automatisch zuzuordnen. Sie können ein PVC entweder mit einer der integrierten Speicherklassen oder mit einer benutzerdefinierten Speicherklasse erstellen. Dieser PVC erstellt einen Azure Blob-Speichercontainer mit der von Ihnen angegebenen SKU, Größe und Protokoll. Wenn Sie eine Poddefinition erstellen, wird der Anspruch auf ein persistentes Volume angegeben, um den gewünschten Speicher anzufordern.

Ein PVC verwendet das Speicherklassenobjekt, um einen Azure Blob Storage-Container dynamisch bereitzustellen. Mit der integrierten Speicherklasse können Sie ein 5 GB PVC mit ReadWriteMany-Zugriff erstellen. Weitere Informationen zu Zugriffsmodi finden Sie in der Dokumentation zum persistenten Kubernetes-Volume .

1. Erstellen Sie eine Datei namens blob-nfs-pvc.yaml und kopieren Sie die folgende YAML:

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

2. Erstellen Sie das PVC mit dem Kubectl Create-Befehl :

   kubectl create -f blob-nfs-pvc.yaml
   

Nach Abschluss des Vorgangs wird der Blob-Speichercontainer erstellt. Sie können den Befehl kubectl get verwenden, um den Status des PVC anzuzeigen:

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

Montage des PVC

Im folgenden YAML wird ein Pod erstellt, das den PVC-Azure-Blob-Speicher verwendet, um den Azure Blob Storage auf dem /mnt/blob Pfad zu mounten.

1. Erstellen Sie eine Datei mit dem Namen blob-nfs-pv, und kopieren Sie die folgende YAML. 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. Nachdem sich der Pod im Ausgeführten Zustand befindet, führen Sie den folgenden Befehl aus, um eine neue Datei namens test.txtzu erstellen.

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

4. Um zu überprüfen, ob der Datenträger ordnungsgemäß bereitgestellt ist, führen Sie den folgenden Befehl aus, und überprüfen Sie, ob 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
   

Dieser Abschnitt enthält Anleitungen für Clusteradministratoren, die einen oder mehrere PVs erstellen möchten, die Details zum Blob-Speicher für die Verwendung durch eine Workload enthalten.

Erstellen eines Blobspeichercontainers

Wenn Sie eine Azure Blob Storage-Ressource für die Verwendung mit AKS erstellen, können Sie die Ressource in der Knotenressourcengruppe erstellen. Mit diesem Ansatz kann der AKS-Cluster auf die BLOB-Speicherressource zugreifen und diese verwalten.

Erstellen Sie für diesen Artikel den Container in der Knotenressourcengruppe. Rufen Sie zunächst den Ressourcengruppennamen mit dem az aks show Befehl ab, und fügen Sie den --query nodeResourceGroup Abfrageparameter hinzu. Im folgenden Beispiel wird die Knotenressourcengruppe für den AKS-Cluster mit dem Namen "myAKSCluster " in der Ressourcengruppe " myResourceGroup" angezeigt:

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 Manage blob Storage ausführen , um den Zugriff zu autorisieren und dann den Container zu erstellen.

In diesem Beispiel konfiguriert das folgende Manifest das Einbinden eines BLOB-Speichercontainers mithilfe des NFS-Protokolls. Verwenden Sie ihn, 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. Erstellen Sie die Speicherklasse mit dem Befehl "kubectl apply ":

   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
   

In diesem Beispiel konfiguriert das folgende Manifest BlobFuse und bindet einen Blob-Speichercontainer ein. Verwenden Sie ihn, 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. Erstellen Sie die Speicherklasse mit dem Befehl "kubectl apply ":

   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
   

Das Einbinden von Blob-Speicher mithilfe des NFS v3-Protokolls nutzt keinen Kontoschlüssel zur Authentifizierung. Ihr AKS-Cluster muss sich im selben oder einem vernetzten virtuellen Netzwerk wie der Agentknoten befinden. Die einzige Möglichkeit zum Sichern der Daten in Ihrem Speicherkonto besteht darin, ein virtuelles Netzwerk und andere Netzwerksicherheitseinstellungen zu verwenden. Weitere Informationen zum Einrichten des NFS-Zugriffs auf Ihr Speicherkonto finden Sie unter Mount Blob Storage mithilfe des Network File System (NFS) 3.0-Protokolls.

Im folgenden Beispiel wird veranschaulicht, wie sie einen BLOB-Speichercontainer mithilfe des NFS-Protokolls als persistentes Volume bereitstellen.

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 volumeHandle Wert in Ihrem YAML sollte eine eindeutige VolumeID für jeden identischen Speicher-BLOB-Container 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 Kubernetes-API-Kapazitätsattribut obligatorisch ist, wird dieser Wert nicht vom Azure Blob Storage CSI-Treiber verwendet, da Sie Daten flexibel schreiben können, bis Sie die Kapazitätsgrenze Ihres Speicherkontos erreichen. Der Wert des capacity Attributs wird nur für größenvergleiche zwischen PVs und PVCs verwendet. Wir empfehlen die Verwendung eines fiktiven hohen Werts. Der Pod sieht ein eingebundenes Laufwerk mit einer fiktiven Größe von 5 Petabytes.

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

   kubectl create -f pvc-blob-nfs.yaml
   

Kubernetes benötigt Anmeldeinformationen für den Zugriff auf den zuvor erstellten BLOB-Speichercontainer, bei dem es sich um einen Azure-Zugriffsschlüssel oder SAS-Token handelt. Diese Anmeldeinformationen werden in einem Kubernetes-Geheimnis gespeichert, auf das verwiesen wird, wenn Sie einen Kubernetes-Pod erstellen.

1. Verwenden Sie die kubectl create secret command Zum Erstellen des geheimen Schlüssels. Sie können sich mit einem Kubernetes-Geheimnis oder einem [shared access signature][sas-tokens] (SAS)-Token authentifizieren. Sie müssen auch den Kontonamen und den Schlüssel aus einem vorhandenen Azure-Speicherkonto angeben.

   • Kubernetes Secret
   • SAS-Token

   Im folgenden Beispiel wird ein Secret-Objekt mit dem Namen azure-secret erstellt und die Parameter azurestorageaccountname und azurestorageaccountkey werden befüllt.

   kubectl create secret generic azure-secret --from-literal azurestorageaccountname=NAME --from-literal azurestorageaccountkey="KEY" --type=Opaque
   

2. Erstellen Sie die Datei pv-blobfuse.yaml. Aktualisieren Sie unter volumeAttributescontainerName. Aktualisieren Sie name mit dem Namen des zuvor erstellten Secret-Objekts in nodeStateSecretRef. Beispiel:

   Hinweis

   Der volumeHandle Wert in Ihrem YAML sollte eine eindeutige VolumeID für jeden identischen Speicher-BLOB-Container 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: 10Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain  # If set as "Delete" container would be removed after pvc deletion
     storageClassName: azureblob-fuse-premium
     mountOptions:
       - -o allow_other
       - --file-cache-timeout-in-seconds=120
     csi:
       driver: blob.csi.azure.com
       # volumeid has to be 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:
         containerName: containerName
       nodeStageSecretRef:
         name: azure-secret
         namespace: default
   

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

   kubectl create -f pv-blobfuse.yaml
   

4. Erstellen Sie eine pvc-blobfuse.yaml-Datei mit einer PV. Beispiel:

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

5. Führen Sie den folgenden Befehl aus, um das PVC mit dem kubectl create-Befehl zu erstellen, der auf die zuvor erstellte YAML-Datei verweist:

   kubectl create -f pvc-blobfuse.yaml
   

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

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: statefulset-blob-nfs
     labels:
       app: nginx
   spec:
     serviceName: statefulset-blob-nfs
     replicas: 1
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:
           "kubernetes.io/os": linux
         containers:
           - name: statefulset-blob-nfs
             image: mcr.microsoft.com/azurelinux/base/nginx:1.25
             volumeMounts:
               - name: persistent-storage
                 mountPath: /mnt/blob
     updateStrategy:
       type: RollingUpdate
     selector:
       matchLabels:
         app: nginx
     volumeClaimTemplates:
       - metadata:
           name: persistent-storage
         spec:
           storageClassName: azureblob-nfs-premium
           accessModes: ["ReadWriteMany"]
           resources:
             requests:
               storage: 100Gi
   

2. Erstellen Sie "StatefulSet" mit dem kubectl create Befehl:

   kubectl create -f azure-blob-nfs-ss.yaml
   

1. Erstellen Sie eine Datei namens „azure-blobfuse-ss.yaml“, und fügen Sie den folgenden YAML-Code ein.

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: statefulset-blob
     labels:
       app: nginx
   spec:
     serviceName: statefulset-blob
     replicas: 1
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:
           "kubernetes.io/os": linux
         containers:
           - name: statefulset-blob
             image: mcr.microsoft.com/azurelinux/base/nginx:1.25
             volumeMounts:
               - name: persistent-storage
                 mountPath: /mnt/blob
     updateStrategy:
       type: RollingUpdate
     selector:
       matchLabels:
         app: nginx
     volumeClaimTemplates:
       - metadata:
           name: persistent-storage
         spec:
           storageClassName: azureblob-fuse-premium
           accessModes: ["ReadWriteMany"]
           resources:
             requests:
               storage: 100Gi
   

2. Erstellen Sie "StatefulSet" mit dem kubectl create Befehl:

   kubectl create -f azure-blobfuse-ss.yaml
   

¹ Wenn das Speicherkonto vom Treiber erstellt wird, müssen Sie nur den Parameter in der Speicherklasse angeben networkEndpointType: privateEndpoint . Der CSI-Treiber erstellt zusammen mit dem Konto den privaten Endpunkt und die private DNS-Zone (benannt privatelink.blob.core.windows.net). Wenn Sie Ihr eigenes Speicherkonto verwenden, müssen Sie den privaten Endpunkt für das Speicherkonto erstellen. Wenn Sie Azure Blob Storage in einem isolierten Cluster verwenden, müssen Sie eine benutzerdefinierte Speicherklasse mit networkEndpointType: privateEndpoint erstellen.

Sie können die Authentifizierung für verwaltete Identitäten oder Dienstprinzipalnamen (SPN) mit BlobFuse verwenden. Weitere Informationen finden Sie unter Verwaltete Identität und Dienstprinzipalnamenauthentifizierung.

Sie können die folgenden Parameter verwenden, um BlobFuse zum Lesen des Kontoschlüssels oder SAS-Tokens direkt aus Azure Key Vault zu aktivieren.

Ein PVC stellt die Lagerung basierend auf einer Lagerklasse automatisch fest. In diesem Fall kann ein PVC eine der zuvor erstellten Speicherklassen verwenden, um einen verwalteten Azure Standard- oder Premium-Datenträger zu erstellen.

1. Erstellen Sie eine Datei namens azure-pvc.yaml, und fügen Sie das folgende Manifest ein. Der Anspruch fordert einen Datenträger mit dem Namen azure-managed-disk und der Größe 5 GB mit ReadWriteOnce Zugriff an. Als Speicherklasse ist managed-csi angegeben.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
       name: azure-managed-disk
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: managed-csi
     resources:
       requests:
         storage: 5Gi
   

   Tipp

   Verwenden Sie zum Erstellen eines Datenträgers, der den Premium-Speicher verwendet, storageClassName: managed-csi-premium statt managed-csi.

2. Erstellen Sie mit dem Befehl kubectl apply einen Anspruch auf ein persistentes Volume, und geben Sie die Datei azure-pvc.yaml an.

   kubectl apply -f azure-pvc.yaml
   

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

   persistentvolumeclaim/azure-managed-disk created
   

Anwenden eines PVC auf eine Kapsel

Nachdem Sie den Anspruch für ein persistentes Volume erstellt haben, müssen Sie überprüfen, ob es den Status Pending hat. Der Status Pending gibt an, dass es bereit ist, von einem Pod verwendet zu werden.

1. Überprüfen Sie mit dem Befehl kubectl describe pvc den Status des PVC.

   kubectl describe pvc azure-managed-disk
   

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

   Name:            azure-managed-disk
   Namespace:       default
   StorageClass:    managed-csi
   Status:          Pending
   [...]
   

2. Erstellen Sie eine Datei namens azure-pvc-disk.yaml, und fügen Sie das folgende Manifest ein. Dieses Manifest erstellt einen einfachen NGINX-Pod, der den persistenten Volume Claim mit dem Namen azure-managed-disk verwendet, um den Azure-Datenträger am Pfad /mnt/azure bereitzustellen. Geben Sie für Windows Server-Container eine mountPath Verwendung der Windows-Pfadkonvention an, z. B. "D:".

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

3. Erstellen Sie den Pod mit dem Befehl kubectl apply.

   kubectl apply -f azure-pvc-disk.yaml
   

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

   pod/mypod created
   

4. Sie verfügen nun über einen ausgeführten Pod mit Ihrem Azure-Datenträger, der im Verzeichnis /mnt/azure eingebunden wurde. Überprüfen Sie die Pod-Konfiguration mit dem Befehl kubectl describe.

   kubectl describe pod mypod
   

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

   [...]
   Volumes:
     volume:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  azure-managed-disk
       ReadOnly:   false
      default-token-smm2n:
       Type:        Secret (a volume populated by a Secret)
       SecretName:  default-token-smm2n
       Optional:    false
   [...]
    Events:
     Type    Reason                 Age   From                               Message
     ----    ------                 ----  ----                               -------
     Normal  Scheduled              2m    default-scheduler                  Successfully assigned mypod to aks-nodepool1-79590246-0
     Normal  SuccessfulMountVolume  2m    kubelet, aks-nodepool1-79590246-0  MountVolume.SetUp succeeded for volume "default-token-smm2n"
     Normal  SuccessfulMountVolume  1m    kubelet, aks-nodepool1-79590246-0  MountVolume.SetUp succeeded for volume "pvc-faf0f176-8b8d-11e8-923b-deb28c58d242"
   [...]
   

Wenn Sie einen Azure-Datenträger für die Verwendung mit AKS erstellen, können Sie die Datenträgerressource in der Ressourcengruppe Knoten erstellen. Diese Vorgehensweise ermöglicht es dem AKS-Cluster, auf die Datenträgerressource zuzugreifen und diese zu verwalten. Wenn Sie den Datenträger stattdessen in einer separaten Ressourcengruppe erstellen, müssen Sie der verwalteten Identität von Azure Kubernetes Service (AKS) für Ihren Cluster die Rolle Contributor für die Ressourcengruppe des Datenträgers zuweisen.

1. Ermitteln Sie den Namen der Ressourcengruppe mithilfe des Befehls az aks show, und fügen Sie den Parameter --query nodeResourceGroup hinzu.

   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
   

2. Erstellen Sie mit dem Befehl az disk create einen Datenträger. Geben Sie den Knotennamen der Ressourcengruppe und einen Namen für die Datenträgerressource an, z. B. myAKSDisk. Im folgenden Beispiel wird ein 20 GiB-Datenträger erstellt und die ID des Datenträgers nach der Erstellung ausgegeben. Wenn Sie einen Datenträger für die Verwendung mit Windows Server-Containern erstellen möchten, fügen Sie den Parameter --os-type windows hinzu, um den Datenträger ordnungsgemäß zu formatieren.

   az disk create \
     --resource-group MC_myResourceGroup_myAKSCluster_eastus \
     --name myAKSDisk \
     --size-gb 20 \
     --query id --output tsv
   

   Hinweis

   Azure-Datenträger werden basierend auf der SKU für eine bestimmte Größe in Rechnung gestellt. Diese SKUs reichen von 32 GiB für S4- oder P4-Datenträger bis 32 TiB für S80- oder P80-Datenträger (in der Vorschau). Der Durchsatz und die IOPS-Leistung eines verwalteten Premium-Datenträgers hängen sowohl von der SKU als auch von der Instanzgröße der Knoten im AKS-Cluster ab. Weitere Informationen finden Sie unter Verwaltete Datenträger – Preise und Leistung.

   Die Datenträgerressourcen-ID wird angezeigt, sobald der Befehl erfolgreich abgeschlossen wurde, wie in der folgenden Beispielausgabe gezeigt. Sie können die Datenträger-ID verwenden, um den Datenträger im nächsten Abschnitt einzubinden.

   /subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk
   

Datenträger als Volume bereitstellen

1. Erstellen Sie eine Pv-azuredisk.yaml-Datei mit einer PV. Aktualisieren Sie volumeHandle mit der Datenträgerressourcen-ID aus dem vorherigen Schritt. Geben Sie für Windows Server-Container NTFS für den Parameter fsTypean.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: disk.csi.azure.com
     name: pv-azuredisk
   spec:
     capacity:
       storage: 20Gi
     accessModes:
       - ReadWriteOnce
     persistentVolumeReclaimPolicy: Retain
     storageClassName: managed-csi
     csi:
       driver: disk.csi.azure.com
       volumeHandle: /subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk
       volumeAttributes:
         fsType: ext4
   

Falls der Datenträger für den volumeHandle in einer separaten Ressourcengruppe erstellt wurde, müssen Sie der verwalteten Identität des AKS-Clusters die Rolle Contributor in der Ressourcengruppe des Datenträgers zuweisen.

1. Erstellen Sie eine PVC-azuredisk.yaml Datei mit einem PVC, das die PV verwendet.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-azuredisk
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 20Gi
     volumeName: pv-azuredisk
     storageClassName: managed-csi
   

2. Erstellen Sie das PV und PVC mithilfe des kubectl apply Befehls, und verweisen Sie auf die beiden yaML-Dateien, die Sie erstellt haben:

   kubectl apply -f pv-azuredisk.yaml
   kubectl apply -f pvc-azuredisk.yaml
   

3. Überprüfen Sie mit dem kubectl get pvc Befehl, ob Ihr PVC erstellt und mit der PV verbunden wurde.

   kubectl get pvc pvc-azuredisk
   

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

   NAME            STATUS   VOLUME         CAPACITY    ACCESS MODES   STORAGECLASS   AGE
   pvc-azuredisk   Bound    pv-azuredisk   20Gi        RWO                           5s
   

4. Erstellen Sie eine Datei azure-disk-pod.yaml, um auf PersistentVolumeClaim zu verweisen. Geben Sie für Windows Server-Container einen Pfad nach der Windows-Pfadkonvention an, z. B. "D:".

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     nodeSelector:
       kubernetes.io/os: linux
     containers:
     - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
       name: mypod
       resources:
         requests:
           cpu: 100m
           memory: 128Mi
         limits:
           cpu: 250m
           memory: 256Mi
       volumeMounts:
         - name: azure
           mountPath: /mnt/azure
     volumes:
       - name: azure
         persistentVolumeClaim:
           claimName: pvc-azuredisk
   

5. Wenden Sie die Konfiguration an, und binden Sie das Volume mithilfe des Befehls kubectl apply ein.

   kubectl apply -f azure-disk-pod.yaml
   

Die folgenden Parameter gelten nur für v2.

Mit einer Speicherklasse wird festgelegt, wie eine Azure-Dateifreigabe erstellt wird. Es wird automatisch ein Speicherkonto in der Knotenressourcengruppe für die Verwendung mit der Speicherklasse erstellt, in dem die Azure-Dateifreigabe gespeichert wird. Wählen Sie für skuName eine der folgenden Azure-Speicherredundanz-SKUs aus:

• Standard_LRS: Lokal redundanter Standardspeicher
• Standard_GRS: Standardmäßiger georedundanter Speicher
• Standard_ZRS: Standardzonenredundanter Speicher
• Standard_RAGRS: Standardmäßiger georedundanter Lesezugriffsspeicher
• Standard_RAGZRS: Standardmäßiger geozonenredundanter Lesezugriffsspeicher
• Premium_LRS: Lokal redundanter Premium-Speicher
• Premium_ZRS: Premium-zonenredundanter Speicher

Weitere Informationen zu Kubernetes-Speicherklassen für Azure Files finden Sie unter Kubernetes-Speicherklassen.

1. Erstellen Sie eine Datei mit dem Namen azure-file-sc.yaml, und fügen Sie das folgende Beispielmanifest ein. Weitere Informationen mountOptionsfinden Sie im Abschnitt " Mount options ".

   kind: StorageClass
   apiVersion: storage.k8s.io/v1
   metadata:
     name: my-azurefile
   provisioner: file.csi.azure.com # replace with "kubernetes.io/azure-file" if aks version is less than 1.21
   allowVolumeExpansion: true
   mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=0
    - gid=0
    - mfsymlinks
    - cache=strict
    - actimeo=30
    - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
   parameters:
     skuName: Premium_LRS
   

2. Erstellen Sie die Speicherklasse mit dem Befehl kubectl apply.

   kubectl apply -f azure-file-sc.yaml
   

Erstellen Sie ein PVC

Ein PVC verwendet das Speicherklassenobjekt, um eine Azure-Dateifreigabe dynamisch bereitzustellen. Mit dem folgenden YAML können Sie ein PVC mit 100 GB Größe mit ReadWriteMany-Zugriff erstellen. Weitere Informationen zu Zugriffsmodi finden Sie unter Persistentes Kubernetes-Volume.

1. Erstellen Sie eine Datei namens „azure-file-pvc.yaml“, und fügen Sie den folgenden YAML-Code ein. Stellen Sie sicher, dass storageClassName der Speicherklasse, die Sie im vorherigen Schritt erstellt haben, entspricht.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: my-azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: my-azurefile
     resources:
       requests:
         storage: 100Gi
   

   Hinweis

   Wenn Sie die Premium_LRS-SKU für die Speicherklasse verwenden, muss der Wert für storage mindestens 100Gi betragen.

2. Erstellen Sie das PVC mit dem kubectl apply Befehl.

   kubectl apply -f azure-file-pvc.yaml
   

   Nach Abschluss des Vorgangs wird die Dateifreigabe erstellt. Außerdem wird ein Kubernetes-Geheimnis erstellt, das die Verbindungs- und Anmeldeinformationen enthält. Mit dem Befehl kubectl get können Sie den Status des PVC anzeigen:

   kubectl get pvc my-azurefile
   

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

   NAME           STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
   my-azurefile   Bound     pvc-8436e62e-a0d9-11e5-8521-5a8664dc0477   100Gi       RWX           my-azurefile      5m
   

Montage des PVC

Im folgenden YAML wird ein Pod erstellt, das das PVC my-azurefile verwendet, um die Azure Files-Dateifreigabe auf dem Pfad /mnt/azure zu mounten. Geben Sie für Windows Server-Container einen Pfad nach der Windows-Pfadkonvention an, z. B. "D:".

1. Erstellen Sie eine Datei mit dem Namen azure-pvc-files.yaml, und fügen Sie den folgenden YAML-Code ein. Stellen Sie sicher, dass der claimName mit dem PVC übereinstimmt, den Sie im vorherigen Schritt erstellt haben.

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

2. Erstellen Sie den Pod mit dem Befehl kubectl apply.

   kubectl apply -f azure-pvc-files.yaml
   

   Sie verfügen jetzt über einen ausgeführten Pod mit Ihrer Azure Files-Dateifreigabe, die im Verzeichnis "/mnt/azure " bereitgestellt ist. Diese Konfiguration wird angezeigt, wenn Sie Ihren Pod mit dem Befehl kubectl describe überprüfen. In der folgenden verkürzten Beispielausgabe ist das im Container eingebundene Volume angegeben.

   Containers:
     mypod:
       Container ID:   docker://053bc9c0df72232d755aa040bfba8b533fa696b123876108dec400e364d2523e
       Image:          mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
       Image ID:       docker-pullable://nginx@sha256:d85914d547a6c92faa39ce7058bd7529baacab7e0cd4255442b04577c4d1f424
       State:          Running
         Started:      Fri, 01 Mar 2019 23:56:16 +0000
       Ready:          True
       Mounts:
         /mnt/azure from volume (rw)
         /var/run/secrets/kubernetes.io/serviceaccount from default-token-8rv4z (ro)
   [...]
   Volumes:
     volume:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  my-azurefile
       ReadOnly:   false
   [...]
   

Einbindungsoptionen

Für Kubernetes-Versionen 1.13.0 und höher sind die Standardwerte für fileMode und dirMode sind 0777. Wenn Sie PVs dynamisch mithilfe einer Speicherklasse bereitstellen, können Sie Bereitstellungsoptionen direkt im Speicherklassenmanifest definieren. Ausführliche Informationen finden Sie unter Bereitstellungsoptionen. Das folgende Beispiel veranschaulicht das Festlegen dieser Berechtigungen auf 0777:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com # replace with "kubernetes.io/azure-file" if aks version is less than 1.21
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
  - actimeo=30
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
parameters:
  skuName: Premium_LRS

Dieser Abschnitt enthält Anleitungen für Clusteradministratoren, die einen oder mehrere PVs erstellen möchten, die Details einer vorhandenen Azure Files-Freigabe enthalten, die mit einer Workload verwendet werden soll.

Erstellen einer Azure Files-Freigabe

Bevor Sie eine Azure Files-Dateifreigabe als Kubernetes-Volume verwenden können, müssen Sie ein Azure Storage-Konto und die Dateifreigabe erstellen.

1. Rufen Sie den Namen der Ressourcengruppe mithilfe des Befehls az aks show mit dem Parameter --query nodeResourceGroup ab.

   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
   

2. Erstellen Sie mithilfe des Befehls az storage account create mit dem Parameter --sku ein Speicherkonto. Mit dem folgenden Befehl wird ein Speicherkonto mithilfe der Standard_LRS-SKU erstellt. Achten Sie darauf, die folgenden Platzhalter zu ersetzen:

   • myAKSStorageAccount durch den Namen des Speicherkontos
   • nodeResourceGroupName durch den Namen der Ressourcengruppe, in der die AKS-Clusterknoten gehostet werden
   • location durch den Namen der Region, in der die Ressource erstellt werden soll. Es sollte sich um dieselbe Region wie die der AKS-Clusterknoten handeln.

   az storage account create -n myAKSStorageAccount -g nodeResourceGroupName -l location --sku Standard_LRS
   

3. Exportieren Sie die Verbindungszeichenfolge als Umgebungsvariable mit dem folgenden Befehl, den Sie zum Erstellen der Dateifreigabe verwenden.

   export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string -n storageAccountName -g resourceGroupName -o tsv)
   

   Verbindungszeichenfolgen müssen mithilfe von Schlüsseldrehung oder Speicher in einem Azure Key Vault geschützt werden. Weitere Informationen zu Verbindungszeichenfolgen finden Sie unter Konfigurieren von Azure Storage-Verbindungszeichenfolgen und Verwalten von Zugriffstasten für Speicherkonten.

   Für Produktionsumgebungen empfiehlt Microsoft die Verwendung der Microsoft Entra ID-Authentifizierung. Weitere Informationen finden Sie unter Autorisieren des Zugriffs auf Daten in Azure Storage.

4. Erstellen Sie mit dem Befehl az storage share create die Dateifreigabe . Stellen Sie sicher, dass Sie shareName durch Ihren Freigabenamen ersetzen.

   az storage share create -n shareName --connection-string $AZURE_STORAGE_CONNECTION_STRING
   

5. Exportieren Sie mit dem folgenden Befehl den Speicherkontoschlüssel als Umgebungsvariable.

   STORAGE_KEY=$(az storage account keys list --resource-group nodeResourceGroupName --account-name myAKSStorageAccount --query "[0].value" -o tsv)
   

6. Geben Sie mit dem folgenden Befehl den Namen und Schlüssel des Speicherkontos als Echo wieder. Kopieren Sie diese Informationen, da diese Werte beim Erstellen des Kubernetes-Volume benötigt werden.

   echo Storage account key: $STORAGE_KEY
   

Erstellen eines Kubernetes-Geheimnisses

Kubernetes benötigt Anmeldeinformationen für den Zugriff auf die im vorherigen Schritt erstellte Dateifreigabe. Diese Anmeldeinformationen werden in einem Kubernetes-Geheimnis gespeichert, auf das verwiesen wird, wenn Sie einen Kubernetes-Pod erstellen.

1. Erstellen Sie mit dem Befehl kubectl create secret das Geheimnis. Im folgenden Beispiel wird ein Geheimschlüssel mit dem Namen azure-secret erstellt und die Parameter "azurestorageaccountname " und "azurestorageaccountkey " aus dem vorherigen Schritt aufgefüllt. Um ein vorhandenes Azure Storage-Konto zu verwenden, geben Sie den Kontonamen und den Zugriffsschlüssel an.

   kubectl create secret generic azure-secret --from-literal=azurestorageaccountname=myAKSStorageAccount --from-literal=azurestorageaccountkey=$STORAGE_KEY
   

Einbinden einer Dateifreigabe als PV

1. Erstellen Sie eine neue Datei mit dem Namen azurefiles-pv.yaml, und kopieren Sie darin den folgenden Inhalt. Unter csi, aktualisieren Sie resourceGroup, volumeHandleund shareName. Für Bereitstellungsoptionen ist der Standardwert für fileMode und dirMode0777.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: file.csi.azure.com
     name: azurefile
   spec:
     capacity:
       storage: 5Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     storageClassName: azurefile-csi
     csi:
       driver: file.csi.azure.com
       volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"  # make sure this volumeid is unique for every identical share in the cluster
       volumeAttributes:
         shareName: aksshare
       nodeStageSecretRef:
         name: azure-secret
         namespace: default
     mountOptions:
       - dir_mode=0777
       - file_mode=0777
       - uid=0
       - gid=0
       - mfsymlinks
       - cache=strict
       - nosharesock
       - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
   

2. Erstellen Sie das PV mithilfe des kubectl create Befehls.

   kubectl create -f azurefiles-pv.yaml
   

3. Erstellen Sie eine neue Datei namens azurefiles-mount-options-pvc.yaml , und kopieren Sie den folgenden Inhalt.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: azurefile-csi
     volumeName: azurefile
     resources:
       requests:
         storage: 5Gi
   

4. Erstellen Sie das PVC mit dem kubectl apply Befehl.

   kubectl apply -f azurefiles-mount-options-pvc.yaml
   

5. Überprüfen Sie mithilfe des Befehls kubectl get, ob Ihr PVC erstellt und an die PV gebunden ist.

   kubectl get pvc azurefile
   

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

   NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
   

6. Aktualisieren Sie Ihre Containerspezifikation, um auf Ihr PVC und Ihren Pod in der YAML-Datei zu verweisen. Beispiel:

   ...
     volumes:
     - name: azure
       persistentVolumeClaim:
         claimName: azurefile
   

7. Eine Podspezifikation kann nicht an Ort und Stelle aktualisiert werden. Löschen Sie daher den Pod mithilfe des Befehls kubectl delete, und erstellen Sie ihn mithilfe des Befehls kubectl apply neu.

   kubectl delete pod mypod
   
   kubectl apply -f azure-files-pod.yaml
   

Bereitstellen der Dateifreigabe als Inline-Volume

Um die Azure Files-Dateifreigabe in den Pod einzubinden, konfigurieren Sie das Volume in der Containerspezifikation.

1. Erstellen Sie eine neue Datei mit dem Namen azure-files-pod.yaml, und kopieren Sie darin den folgenden Inhalt. Wenn Sie den Namen oder den geheimen Namen der Dateifreigabe geändert haben, aktualisieren Sie shareName und secretName. Sie können auch den Wert mountPath aktualisieren. Dies ist der Pfad, unter dem die Files-Freigabe im Pod eingebunden wird. Geben Sie für Windows Server-Container einen mountPath unter Verwendung der Windows-Pfadkonvention an, z. B. D:/.

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     nodeSelector:
       kubernetes.io/os: linux
     containers:
       - image: 'mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine'
         name: mypod
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             cpu: 250m
             memory: 256Mi
         volumeMounts:
           - name: azure
             mountPath: /mnt/azure
             readOnly: false
     volumes:
       - name: azure
         csi:
           driver: file.csi.azure.com
           volumeAttributes:
             secretName: azure-secret  # required
             shareName: aksshare  # required
             mountOptions: 'dir_mode=0777,file_mode=0777,cache=strict,actimeo=30,nosharesock,nobrl'  # optional
   

2. Erstellen Sie den Pod mit dem Befehl kubectl apply.

   kubectl apply -f azure-files-pod.yaml
   

   Sie verfügen jetzt über einen ausgeführten Pod mit einer Azure Files-Dateifreigabe, die unter "/mnt/azure" bereitgestellt wurde. Mit dem Befehl kubectl describe können Sie überprüfen, ob die Freigabe erfolgreich eingebunden wurde.

   kubectl describe pod mypod
   

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

¹ Wenn das Speicherkonto vom Treiber erstellt wird, müssen Sie nur den Parameter in der Speicherklasse angeben networkEndpointType: privateEndpoint . Der CSI-Treiber erstellt zusammen mit dem Konto den privaten Endpunkt und die private DNS-Zone (benannt privatelink.file.core.windows.net). Wenn Sie Ihr eigenes Speicherkonto verwenden, müssen Sie den privaten Endpunkt für das Speicherkonto erstellen. Wenn Sie den Azure Files-Speicher in einem isolierten Netzwerkcluster verwenden, müssen Sie eine benutzerdefinierte Speicherklasse mit "networkEndpointType: privateEndpoint" erstellen. Sie können diesem Beispiel zur Referenz folgen:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS, Standard_LRS, Standard_GRS, Standard_ZRS, Standard_RAGRS, Standard_RAGZRS
  networkEndpointType: privateEndpoint
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Die folgenden Parameter gelten nur für das SMB-Protokoll.

Die folgenden Parameter gelten nur für das NFS-Protokoll.

Die folgenden Parameter gelten nur für die VNet-Einstellung, z. B. NFS und privaten Endpunkt.

Die folgende Tabelle enthält Parameter, die Sie zum Definieren einer PV verwenden können.

Die folgenden Parameter gelten nur für das SMB-Protokoll.

Die folgenden Parameter gelten nur für das NFS-Protokoll.

Führen Sie die folgenden Schritte aus, um verwaltete Identität für dynamisch bereitgestellte Volumes zu aktivieren:

1. Erstellen Sie eine Speicherklasse mit aktivierter verwalteter Identität mithilfe einer YAML-Datei, azurefile-csi-managed-identity.yaml z. B. mit dem folgenden Beispielinhalt. Platzieren Sie mountWithManagedIdentity: "true" unter parameters:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: azurefile-csi
    provisioner: file.csi.azure.com
    parameters:
      resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
      storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
      mountWithManagedIdentity: "true"
      # optional, clientID of the managed identity, kubelet identity would be used by default if it's not provided
      clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
    reclaimPolicy: Delete
    volumeBindingMode: Immediate
    allowVolumeExpansion: true
    mountOptions:
     - dir_mode=0777  # modify this permission if you want to enhance the security
     - file_mode=0777
     - uid=0
     - gid=0
     - mfsymlinks
     - cache=strict  # https://linux.die.net/man/8/mount.cifs
     - nosharesock  # reduce probability of reconnect race
     - actimeo=30  # reduce latency for metadata-heavy workload
     - nobrl  # disable sending byte range lock requests to the server
   

2. Wenden Sie diese Speicherklasse an, indem Sie den folgenden Befehl ausführen:

   kubectl apply -f azurefile-csi-managed-identity.yaml
   

3. Stellen Sie Ihr StatefulSet oder Ihre Workload mithilfe der neuen Speicherklasse bereit, die auf dieses PVC verweist, um sicherzustellen, dass das Volume mithilfe der verwalteten Identitätsauthentifizierung bereitgestellt wird. Legen Sie storageClassName: azurefile-csi-managed-identity in Ihrem PVC-Manifest fest. Beispiel:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile-managed-identity-pvc
   spec:
     accessModes:
      - ReadWriteMany
     storageClassName: azurefile-csi-managed-identity
     resources:
      requests:
       storage: 100Gi
   

Führen Sie die folgenden Schritte aus, um verwaltete Identität für statisch bereitgestellte Volumes zu aktivieren:

1. Erstellen Sie ein PV-Manifest, z. B. azurefile-csi-static.yaml. Definieren Sie eine PV, die auf Ihre vorhandene Azure Files-Freigabe verweist, um die verwaltete Identitätsauthentifizierung zu ermöglichen, indem Sie mountWithManagedIdentity: "true" unter volumeAttributes festlegen.

   PV-Beispielmanifest:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv-azurefile
   spec:
     capacity:
       storage: 100Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     storageClassName: azurefile-csi
     mountOptions:
       - dir_mode=0777  # modify this permission if you want to enhance the security
       - file_mode=0777
       - uid=0
       - gid=0
       - mfsymlinks
       - cache=strict  # https://linux.die.net/man/8/mount.cifs
       - nosharesock  # reduce probability of reconnect race
       - actimeo=30  # reduce latency for metadata-heavy workload
       - nobrl  # disable sending byte range lock requests to the server
     csi:
       driver: file.csi.azure.com
       # make sure volumeHandle is unique for every identical share in the cluster
       volumeHandle: "{resource-group-name}#{account-name}#{file-share-name}"
       volumeAttributes:
         resourceGroup: EXISTING_RESOURCE_GROUP_NAME   # optional, node resource group by default if it's not provided
         storageAccount: EXISTING_STORAGE_ACCOUNT_NAME # optional, a new account will be created if it's not provided
         shareName: EXISTING_FILE_SHARE_NAME
         mountWithManagedIdentity: "true"
         # optional, clientID of the managed identity, kubelet identity would be used by default if it's empty
         clientID: "xxxxx-xxxx-xxx-xxx-xxxxxxx"
   

2. Stellen Sie die PV auf Ihrem Anwendungs pod bereit, indem Sie den folgenden Befehl ausführen:

   kubectl apply -f azurefile-csi-static.yaml
   

Dieser Abschnitt enthält Informationen zum Ansatz zur Leistungsoptimierung von NFS mit dem Azure Files CSI-Treiber mit den rsize Optionen (Lesegröße) und wsize (Schreibgröße). Die Optionen rsize und wsize legen gemeinsam die maximale Übertragungsgröße eines NFS-Vorgangs fest. Wenn rsize oder wsize beim Einbinden nicht angegeben werden, handeln Client und Server die höchste von beiden unterstützte Größe aus. Derzeit unterstützen sowohl Azure Files als auch moderne Linux-Distributionen Lese- und Schreibgrößen von bis zu 1.048.576 Bytes (1 MiB).

Für eine optimale Leistung muss die Client-Server-Kommunikation möglichst effizient sein. Das Erhöhen oder Verringern der Werte für Lese- und Schreibgröße der Bereitstellung kann die NFS-Leistung verbessern. Die Standardgröße der zwischen Client und Server übertragenen Lese-/Schreibpakete beträgt 8 KB für NFS Version 2 und 32 KB für NFS Version 3 und 4. Diese Standardwerte sind möglicherweise zu groß oder zu klein. Das Reduzieren von rsize und wsize könnte die NFS-Leistung in einem überlasteten Netzwerk verbessern, indem kleinere Pakete für jede NFS-Leseantwort und -schreibanforderung gesendet werden. Diese Reduzierung kann jedoch die Anzahl der Pakete erhöhen, die zum Senden von Daten über das Netzwerk benötigt werden, wodurch der gesamte Netzwerkdatenverkehr und die CPU-Auslastung auf dem Client und server erhöht werden.

Es ist wichtig, dass Sie Tests durchführen, um eine rsize effiziente Paketübertragung zu finden und wsize aufrechtzuerhalten, bei der der Durchsatz nicht verringert und die Latenz erhöht wird.

Um beispielsweise ein Maximum von rsize und wsize auf 256 KiB festzulegen, konfigurieren Sie die Speicherklasse mountOptions wie folgt:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30
  - rsize=262144
  - wsize=262144

1. Erstellen Sie eine Datei mit dem Namen nfs-sc.yaml , und kopieren Sie das Beispielmanifest. Eine Liste der unterstützten mountOptions finden Sie unter NFS-Einbindungsoptionen.

   Hinweis

   Der CSI-Treiber für Azure-Dateien konfiguriert vers, minorversion, und sec. Das Angeben eines Werts in Ihrem Manifest für diese Eigenschaften wird nicht unterstützt.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: azurefile-csi-nfs
   provisioner: file.csi.azure.com
   allowVolumeExpansion: true
   parameters:
     protocol: nfs
    mountOptions:
     - nconnect=4
     - noresvport
     - actimeo=30
   

2. Nachdem Sie Ihre YAML-Datei bearbeitet und gespeichert haben, wenden Sie die Speicherklasse mit dem Befehl "kubectl apply" an :

   kubectl apply -f nfs-sc.yaml
   

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

   storageclass.storage.k8s.io/azurefile-csi-nfs created
   

1. Sie können ein StatefulSet-Beispiel mithilfe des folgenden Manifests bereitstellen, das Zeitstempel in eine Datei schreibt, die mit dem data.txt benannt wird:

   kubectl apply -f
   
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: statefulset-azurefile
     labels:
       app: nginx
   spec:
     podManagementPolicy: Parallel  # default is OrderedReady
     serviceName: statefulset-azurefile
     replicas: 1
     template:
       metadata:
         labels:
           app: nginx
       spec:
         nodeSelector:
           "kubernetes.io/os": linux
         containers:
           - name: statefulset-azurefile
             image: mcr.microsoft.com/oss/nginx/nginx:1.19.5
             command:
               - "/bin/bash"
               - "-c"
               - set -euo pipefail; while true; do echo $(date) >> /mnt/azurefile/outfile; sleep 1; done
             volumeMounts:
               - name: persistent-storage
                 mountPath: /mnt/azurefile
     updateStrategy:
       type: RollingUpdate
     selector:
       matchLabels:
         app: nginx
     volumeClaimTemplates:
       - metadata:
           name: persistent-storage
         spec:
           storageClassName: azurefile-csi-nfs
           accessModes: ["ReadWriteMany"]
           resources:
             requests:
               storage: 100Gi
   

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

   statefulset.apps/statefulset-azurefile created
   

2. Führen Sie den folgenden Befehl aus, um den Inhalt des Volumes zu überprüfen:

   kubectl exec -it statefulset-azurefile-0 -- df -h
   

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

   Filesystem      Size  Used Avail Use% Mounted on
   ...
   /dev/sda1                                                                                 29G   11G   19G  37% /etc/hosts
   accountname.file.core.windows.net:/accountname/pvc-fa72ec43-ae64-42e4-a8a2-556606f5da38  100G     0  100G   0% /mnt/azurefile
   ...
   

Da sich der NFS in einem Premium-Speicherkonto befindet, beträgt die Mindestgröße der Dateifreigabe 100 GiB. Wenn Sie ein PVC mit einer kleinen Speichergröße erstellen, tritt möglicherweise ein Fehler auf, der der folgenden Ausgabe ähnelt:

*failed to create file share ... size (5)...*.

Mit AKS Version 1.33 stellt das Feature "Verschlüsselung bei Übertragung (EiT)Vorschau" sicher, dass alle Lese- und Schreibvorgänge in die NFS-Dateifreigaben innerhalb des VNet verschlüsselt sind, was eine zusätzliche Sicherheitsebene bietet.

Durch das Festlegen von encryptInTransit: "true" in den Speicherklassenparametern können Sie die Datenverschlüsselung für NFS Azure-Dateifreigaben im Transit einschalten. Beispiel:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
  encryptInTransit: "true"
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30

Die empfohlenen Einbindungsoptionen für SMB-Freigaben werden im folgenden Beispiel für die Speicherklasse bereitgestellt.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS  # available values: Premium_LRS, Premium_ZRS, Standard_LRS, Standard_GRS, Standard_ZRS, Standard_RAGRS, Standard_RAGZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777  # modify this permission if you want to enhance the security
  - file_mode=0777 # modify this permission if you want to enhance the security
  - mfsymlinks    # support symbolic links
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduces probability of reconnect race
  - actimeo=30  # reduces latency for metadata-heavy workload
  - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks

Wenn Sie Premium-Dateifreigaben (SSD) verwenden und Ihre Workload metadatenlastig ist, registrieren Sie sich für die Verwendung des Metadatenzwischenspeicherungsfeatures , um die Leistung zu verbessern.

Weitere Informationen finden Sie unter Verbessern der Leistung für SMB Azure-Dateifreigaben.

Die empfohlenen Bereitstellungsoptionen für NFS-Freigaben werden im folgenden Beispiel einer Speicherklasse gezeigt.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
parameters:
  protocol: nfs
  skuName: Premium_LRS     # available values: Premium_LRS, Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - nconnect=4  # improves performance by enabling multiple connections to share
  - noresvport  # improves availability
  - actimeo=30  # reduces latency for metadata-heavy workloads

Sie können den Lesedurchsatz verbessern, indem Sie die Read-Ahead-Größe erhöhen.

Während Azure Files die Einrichtung nconnect bis zur maximalen Einstellung von 16 unterstützt, empfehlen wir, die Bereitstellungsoptionen mit der optimalen Einstellung von nconnect=4 zu konfigurieren. Derzeit gibt es keine Vorteile über vier Kanäle hinaus für die Azure Files-Implementierung von nconnect.

Weitere Informationen finden Sie unter Verbessern der Leistung für NFS Azure-Dateifreigaben.