Erstellen und Verwenden eines Volumes mit Azure-Datenträgern in Azure Kubernetes Service (AKS)
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
Wenn das Volumenlimit pro Knoten ein Problem für Ihre Workload darstellt, sollten Sie anstelle von CSI-Treibern Azure Container Storage für persistente Volumes verwenden.
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:
- 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.
- 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.
- 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
- 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 Anspruch auf ein persistentes Volume (Persistent Volume Claim, PVC) verwenden.
Die Verringerung der Größe eines PVC wird aufgrund des Risikos von Datenverlusten 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.
Erstellen Sie eine Datei namens
azure-pvc.yaml
, und fügen Sie das folgende Manifest ein. Der Anspruch fordert einen Datenträger namensazure-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.
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.
Ü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 [...]
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
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
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 Befehlkubectl 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.
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
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
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
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
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
Vergewissern Sie sich, dass mit dem Befehl
kubectl get pvc
PersistentVolumeClaim 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
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
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
- Informationen zur Verwendung des CSI-Treibers für Azure Disk Storage finden Sie unter Verwenden von Azure Disk Storage mit CSI-Treibern.
- Entsprechenden bewährte Methoden finden Sie unter Bewährte Methoden für die Speicherung und Sicherungen in AKS.
Azure Kubernetes Service