Freigeben über

Erstellen und Verwenden eines Volume mit Azure Files in Azure Kubernetes Service (AKS)

  • Artikel

Ein persistentes Volume stellt ein Speicherelement dar, das für die Verwendung in Kubernetes-Pods bereitgestellt wurde. Sie können ein persistentes Volume von einem oder mehreren Pods verwenden, und es kann dynamisch oder statisch bereitgestellt werden. Wenn mehrere Pods gleichzeitig Zugriff auf dasselbe Speichervolume benötigen, können Sie Azure Files verwenden, um mithilfe des Server Message Block-Protokolls (SMB) eine Verbindung herzustellen. In diesem Artikel wird gezeigt, wie Sie dynamisch eine Azure-Dateifreigabe erstellen, die von mehreren Pods in einem AKS-Cluster (Azure Kubernetes Service) verwendet wird.

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 eine oder mehrere Azure-Dateifreigaben erstellen, die an einen Pod angefügt werden sollen.
  • Sie arbeiten mit einem statischen PV, indem Sie eine oder mehrere Azure-Dateifreigaben erstellen, oder Sie verwenden eine vorhandene Dateifreigabe und fügen sie an einen Pod an.

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

Voraussetzungen

  • Sie benötigen ein Azure Storage-Konto.
  • Stellen Sie sicher, dass Version 2.0.59 oder höher der Azure-Befehlszeilenschnittstelle (Azure CLI) installiert und konfiguriert ist. Führen Sie az --version aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sei bei Bedarf unter Installieren der Azure CLI.
  • Bei der Wahl zwischen Standard- und Premium-Dateifreigaben ist es wichtig, das Bereitstellungsmodell und die Anforderungen des erwarteten Nutzungsmusters zu verstehen, das Sie in Azure Files ausführen möchten. Weitere Informationen finden Sie unter Auswählen einer Azure Files-Leistungsstufe basierend auf Nutzungsmustern.

Dynamisches Bereitstellen eines Volumes

Dieser Abschnitt enthält Anleitungen für Clusteradministratoren, die ein oder mehrere persistente Volumes mit Details zu einer oder mehreren Freigaben in Azure Files bereitstellen möchten. Ein Anspruch auf ein persistentes Volume (Persistent Volume Claim, PVC) verwendet das Speicherklassenobjekt, um eine Azure Files-Dateifreigabe dynamisch bereitzustellen.

Speicherklassenparameter für dynamische persistente Volumes

Die folgende Tabelle enthält Parameter, die Sie zum Definieren einer benutzerdefinierten Speicherklasse für „PersistentVolumeClaim“ verwenden können:

Name Bedeutung Verfügbarer Wert Obligatorisch. Standardwert
accountAccessTier Zugriffsebene für das Speicherkonto Für das Standard-Konto kann Hot oder Cool und für das Premium-Konto nur Premium ausgewählt werden. Nein Leer. Verwenden Sie die Standardeinstellung für verschiedene Speicherkontotypen.
accountQuota Hiermit wird das Kontingent für ein Konto eingeschränkt. Sie können ein maximales Kontingent in GB angeben (standardmäßig 102.400 GB). Wenn das Konto das angegebene Kontingent überschreitet, überspringt der Treiber die Auswahl des Kontos. Nein 102400
allowBlobPublicAccess Erlauben oder verweigern Sie den öffentlichen Zugriff auf alle Blobs oder Container für das vom Treiber erstellte Speicherkonto. true oder false Nein false
disableDeleteRetentionPolicy Angabe, ob DeleteRetentionPolicy für das vom Treiber erstellte Speicherkonto deaktiviert werden soll true oder false Nein false
enableLargeFileShares Hiermit wird angegeben, ob ein Speicherkonto mit aktivierten großen Dateifreigaben verwendet werden soll. Wenn dieses Flag auf true festgelegt ist, aber kein Speicherkonto mit aktivierten großen Dateifreigaben vorhanden ist, wird ein neues Speicherkonto mit aktivierten großen Dateifreigaben erstellt. Dieses Flag sollte mit der Standard-SKU verwendet werden, da für die mit der Premium-SKU erstellten Speicherkonten standardmäßig die largeFileShares-Option aktiviert ist. true oder false Nein false
folderName Angabe des Ordnernamens in der Azure-Dateifreigabe Vorhandener Ordnername in der Azure-Dateifreigabe Nein Ist der Ordnername in der Dateifreigabe nicht vorhanden, ist die Einbindung nicht erfolgreich.
getLatestAccount Hiermit wird bestimmt, ob der neueste Kontoschlüssel basierend auf der Erstellungszeit abgerufen werden soll. Dieser Treiber ruft standardmäßig den ersten Schlüssel ab. true oder false Nein false
location Geben Sie die Azure-Region des Azure-Speicherkontos an. Beispiel: eastus. Nein Ohne Angabe verwendet der Treiber den gleichen Standortnamen wie der aktuelle AKS-Cluster.
matchTags Tags abgleichen, wenn der Treiber versucht, ein geeignetes Speicherkonto zu finden. true oder false Nein false
networkEndpointType Geben Sie den Netzwerkendpunkttyp für das vom Treiber erstellte Speicherkonto an. Wird privateEndpoint angegeben, wird ein privater Endpunkt für das Speicherkonto erstellt. In anderen Fällen wird standardmäßig ein Dienstendpunkt erstellt. "",privateEndpoint Nein ""
Protokoll Geben Sie das Dateifreigabeprotokoll an. smb, nfs Nein smb
requireInfraEncryption Angabe, ob der Dienst eine sekundäre Verschlüsselungsebene mit plattformseitig verwalteten Schlüsseln für ruhende Daten für das vom Treiber erstellte Speicherkonto anwendet true oder false Nein false
resourceGroup Geben Sie die Ressourcengruppe für die Azure Disks an. Vorhandener Ressourcengruppenname Nein Ohne Angabe verwendet der Treiber den gleichen Ressourcengruppennamen wie der aktuelle AKS-Cluster.
selectRandomMatchingAccount Hiermit wird bestimmt, ob ein übereinstimmendes Konto nach dem Zufallsprinzip ausgewählt werden soll. Standardmäßig wählt der Treiber immer das erste übereinstimmende Konto in alphabetischer Reihenfolge aus. (Hinweis: Dieser Treiber verwendet den Kontosuchcache, was zu einer ungleichen Verteilung der Dateierstellung bei mehreren Konten führt.) true oder false Nein false
server Geben Sie die Serveradresse des Azure-Speicherkontos an. Vorhandene Serveradresse, z. B. accountname.privatelink.file.core.windows.net Nein Ohne Angabe verwendet der Treiber standardmäßig accountname.file.core.windows.net oder eine andere Sovereign Cloud-Kontoadresse.
shareAccessTier Zugriffsebene für die Dateifreigabe Für ein Konto vom Typ „Allgemein, Version 2“ kann zwischen TransactionOptimized (Standardwert), Hot und Cool gewählt werden. Kontotyp „Premium Storage“ nur für Dateifreigaben. Nein Leer. Verwenden Sie die Standardeinstellung für verschiedene Speicherkontotypen.
shareName Geben Sie einen Azure-Dateifreigabenamen an. Vorhandener oder neuer Name der Azure-Dateifreigabe Nein Ohne Angabe generiert der Treiber einen Namen für die Azure-Dateifreigabe.
shareNamePrefix Angabe des vom Treiber erstellten Präfixes für den Namen der Azure-Dateifreigabe Der Freigabename darf nur Kleinbuchstaben, Ziffern und Bindestriche enthalten und sollte weniger als 21 Zeichen lang sein. Nein
skuName Azure Files-Speicherkontotyp (Alias: storageAccountType) Standard_LRS, Standard_ZRS, Standard_GRS, Standard_RAGRS, Standard_RAGZRS,Premium_LRS, Premium_ZRS Nein StandardSSD_LRS
Die Mindestgröße der Dateifreigabe für den Kontotyp „Premium“ beträgt 100 GB.
Der ZRS-Kontotyp wird in einer begrenzten Anzahl von Regionen unterstützt.
Die NFS-Dateifreigabe unterstützt nur den Kontotyp „Premium“.
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.
storageEndpointSuffix Geben Sie das Suffix für den Azure-Speicherendpunkt an. core.windows.net, core.chinacloudapi.cn usw. Nein Ohne Angabe verwendet der Treiber das Standardsuffix für den Speicherendpunkt gemäß der Cloudumgebung. Beispiel: core.windows.net.
tags Tags werden in einem neuen Speicherkonto erstellt. Tagformat: „foo=aaa,bar=bbb“ Nein ""
--- Die folgenden Parameter gelten nur für das NFS-Protokoll. --- ---
subscriptionID Angabe der Azure-Abonnement-ID, unter der die Azure-Datenfreigabe erstellt wird Azure-Abonnement-ID Nein Ist dieser Wert nicht leer, muss resourceGroup angegeben werden.
storeAccountKey Geben Sie an, ob der Kontoschlüssel im Kubernetes-Geheimnis gespeichert werden soll. true oder false
false bedeutet, dass der Treiber die Kubelet-Identität verwendet, um den Kontoschlüssel zu erhalten.		 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.

Hinweis:
Wenn secretNamespace nicht angegeben ist, wird das Geheimnis im gleichen Namespace wie der Pod erstellt.		 default,kube-system, usw. Nein PVC-Namespace, z. B. csi.storage.k8s.io/pvc/namespace
useDataPlaneAPI Geben Sie an, ob die Datenebenen-API für das Erstellen/Löschen/Ändern der Größe von Dateifreigaben verwendet werden soll. Dadurch könnte das Problem der SRP-API-Drosselung behoben werden, da die Datenebenen-API fast keine Beschränkung aufweist. Wenn Firewall- oder Vnet-Einstellungen für das Speicherkonto vorhanden sind, wäre ihre Ausführung jedoch nicht erfolgreich. true oder false Nein false
--- Die folgenden Parameter gelten nur für das NFS-Protokoll --- ---
mountPermissions Berechtigungen für eingebundene Ordner. Der Standardwert lautet 0777. Beim Festlegen auf 0 führt der Treiber chmod nach dem Einbinden nicht aus. 0777 Nein
rootSquashType Angabe des Root Squashing-Verhaltens für die Freigabe. Der Standardwert ist NoRootSquash. AllSquash, NoRootSquash, RootSquash Nein
--- Die folgenden Parameter gelten nur für die VNet-Einstellung. Beispiel: NFS, privater Endpunkt. --- ---
fsGroupChangePolicy Gibt an, wie der Besitz des Volume vom Treiber geändert wird. Pod securityContext.fsGroupChangePolicy wird ignoriert. OnRootMismatch (Standardwert), Always, None Nein OnRootMismatch
subnetName Subnetzname Vorhandener Subnetzname des Agent-Knotens Nein Wenn leer, verwendet der Treiber den subnetNameWert in der Azure-Cloudkonfigurationsdatei.
vnetName Name des virtuellen Netzwerks Name des vorhandenen virtuellen Netzwerks Nein Wenn leer, verwendet der Treiber den vnetNameWert in der Azure-Cloudkonfigurationsdatei.
vnetResourceGroup Geben Sie die VNet-Ressourcengruppe an, in der das virtuelle Netzwerk definiert ist. Vorhandener Ressourcengruppenname Nein Wenn leer, verwendet der Treiber den vnetResourceGroupWert in der Azure-Cloudkonfigurationsdatei.

Erstellen einer Speicherklasse

Speicherklassen definieren, wie eine Azure-Dateifreigabe erstellt wird. In der Knotenressourcengruppe wird automatisch ein Speicherkonto zur Verwendung mit der Speicherklasse und zur Speicherung der Azure Files-Dateifreigabe erstellt. Wählen Sie für skuName eine der folgenden Azure-Speicherredundanz-SKUs aus:

  • Standard_LRS: Standard – Lokal redundanter Speicher (LRS)
  • Standard_GRS: Standard – Georedundanter Speicher (GRS)
  • Standard_ZRS: Standard – Zonenredundanter Speicher (ZRS)
  • Standard_RAGRS: Standard – Georedundanter Speicher mit Lesezugriff (RA-GRS)
  • Premium_LRS: Premium – Lokal redundanter Speicher (LRS)
  • Premium_ZRS: Premium – Zonenredundanter Speicher (ZRS)

Hinweis

Die minimale Premium-Dateifreigabe beträgt 100 GB.

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 zu mountOptions finden Sie im Abschnitt Einbindungsoptionen.

    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 eines Anspruchs auf ein persistentes Volume

Ein Anspruch auf ein persistentes Volume (Persistent Volume Claim, PVC) verwendet das Speicherklassenobjekt, um eine Azure-Dateifreigabe dynamisch bereitzustellen. Der folgende YAML-Code kann verwendet werden, um einen Anspruch auf ein persistentes Volume der Größe 100 GB mit ReadWriteMany-Zugriff zu 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 den Anspruch auf ein persistentes Volume mit dem Befehl kubectl apply.

    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

Verwenden des persistenten Volumes

Mit dem folgenden YAML-Code wird ein Pod erstellt, der den Anspruch auf das persistente Volume my-azurefile verwendet, um die Azure Files-Dateifreigabe im Pfad /mnt/azure einzubinden. Geben Sie für Windows Server-Container einen mountPath gemäß 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 nun über einen ausgeführten Pod, bei dem Ihre Azure Files-Dateifreigabe im Verzeichnis /mnt/azure eingebunden wurde. 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

Der Standardwert für fileMode und dirMode lautet bei Kubernetes Versionen 1.13.0 und höher 0777. Wenn Sie das persistente Volume dynamisch mit einer Speicherklasse erstellen, können Sie Einbindungsoptionen im Speicherklassenobjekt angeben. Weitere Informationen finden Sie unter Einbindungsoptionen. Im folgenden Beispiel wird 0777 festgelegt:

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

Verwenden von Azure-Tags

Weitere Informationen zur Verwendung von Azure-Tags finden Sie unter Verwenden von Azure-Tags in Azure Kubernetes Service (AKS).

Statisches Bereitstellen eines Volumes

Dieser Abschnitt enthält Anleitungen für Clusteradministratoren, die ein oder mehrere persistente Volumes erstellen möchten, wobei diese Volumes Details zu einer vorhandenen Azure Files-Dateifreigabe für die Verwendung mit einem Workload enthalten.

Statische Bereitstellungsparameter für persistente Volumes

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

Name Bedeutung Verfügbarer Wert Obligatorisch. Standardwert
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.shareName Geben Sie einen Azure-Dateifreigabenamen an. fileShareName Ja
volumeAttributes.folderName Geben Sie einen Ordnernamen in der Azure-Dateifreigabe an. folderName Nein Ist der Ordnername in der Dateifreigabe nicht vorhanden, ist die Einbindung nicht erfolgreich.
volumeAttributes.protocol Geben Sie das Dateifreigabeprotokoll an. smb, nfs Nein smb
volumeAttributes.server Angabe der Serveradresse des Azure-Speicherkontos Vorhandene Serveradresse, z. B. accountname.privatelink.file.core.windows.net Nein Ohne Angabe verwendet der Treiber standardmäßig accountname.file.core.windows.net oder eine andere Sovereign Cloud-Kontoadresse.
--- Die folgenden Parameter gelten nur für das NFS-Protokoll. --- --- ---
volumeAttributes.secretName Geben Sie einen geheimen Namen an, in dem der Speicherkontoname und -schlüssel gespeichert sind. Nein
volumeAttributes.secretNamespace Geben Sie einen geheimen Namespace an. default,kube-system, usw. Nein PVC-Namespace (csi.storage.k8s.io/pvc/namespace)
nodeStageSecretRef.name Geben Sie einen geheimen Namen an, in dem der Speicherkontoname und -schlüssel gespeichert sind. Vorhandener geheimer Name. No Wenn er leer ist, verwendet der Treiber kubelet-Identität, um den Kontoschlüssel abzurufen.
nodeStageSecretRef.namespace Geben Sie einen geheimen Namespace an. Kubernetes-Namespace No
--- Die folgenden Parameter gelten nur für das NFS-Protokoll --- --- ---
volumeAttributes.fsGroupChangePolicy Gibt an, wie der Besitz eines Volume vom Treiber geändert wird. Pod securityContext.fsGroupChangePolicy wird ignoriert. OnRootMismatch (Standardwert), Always, None Nein OnRootMismatch
volumeAttributes.mountPermissions Geben Sie Berechtigungen für bereitgestellte Ordner an. Der Standardwert ist 0777. Nein

Erstellen einer Azure-Dateifreigabe

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)

  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 bei der Erstellung eines Kubernetes-Pod verwiesen wird.

  1. Erstellen Sie mit dem Befehl kubectl create secret das Geheimnis. Das folgende Beispiel erstellt ein Geheimnis mit dem Namen azure-secret und füllt die Felder azurestorageaccountname und azurestorageaccountkey aus dem vorherigen Schritt. 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 persistentes Volume

  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. Der Standardwert für die Einbindeoptionen für fileMode und dirMode ist 0777.

    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 mit dem Befehl kubectl create das persistente Volume.

    kubectl create -f azurefiles-pv.yaml

  3. Erstellen Sie eine neue Datei mit dem Namen 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 mit dem Befehl kubectl apply den PersistentVolumeClaim.

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

  5. Vergewissern Sie sich, dass mit dem Befehl kubectl get PersistentVolumeClaim erstellt und an PersistentVolume gebunden wurde.

    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 die Containerspezifikation, um auf Ihr PersistentVolumeClaim 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

Einbinden von Dateifreigaben als Inlinevolume

Hinweis

Um Leistungsproblem zu vermeiden, empfehlen wir, ein persistentes Volume anstelle eines Inlinevolumes zu verwenden, wenn zahlreiche Pods auf dieselbe Dateifreigabe zugreifen. Das Inlinevolume kann nur auf Geheimnisse zugreifen, die sich im selben Namespace wie der Pod befinden. Um einen anderen Geheimnis-Namespace anzugeben, verwenden Sie ein persistentes 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 gemäß 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

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

    kubectl apply -f azure-files-pod.yaml

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

    kubectl describe pod mypod

Nächste Schritte

Informationen zu CSI-Treiberparametern für Azure Files finden Sie unter CSI-Treiberparameter.

Entsprechenden bewährte Methoden finden Sie unter Bewährte Methoden für die Speicherung und Sicherungen in AKS.