Teilen über

Erstellen und Verwenden eines Volumes mit Azure-Datenträgern 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 Sie können es dynamisch oder statisch bereitstellen. In diesem Artikel wird erläutert, wie Sie persistente Volumes mit Azure-Datenträgern in einem AKS-Cluster (Azure Kubernetes Service) dynamisch erstellen können.

Hinweis

Ein Azure-Datenträger kann nur mit einem Zugriffsmodus vom Typ ReadWriteOnce eingebunden werden. Dadurch ist er für einen Knoten in AKS verfügbar. In diesem Zugriffsmodus können immer noch mehrere Pods auf das Volume zugreifen, wenn die Pods auf demselben Knoten ausgeführt werden. Weitere Informationen finden Sie unter Kubernetes PersistentVolume-Zugriffsmodi.

In diesem Artikel lernen Sie Folgendes:

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

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

Voraussetzungen

  • 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 Sie bei Bedarf unter Installieren der Azure CLI.

  • Der Azure Disk-CSI-Treiber weist ein Volumenlimit pro Knoten auf. Die Volumeanzahl ändert sich basierend auf der Größe des Knotens/Knotenpools. Führen Sie den Befehl kubectl get aus, um die Anzahl der Volumes zu ermitteln, die pro Knoten zugeordnet werden können:

    kubectl get CSINode <nodename> -o yaml

Dynamisches Bereitstellen eines Volumes

Dieser Abschnitt enthält Anleitungen für Clusteradministratoren, die ein oder mehrere persistente Volumes mit Details zu Azure Disk Storage bereitstellen möchten, wobei diese von einem Workload verwendet werden sollen. Ein Persistent Volume Claim (PVC) verwendet das Speicherklassenobjekt, um einen Azure Disk 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 „PersistentVolumeClaim“ verwenden können:

Name Bedeutung Verfügbarer Wert Obligatorisch. Standardwert
skuName Speicherkontotyp für Azure-Datenträger (Alias: storageAccountType) Standard_LRS, Premium_LRS, StandardSSD_LRS, PremiumV2_LRS, UltraSSD_LRS, Premium_ZRS, StandardSSD_ZRS Nein StandardSSD_LRS
fsType Dateisystemtyp ext4, ext3, ext2, xfs, btrfs für Linux, ntfs für Windows Nein ext4 für Linux, ntfs für Windows
cachingMode Azure Data Disk Host Cache Einstellung(PremiumV2_LRS und UltraSSD_LRS nur Support None Caching-Modus) None, ReadOnly, ReadWrite Nein ReadOnly
resourceGroup Angeben der Ressourcengruppe für die Azure Disks Vorhandener Ressourcengruppenname Nein Ohne Angabe verwendet der Treiber den gleichen Ressourcengruppennamen wie der aktuelle AKS-Cluster.
DiskIOPSReadWrite UltraSSD-Datenträger oder Premium SSD v2 IOPS-Funktion (minimum: 2 IOPS/GiB) 100~160.000 Nein 500
DiskMBpsReadWrite UltraSSD-Datenträger oder Premium SSD v2-Durchsatzfunktion (minimum: 0.032/GiB) 1~2.000 Nein 100
LogicalSectorSize Logische Sektorgröße in Bytes für Disk Ultra. Unterstützte Werte: 512 und 4.096. 4.096 ist der Standardwert. 512, 4096 Nein 4096
tags Tags für Azure-Datenträger Tagformat: key1=val1,key2=val2 Nein ""
diskEncryptionSetID Ressourcen-ID des Datenträgerverschlüsselungssatzes, der zum Aktivieren der Verschlüsselung ruhender Daten verwendet werden soll Format: /subscriptions/{subs-id}/resourceGroups/{rg-name}/providers/Microsoft.Compute/diskEncryptionSets/{diskEncryptionSet-name} Nein ""
diskEncryptionType Verschlüsselungstyp des Datenträgerverschlüsselungssatzes. EncryptionAtRestWithCustomerKey (Standardeinstellung), EncryptionAtRestWithPlatformAndCustomerKeys Nein ""
writeAcceleratorEnabled Schreibbeschleunigung für Azure-Datenträger true, false Nein ""
networkAccessPolicy Eigenschaft „networkAccessPolicy“ zur Vermeidung der Generierung des SAS-URI für einen Datenträger oder für eine Momentaufnahme AllowAll, DenyAll, AllowPrivate Nein AllowAll
diskAccessID Azure-Ressourcen-ID der Ressource „DiskAccess“ zur Verwendung privater Endpunkte auf Datenträgern Nein ``
enableBursting Aktivieren von bedarfsgesteuertem Bursting, das über das bereitgestellte Leistungsziel des Datenträgers hinausgeht. Bedarfsgesteuertes Bursting sollte nur für Premium-Datenträger und bei einer Datenträgergröße > 512 GB verwendet werden. Ultra-Datenträger und freigegebene Datenträger werden nicht unterstützt. Bursting ist standardmäßig deaktiviert. true, false Nein false
useragent Benutzer-Agent für die Zuordnung der Nutzung durch Kunden Nein Generierter Benutzer-Agent im Format driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Angeben der Azure-Abonnement-ID, unter der die Azure-Datenträger erstellt werden. Azure-Abonnement-ID Nein Ist dieser Wert nicht leer, muss resourceGroup angegeben werden.
--- Folgende Parameter sind nur für v2 --- --- ---
maxShares Die Gesamtzahl der freigegebenen Datenträgereinbindungen, die für den Datenträger zulässig sind. Durch Festlegen des Werts auf 2 oder mehr werden Anlagenreplikate aktiviert. Unterstützte Werte hängen von der Datenträgergröße ab. Unterstützte Werte finden Sie unter Freigeben eines verwalteten Azure-Datenträgers. Nein 1
maxMountReplicaCount Die Anzahl der zu erhaltenden Replikatanlagen. Dieser Wert muss im Bereich [0..(maxShares - 1)] liegen. Nein Wenn accessMode gleich ReadWriteMany ist, ist der Standardwert 0. Andernfalls ist der Standardwert maxShares - 1.

Integrierte Speicherklassen

Speicherklassen definieren, wie eine Speichereinheit dynamisch in einem persistenten Volume erstellt wird. Weitere Informationen zu Kubernetes-Speicherklassen finden Sie unter Kubernetes-Speicherklassen.

Jeder AKS-Cluster enthält vier vorab erstellte Speicherklassen, von denen zwei für die Arbeit mit Azure-Datenträgern konfiguriert sind:

  1. Die Speicherklasse default stellt einen Azure SSD Standard-Datenträger bereit.
    • Standard-SSDs basieren auf Standard-Laufwerken und stellen eine kostengünstige Speicherlösung mit zuverlässiger Leistung dar.
  2. Die Speicherklasse managed-csi-premium stellt einen Azure Premium-Datenträger bereit.
    • SSD-basierte hohe Leistung und geringe Wartezeit zeichnen Premium-Datenträger aus. Sie eignen sich ideal für virtuelle Computer, auf denen Produktionsworkloads ausgeführt werden. Wenn Sie den Azure Disk-CSI-Treiber in AKS verwenden, können Sie auch die managed-csi-Speicherklasse verwenden, die von lokal redundantem SSD Standards-Speicher (Locally Redundant Storage, LRS) unterstützt wird.
  3. Ab Kubernetes-Version 1.29 verwendet AKS bei der Bereitstellung von Azure Kubernetes Service (AKS)-Clustern über mehrere Verfügbarkeitszonen hinweg jetzt zonenredundanten Speicher (ZRS), um verwaltete Datenträger innerhalb integrierter Speicherklassen zu erstellen.
    • ZRS stellt die synchrone Replikation Ihrer von Azure verwalteten Datenträger in mehreren Azure-Verfügbarkeitszonen in Ihrer ausgewählten Region sicher. Diese Redundanzstrategie verbessert die Resilienz Ihrer Anwendungen und schützt Ihre Daten vor Rechenzentrumsfehlern.
    • Es ist jedoch wichtig zu beachten, dass zonenredundanter Speicher (ZRS) im Vergleich zu lokal redundantem Speicher (LRS) höhere Kosten verursacht. Wenn die Kostenoptimierung Priorität hat, können Sie eine neue Speicherklasse mit dem LRS-SKU-Namensparameter erstellen und in Ihrem Persistent Volume Claim (PVC) verwenden.

Die Verringerung der Größe eines PVC wird aufgrund des Risikos von Datenverlust nicht unterstützt. Sie können eine vorhandene Speicherklasse mit dem Befehl kubectl edit sc bearbeiten, oder Sie können eine eigene benutzerdefinierte Speicherklasse erstellen. Wenn Sie beispielsweise einen Datenträger mit einer Größe von 4 TiB verwenden möchten, müssen Sie eine Speicherklasse erstellen, die cachingmode: None definiert, da Datenträgerzwischenspeicherungen für Datenträger ab 4 TiB nicht unterstützt werden. Weitere Informationen zu Speicherklassen und der Erstellung eigener Speicherklassen finden Sie unter Speicheroptionen für Anwendungen in AKS.

Sie können die vordefinierten Speicherklassen mithilfe des Befehls kubectl get sc anzeigen. Im folgenden Beispiel werden die in einem AKS-Cluster verfügbaren vorab erstellten Speicherklassen gezeigt:

kubectl get sc

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

NAME                PROVISIONER                AGE
default (default)   disk.csi.azure.com         1h
managed-csi         disk.csi.azure.com         1h

Hinweis

Ansprüche für persistente Volumes werden in GiB angegeben, verwaltete Azure-Datenträger werden jedoch nach SKU für eine bestimmte Größe abgerechnet. 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.

Erstellen eines Anspruchs auf ein persistentes Volume

Ein Anspruch auf ein persistentes Volume (Persistent Volume Claim, PVC) stellt basierend auf einer Speicherklasse automatisch Speicher bereit. 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 namens azure-managed-disk mit einer Größe von 5 GB und 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.

  1. 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

Verwenden des persistenten Volumes

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 grundlegenden NGINX-Pod, der den Anspruch auf das persistente Volume azure-managed-disk verwendet, um den Azure-Datenträger im Pfad /mnt/azure einzubinden. Geben Sie für Windows Server-Container einen mountPath gemäß 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"
[...]

Verwenden von Azure Ultra Disks

Informationen zum Verwenden von Disk Ultra finden Sie unter Verwenden von Disk Ultra-Datenträgern in Azure Kubernetes Service (AKS).

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 mit Details zu Azure Disk Storage erstellen möchten, wobei diese von einem Workload verwendet werden sollen.

Statische Bereitstellungsparameter für ein persistentes Volumen

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

Name Bedeutung Verfügbarer Wert Obligatorisch. Standardwert
volumeHandle Azure-Datenträger-URI /subscriptions/{sub-id}/resourcegroups/{group-name}/providers/microsoft.compute/disks/{disk-id} Ja –
volumeAttributes.fsType Dateisystemtyp ext4, ext3, ext2, xfs, btrfs für Linux, ntfs für Windows Nein ext4 für Linux, ntfs für Windows
volumeAttributes.partition Partitionsnummer des vorhandenen Datenträgers (nur unter Linux unterstützt) 1, 2, 3 No Leer (keine Partition)
- Stellen Sie sicher, dass das folgende Partitionsformat verwendet wird: -part1.
volumeAttributes.cachingMode Cacheeinstellung für Datenträgerhost None, ReadOnly, ReadWrite No ReadOnly

Erstellen eines Azure-Datenträgers

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. Das folgende Beispiel erstellt einen Datenträger mit 20 GiB und gibt die ID des Datenträgers nach der Erstellung aus. 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 nach SKU für eine bestimmte Größe berechnet. 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.

    Die ID der Datenträgerressource 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

Einbinden des Datenträgers als Volume

  1. Erstellen Sie eine Datei pv-azuredisk.yaml mit einem PersistentVolume. Aktualisieren Sie volumeHandle mit der Datenträgerressourcen-ID aus dem vorherigen Schritt. Geben Sie für Windows Server-Container ntfs- für den Parameter fsType an.

    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

  2. Erstellen Sie eine Datei pvc-azuredisk.yaml mit einem PersistentVolumeClaim-Objekt, das PersistentVolume verwendet.

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

  3. Erstellen Sie PersistentVolume und PersistentVolumeClaim mithilfe des Befehls kubectl apply. Verweisen Sie dabei auf die beiden erstellten YAML-Dateien.

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

  4. Vergewissern Sie sich, dass mit dem Befehl kubectl get pvcPersistentVolumeClaim erstellt und an PersistentVolume gebunden 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

  5. Erstellen Sie eine Datei azure-disk-pod.yaml, um auf PersistentVolumeClaim zu verweisen. 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
  volumes:
    - name: azure
      persistentVolumeClaim:
        claimName: pvc-azuredisk

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

    kubectl apply -f azure-disk-pod.yaml

Bereinigen von Ressourcen

Wenn Sie mit den in diesem Artikel erstellten Ressourcen fertig sind, können Sie sie mithilfe des Befehls kubectl delete entfernen.

# Remove the pod
kubectl delete -f azure-pvc-disk.yaml

# Remove the persistent volume claim
kubectl delete -f azure-pvc.yaml

Nächste Schritte