Verwenden des Container Storage Interface (CSI)-Treibers für Azure-Datenträger in Azure Kubernetes Service (AKS)

  • Artikel

Der Container Storage Interface (CSI)-Treiber für Azure-Datenträger ist ein mit der CSI-Spezifikation konformer Treiber, der von Azure Kubernetes Service (AKS) zum Verwalten des Lebenszyklus von Azure-Datenträgern verwendet wird.

CSI ist ein Standard für die Bereitstellung beliebiger Block- und Dateispeichersysteme für containerisierte Workloads in Kubernetes. Durch die Einführung und Verwendung von CSI kann AKS nun Plug-Ins schreiben, bereitstellen und durchlaufen, um neue Speichersysteme in Kubernetes verfügbar zu machen oder vorhandene Speichersysteme in Kubernetes zu verbessern. Bei Verwendung von CSI-Treibern in AKS muss weder der Kerncode von Kubernetes geändert noch auf dessen Releasezyklen gewartet werden.

Informationen zum Erstellen eines AKS-Clusters mit CSI-Treiberunterstützung finden Sie unter Aktivieren von CSI-Treibern (Container Storage Interface) für Azure-Datenträger und Azure Files in Azure Kubernetes Service (AKS). Dieser Artikel beschreibt die Verwendung des Azure Disk-CSI-Treibers Version 1.

Hinweis

Azure Disk-CSI-Treiber v2 (Vorschau) verbessert die Skalierbarkeit und reduziert die Failover-Latenz von Pods. Sie verwendet freigegebene Datenträger, um Anfügereplikate auf mehreren Clusterknoten bereitzustellen, und ist mit dem Pod-Planer integriert, um sicherzustellen, dass im Falle eines Pod-Failovers ein Knoten mit einem Anfügereplikat ausgewählt wird. Der Azure Disk-CSI-Treiber v2 (Vorschau) bietet auch die Möglichkeit, die Leistung zu optimieren. Wenn Sie an der Vorschau teilnehmen möchten, senden Sie eine Anfrage: https://aka.ms/DiskCSIv2Preview. Diese Vorschauversion wird ohne Dienstebenenvereinbarung bereitgestellt, und während der Vorschauphase ist mit gelegentlichen Breaking Changes zu rechnen. Die Vorschauversion sollte nicht für Produktionsworkloads verwendet werden. Weitere Informationen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

Hinweis

Strukturinterne Treiber sind die aktuellen Speichertreiber, die Teil des Kubernetes-Kerncodes sind, also nicht die neuen CSI-Treiber, die als Plug-Ins bereitgestellt werden.

Features des Azure Disk-CSI-Treibers

Zusätzlich zu den Features des Strukturtreibers unterstützt der Azure Disk-CSI-Treiber folgende Features:

  • Leistungsverbesserungen bei gleichzeitiger Datenträgeranfügung und -trennung
    • Von Strukturtreibern werden Datenträger nacheinander angefügt oder getrennt. Von CSI-Treibern werden Datenträger per Batchvorgang angefügt bzw. getrennt. Es wird eine erhebliche Verbesserung erzielt, wenn mehrere Datenträger an einen einzelnen Knoten angefügt werden.
  • Premium SSD v1 und v2 werden unterstützt.
    • PremiumV2_LRS unterstützt nur den Cachemodus None
  • Unterstützung von ZRS-Datenträgern (zonenredundanter Speicher)
    • Die Datenträgertypen Premium_ZRS und StandardSSD_ZRS werden unterstützt. Ein ZRS-Datenträger kann für den Knoten mit oder ohne Zone geplant werden. Dabei gilt nicht die Einschränkung, dass sich das Datenträgervolume in derselben Zone wie ein bestimmter Knoten befinden muss. Weitere Informationen, einschließlich der unterstützten Regionen, finden Sie unter Zonenredundanter Speicher für verwaltete Datenträger.
  • Momentaufnahme
  • Volumeklon
  • Ändern der Größe eines persistenten Datenträgevolumes ohne Ausfallzeiten

Hinweis

Abhängig von der verwendeten VM-SKU kann der Azure Disk-CSI-Treiber ein Volumenlimit pro Knoten haben. Für einige leistungsstarke VMs (z. B. 16 Kerne) beträgt das Limit 64 Volumes pro Knoten. Um das Limit pro VM-SKU zu ermitteln, überprüfen Sie die Spalte Max. Datenträger für jede angebotene VM-SKU. Eine Liste der angebotenen VM-SKUs mit deren entsprechenden detaillierten Kapazitätslimits finden Sie unter Universelle VM-Größen.

Verwenden persistenter CSI-Volumes mit Azure-Datenträgern

Ein persistentes Volume (PV) stellt ein Speicherelement dar, das für die Verwendung mit Kubernetes-Pods bereitgestellt wurde. Ein persistentes Volume kann von einem oder mehreren Pods verwendet und dynamisch oder statisch bereitgestellt werden. In diesem Artikel erfahren Sie, wie Sie dynamisch PVs mit Azure-Datenträger zur Verwendung durch einen einzelnen Pod in einem AKS-Cluster erstellen können. Informationen zur statischen Bereitstellung finden Sie unter Manuelles Erstellen und Verwenden eines Volumes mit Azure-Datenträgern in Azure Kubernetes Service (AKS).

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

Dynamisches Erstellen von persistenten Azure-Datenträgervolumes mithilfe der integrierten Speicherklassen

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

Wenn Sie den Azure Disk-CSI-Treiber auf AKS verwenden, gibt es zwei weitere integrierte StorageClasses, die den Azure Disk-CSI-Speichertreiber verwenden. Die anderen CSI-Speicherklassen werden zusammen mit dem Cluster und zusätzlich zu den Standardspeicherklassen in der Struktur erstellt.

  • managed-csi: Verwendet lokal redundanten Azure-SSD Standard-Speicher (LRS) zum Erstellen eines verwalteten Datenträgers. Ab Kubernetes-Version 1.29 nutzt diese Speicherklasse in Azure Kubernetes Service (AKS)-Clustern, die über mehrere Verfügbarkeitszonen bereitgestellt werden, Azure Standard SSD Zone-Redundant Storage (ZRS), um verwaltete Datenträger zu erstellen.
  • managed-csi-premium: Verwendet lokal redundanten Azure-Premium-Speicher (LRS) zum Erstellen verwalteter Datenträger. Ab Kubernetes-Version 1.29 nutzt diese Speicherklasse in Azure Kubernetes Service (AKS)-Clustern, die über mehrere Verfügbarkeitszonen bereitgestellt werden, zonenredundanten Azure Premium-Speicher (ZRS) zum Erstellen verwalteter Datenträger.

Die Freigaberichtlinie in beiden Speicherklassen stellt sicher, dass beim Löschen eines persistenten Volumes auch die zugrunde liegenden Azure-Datenträger gelöscht werden. Die Speicherklassen konfigurieren die persistenten Volumes auch so, dass sie erweiterbar sind. Sie müssen nur den persistenten Volumeanspruch (PVC) mit der neuen Größe bearbeiten.

Um diese Speicherklassen zu verwenden, erstellen Sie einen PVC und den entsprechenden Pod, der auf diesen verweist und ihn verwendet. Ein Anspruch auf ein persistentes Volume wird verwendet, um basierend auf einer Speicherklasse automatisch Speicher bereitzustellen. Ein Anspruch auf ein persistentes Volume kann eine der vorab erstellten Speicherklassen oder eine benutzerdefinierte Speicherklasse verwenden, um einen verwalteten Azure-Datenträger für die gewünschte SKU und Größe zu erstellen. Wenn Sie eine Poddefinition erstellen, wird der Anspruch auf ein persistentes Volume angegeben, um den gewünschten Speicher anzufordern.

Erstellen Sie einen Beispielpod und einen entsprechenden PVC durch Ausführen des Befehls kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/pvc-azuredisk-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/nginx-pod-azuredisk.yaml

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

persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created

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

kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt

Führen Sie den folgenden Befehl aus, und überprüfen Sie, ob die Datei test.txt in der Ausgabe angezeigt wird, um sich zu vergewissern, dass der Datenträger ordnungsgemäß eingebunden ist:

kubectl exec nginx-azuredisk -- ls /mnt/azuredisk

lost+found
outfile
test.txt

Erstellen einer benutzerdefinierten Speicherklasse

Die Standardspeicherklassen sind für die meisten gängigen Szenarien geeignet. In einigen Fällen möchten Sie möglicherweise Ihre eigene Speicherklasse mit eigenen Parametern anpassen. Zum Beispiel können Sie bei Bedarf die Klasse volumeBindingMode ändern.

Sie können eine Klasse vom Typ volumeBindingMode: Immediate verwenden, um sicherzustellen, dass der Vorgang unmittelbar nach der Erstellung des PVC ausgeführt wird. Wenn Ihre Knotenpools durch die Topologie eingeschränkt sind – etwa bei Verwendung von Verfügbarkeitszonen – werden PVs ohne Kenntnis der Planungsanforderungen des Pods gebunden oder bereitgestellt.

Um dieses Szenario zu behandeln, können Sie volumeBindingMode: WaitForFirstConsumer verwenden, wodurch das Binden und Bereitstellen eines PVs verzögert wird, bis ein Pod erstellt wird, der den PVC verwendet. Dadurch wird das PV konform und in der Verfügbarkeitszone (oder einer anderen Topologie) bereitgestellt, die durch die Planungseinschränkungen des Pods angegeben ist. Die Standardspeicherklassen verwenden volumeBindingMode: WaitForFirstConsumerclass.

Erstellen Sie eine Datei namens sc-azuredisk-csi-waitforfirstconsumer.yaml, und fügen Sie anschließend das folgende Manifest ein. Die Speicherklasse entspricht der Speicherklasse managed-csi, es wird jedoch eine andere Klasse vom Typ volumeBindingMode verwendet.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Erstellen Sie die Speicherklasse durch Ausführen des Befehls kubectl apply, und geben Sie dabei die Datei sc-azuredisk-csi-waitforfirstconsumer.yaml an:

kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml

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

storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created

Volumesnapshots

Der Azure Disk-CSI-Treiber unterstützt die Erstellung von Momentaufnahmen von persistenten Volumes. Im Rahmen dieser Funktion kann der Treiber entweder vollständige oder inkrementelle Momentaufnahmen ausführen, je nach dem Wert, der im Parameter incremental festgelegt wurde (standardmäßig ist dies „true“).

Die folgende Tabelle enthält Details zu allen Parametern:

Name Bedeutung Verfügbarer Wert Obligatorisch. Standardwert
resourceGroup Ressourcengruppe zum Speichern von Momentaufnahmen VORHANDENE RESSOURCENGRUPPE No Ohne Angabe werden Momentaufnahmen in der gleichen Ressourcengruppe gespeichert wie die Azure-Quelldatenträger.
incremental Erstellen vollständiger oder inkrementeller Momentaufnahmen true, false Nein true
tags Tags von Azure-Datenträgern Tagformat: Schlüssel1=Wert1,Schlüssel2=Wert2 Nein ""
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. incremental muss auf false festgelegt werden.

Erstellen einer Volumemomentaufnahme

Hinweis

Bevor Sie fortfahren, stellen Sie sicher, dass die Anwendung keine Daten auf den Quelldatenträger schreibt.

Als Beispiel für diese Funktion erstellen Sie eine Volumemomentaufnahmenklasse mit dem Befehl kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/storageclass-azuredisk-snapshot.yaml

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

volumesnapshotclass.snapshot.storage.k8s.io/csi-azuredisk-vsc created

Erstellen Sie jetzt eine Volumemomentaufnahme mit dem Anspruch auf ein persistentes Volume (PVC), den Sie zu Beginn dieses Tutorials dynamisch erstellt haben (pvc-azuredisk).

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/azuredisk-volume-snapshot.yaml

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

volumesnapshot.snapshot.storage.k8s.io/azuredisk-volume-snapshot created

Um zu überprüfen, ob die Momentaufnahme ordnungsgemäß erstellt wurde, führen Sie den folgenden Befehl aus:

kubectl describe volumesnapshot azuredisk-volume-snapshot

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

Name:         azuredisk-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T05:27:58Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  714582
  Self Link:         /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
  UID:               dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azuredisk
  Volume Snapshot Class Name:      csi-azuredisk-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
  Creation Time:                       2020-08-31T05:27:59Z
  Ready To Use:                        true
  Restore Size:                        10Gi
Events:                                <none>

Erstellen eines neuen PVCs auf Basis einer Volumemomentaufnahme

Sie können einen neuen PVC auf der Grundlage einer Volumemomentaufnahme erstellen. Verwenden Sie die im vorigen Schritt erstellte Momentaufnahme, und erstellen Sie einen neuen PVC sowie einen neuen Pod, um ihn zu verwenden.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/pvc-azuredisk-snapshot-restored.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/snapshot/nginx-pod-restored-snapshot.yaml

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

persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created

Zum Schluss stellen wir sicher, dass es sich um denselben PVC handelt, der zuvor erstellt wurde, indem wir den Inhalt durch Ausführen des folgenden Befehls überprüfen:

kubectl exec nginx-restored -- ls /mnt/azuredisk

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

lost+found
outfile
test.txt

Wie erwartet, können wir immer noch unsere zuvor erstellte Datei test.txt sehen.

Klonen von Volumes

Ein geklontes Volumen ist als Duplikat eines vorhandenen Kubernetes-Volumens definiert. Weitere Informationen zum Klonen von Volumes in Kubernetes finden Sie in der konzeptionellen Dokumentation zum Klonen von Volumes.

Der CSI-Treiber für Azure-Datenträger unterstützt das Klonen von Volumes. Erstellen Sie zur Veranschaulichung ein geklontes Volume des zuvor erstellten Volumes azuredisk-pvc und einen neuen Pod, um es zu verwenden.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/pvc-azuredisk-cloning.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/cloning/nginx-pod-restored-cloning.yaml

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

persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created

Sie können den Inhalt des geklonten Volumes überprüfen, indem Sie den folgenden Befehl ausführen und sich vergewissern, dass die Datei test.txt erstellt wurde:

kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk

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

lost+found
outfile
test.txt

Ändern der Größe eines persistenten Volumes ohne Ausfallzeiten

Sie können ein größeres Volume für einen Anspruch auf ein persistentes Volume anfordern. Bearbeiten Sie das PVC-Objekt, und geben Sie eine höhere Größe an. Diese Änderung löst die Erweiterung des zugrunde liegenden Volumes für den Anspruch auf ein persistentes Volume aus.

Hinweis

Für den Anspruch wird nie ein neues persistentes Volume erstellt. Stattdessen wird die Größe eines vorhandenen Volumes geändert.

In AKS unterstützt die integrierte Speicherklasse managed-csi bereits Erweiterungen. Verwenden Sie daher den zuvor erstellten Anspruch auf ein persistentes Volume mit dieser Speicherklasse. Der PVC hat ein persistentes 10-Gi-Volume angefordert. Zur Bestätigung können Sie den folgenden Befehl ausführen:

kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk

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

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        9.8G   42M  9.8G   1% /mnt/azuredisk

Erweitern Sie den PVC, indem Sie das Feld spec.resources.requests.storage durch Ausführen des folgenden Befehls erhöhen:

kubectl patch pvc pvc-azuredisk --type merge --patch '{"spec": {"resources": {"requests": {"storage": "15Gi"}}}}'

Hinweis

Das Verkleinern persistenter Volumes wird derzeit nicht unterstützt. Beim Versuch, einen vorhandenen PVC mit einer kleineren Größe als der aktuellen zu patchen, wird die folgende Fehlermeldung angezeigt: The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

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

persistentvolumeclaim/pvc-azuredisk patched

Führen Sie den folgenden Befehl aus, um sich zu vergewissern, dass die Volumengröße erhöht wurde:

kubectl get pv

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

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            Delete           Bound    default/pvc-azuredisk                     managed-csi             2d2h
(...)

Warten Sie einige Minuten, und führen Sie dann die folgenden Befehle aus, um die Größe des PVC zu bestätigen:

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    pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            managed-csi    2d2h

Führen Sie den folgenden Befehl aus, um die Größe des Datenträgers innerhalb des Pods zu überprüfen:

kubectl exec -it nginx-azuredisk -- df -h /mnt/azuredisk

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

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         15G   46M   15G   1% /mnt/azuredisk

Bedarfsgesteuertes Bursting

Das Modell für bedarfsgesteuertes Bursting ermöglicht Datenträgerbursts, wenn der Bedarf die aktuelle Kapazität übersteigt. Dieses Modell generiert beim Bursting des Datenträgers zusätzliche Gebühren. Bedarfsgesteuertes Bursting ist nur für Premium-SSDs verfügbar, die größer als 512 GiB sind. Weitere Informationen zu bereitgestellten IOPS von SSD Premium sowie zum Durchsatz pro Datenträger finden Sie unter Premium SSD-Größe. Eine Alternative ist guthabenbasiertes Bursting. Hierbei wird Datenträgerbursting nur genutzt, wenn im zugehörigen Guthabenbucket entsprechendes Guthaben gesammelt wurde. Das guthabenbasierte Bursting generiert keine zusätzlichen Gebühren beim Bursting des Datenträgers. Das guthabenbasierte Bursting ist nur für SSD-Datenträger vom Typ Premium mit maximal 512 GiB sowie vom Typ Standard mit maximal 1024 GiB verfügbar. Weitere Informationen zum bedarfsgesteuerten Bursting finden Sie unter Bedarfsgesteuertes Bursting.

Wichtig

Bei der Standardspeicherklasse managed-csi-premium ist bedarfsgesteuertes Bursting deaktiviert, und es wird guthabenbasiertes Bursting verwendet. Bei Premium-SSDs, die dynamisch durch einen persistenten Volumeanspruch auf der Grundlage der Standardspeicherklasse managed-csi-premium erstellt werden, ist bedarfsgesteuertes Bursting ebenfalls deaktiviert.

Wenn Sie ein persistentes SSD Premium-Volume mit aktiviertem bedarfsgesteuertem Bursting erstellen möchten, können Sie eine neue Speicherklasse erstellen und dabei den Parameter enableBursting auf true festlegen, wie in der folgenden YAML-Vorlage zu sehen. Weitere Informationen zum Aktivieren von bedarfsgesteuertem Bursting finden Sie unter Bedarfsgesteuertes Bursting. Ausführlichere Informationen zum Erstellen Ihrer eigenen Speicherklasse mit aktiviertem bedarfsgesteuertem Bursting finden Sie unter Erstellen einer burstfähigen verwalteten CSI-Storage Premium-Klasse.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Windows-Container

Der CSI-Treiber des Azure-Datenträgers unterstützt Windows-Knoten und -Container. Wenn Sie Windows-Container verwenden möchten, gehen Sie wie in der Schnellstartanleitung für Windows-Container beschrieben vor, um einen Windows-Knotenpool hinzuzufügen.

Wenn Sie über einen Windows-Knotenpool verfügen, können Sie jetzt die integrierten Speicherklassen wie managed-csi verwenden. Sie können ein exemplarisches Windows-basiertes StatefulSet-Objekt bereitstellen, das Zeitstempel in der Datei data.txt speichert, indem Sie den folgenden Befehl vom Typ kubectl apply ausführen:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/deploy/example/windows/statefulset.yaml

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

statefulset.apps/busybox-azuredisk created

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

kubectl exec -it busybox-azuredisk-0 -- cat c:\\mnt\\azuredisk\\data.txt # on Linux/MacOS Bash
kubectl exec -it busybox-azuredisk-0 -- cat c:\mnt\azuredisk\data.txt # on Windows Powershell/CMD

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

2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)

Nächste Schritte