Praxistipps: Azure CSI-Treiber in AKS installieren und nutzen

Grundlagen und Architektur

In AKS werden CSI-Treiber als Erweiterung über Add-ons oder native Integration verwendet, um In-Tree-Treiber zu ersetzen oder zu ergänzen. Ab Kubernetes Version 1.21 ist in AKS die CSI-Migration standardmäßig aktiviert, und AKS verwendet in der Regel CSI-Treiber für Speicheroperationen.

Microsoft bietet für Azure primär drei Kategorien von CSI-Treibern:

• Azure Disk CSI Driver für Blockspeicher (Managed Disks)
• Azure Files CSI Driver für Dateifreigaben (SMB/NFS)
• Azure Blob CSI Driver (relativ neuer) für die Einbindung von Blob-Container-Speicher via Blobfuse oder NFS-Protokoll

Jeder dieser Treiber nutzt das standardisierte CSI-Interface und besteht meist aus:

• CSI-Controller-Komponenten (im Control-Plane-Bereich), die mit Azure-APIs interagieren (zum Beispiel für das Erstellen von Disks oder File Shares).
• CSI-Node-Komponenten (als DaemonSet auf jedem Node), die Attach/Detach, Mount/Umount und Bind-Funktionen implementieren.
• StorageClasses, PersistentVolumes (PV) und PersistentVolumeClaims (PVC) als Kubernetes-Ressourcen, die der Anwender definiert.
• Support für Features wie Volume-Expansion, Snapshot, Cloning (falls vom Treiber und Azure unterstützt).

Ein Vorteil gegenüber In-Tree-Treibern ist, dass CSI-Treiber unabhängig vom Kubernetes-Core weiterentwickelt werden können, neue Funktionen schneller verfügbar sind und eine deutlichere Trennung von Kubernetes und Cloud-spezifischem Code erreicht wird.

Voraussetzungen

Es gibt verschiedene Voraussetzungen, die eine Umgebung erfüllen muss, bevor der CSI-Treiber installiert werden kann. Administratoren sollten sicherstellen, dass folgende Parameter erfüllt sind.

• Ein vorhandenes AKS-Cluster in einer unterstützten Kubernetes-Version (mindestens 1.21 oder höher ist empfohlen, da CSI-Migration dort Standard ist).
• az aks CLI (Azure CLI) und kubectl müssen eingerichtet und mit passenden Berechtigungen verbunden sein.
• Im Azure-Abonnement sind die relevanten Dienste und APIs aktiviert, etwa Microsoft.Compute (für Disks), Microsoft.Storage (für Files / Blob), eventuell auch Microsoft.StorageSync
• Der AKS-Cluster muss das entsprechende CSI-Treiber-Add-on aktiviert haben (je nach Azure-Region und Cluster-Konfiguration). In vielen Fällen ist der Azure Disk CSI- und Azure File CSI-Treiber bereits integriert.
• Für Azure Files benötig der Admin eine Storage Account-Instanz oder es wird automatisch eine Storage Account-Ressource angelegt, die der CSI-Treiber verwaltet.
• Für das Blob-CSI muss der Admin überprüfen, ob der Blob-CSI-Treiber für das Cluster aktiviert ist, insbesondere bei bestehenden Clustern.
• Die Netzwerk- und Zugriffsstruktur entsprechend eingerichtet sein. Das heißt beispielsweise, dass Nodes Berechtigungen haben, auf die Storage-Ressourcen zuzugreifen und geeignete VNet/Subnet-Konfigurationen installiert sind.

Darüber hinaus lassen sich weitere Maßnahmen umsetzen, um eine erfolgreiche Installation des Treibers zu gewährleisten. So ist eine Planung der Zonen und Verfügbarkeit empfehlenswert. Azure Disks sind in der Regel zonal und Node und Volume müssen in derselben Verfügbarkeitszone (Availability Zone) liegen. Wichtig für die Skalierbarkeit ist, dass der Administrator die maximale Anzahl an Disks pro VM-SKU kennt, zum Beispiel wie viele Laufwerke erlaubt sind.

Auch die Snapshot- und Backup-Strategie muss geprüft und eventuell angepasst werden. Hier kann der Admin beispielsweise die Entscheidung treffen, ob Azure Backup oder Snapshots über das CSI eingesetzt werden sollen.

Bei größeren Umgebungen kann eine Migration von In-Tree-Treibern auf CSI erforderlich sein, insbesondere darum, da neuere AKS-Versionen den In-Tree-Treiber nicht mehr unterstützen.

Schritt 1: Prüfen und Aktivieren des CSI-Treibers

In vielen neueren AKS-Clustern sind die Azure Disk und Azure Files CSI-Treiber bereits integriert oder als Default-Add-on aktiviert. Laut Microsoft verwendet AKS in aktuellen Versionen den CSI-Treiber nativ.

Um festzustellen, ob der CSI-Treiber aktiv ist, sollte der Admin folgendes prüfen:

• In der AKS-Clusterkonfiguration zum Beispiel mit az aks show nachsehen, ob die CSI-Treiber für Disk, Files oder Blob aktiviert sind.
• In kubectl get csidrivers sicherstellen, ob disk.csi.azure.com, file.csi.azure.com oder blob.csi.azure.com aufgelistet sind.
• Kontrollieren, ob StorageClasses existieren, die als provisioner zum Beispiel disk.csi.azure.com oder file.csi.azure.com nutzen.

Falls der Treiber nicht aktiviert ist, kann ihn der Anwender über die AKS-CLI nachträglich in Betrieb nehmen. Wie das geschieht, hängt von der Azure-Version und Feature-Verfügbarkeit ab. Ein Beispiel für einen solchen Befehl ist der folgende:

az aks update --name <ClusterName> --resource-group <RG> --enable-addons azure-keyvault-secrets-provider,file-csi,blob-csi

Der IT-Verantwortliche muss dabei beachten, dass auch die tatsächlichen Add-on-Namen je nach Azure Version variieren können. Microsoft bietet hier entsprechende Dokumentationen.

Darüber hinaus gilt es zu vermeiden, den Treiber manuell aus GitHub bereitzustellen, wenn er als integriertes Feature verfügbar ist, da die Managed-Version durch Azure gewartet wird.

Schritt 2: StorageClass für Azure Disk definieren

Für die weiteren Schritte fokussieren wir auf Azure Disk, das Block Storage. Für denBlockspeicher via Managed Disks erstellt der Admin eine StorageClass, die den Azure Disk CSI-Treiber (provisioner disk.csi.azure.com) verwendet.

Ein Beispiel hierfür ist:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-csi
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  kind: Managed
  cachingmode: ReadOnly
  # optional: zones: "1,2,3" (je nach Verfügbarkeitszonen)
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

In diesem Beispiel definiert sukname den Typ der Managed Disk, beispielsweise Standard_LRS, Premium_LRS, StandardSSD_ZRS oder Premium_ZRS. Mit kind: Managed wird spezifiziert, dass es sich um Azure Managed Disk handelt, während der cachingmode je nach Leistungs- und Konsistenzanforderung definiert wird, in diesem Falle als ReadOnly (nur Lesezugriffe).

Die Codezeile volumeBindingMode: WaitForFirstConsumer sorgt dafür, dass die Zone, in der das Volume erstellt wird, erst dann bestimmt wird, wenn der Pod geplant ist, um Disk/Node-Zone-Mismatch zu vermeiden. Mit anderen Worten wird hier eine Disk-Node-Diskrepanz verhindert. Eine nachträgliche Erweiterung des Volumes lässt sich mit allowVolumeExpansion: true umsetzen, ohne dabei eine Downtime zu riskieren. Optional kann der IT-Verantwortliche Zonen explizit angeben, falls er eine zonale Verteilung erzwingen will.

Die StorageClass lässt sich dann mit dem folgenden Befehl erstellen und auch aktualisieren:

kubectl apply -f storageclass-azuredisk.yaml

Um sicherzustellen, dass die StorageClass richtig angelegt ist, kann der Admin diese mit diesem Befehl auflisten:

kubectl get sc

Hier werden verschiedene Informationen angezeigt, darunter der Name, der Provisioner (Treiber), die Reclaim Policy (Löschverhalten) und das Alter der StorageClass.

In neueren AKS-Versionen existieren oft vorinstallierte StorageClasses wie managed-csi und managed-csi-premium, die automatisch den Azure Disk CSI-Treiber einsetzen.

Schritt 3: PersistentVolumeClaim (PVC) anlegen

Mit der StorageClass kann man nun eine PVC erstellen, die automatisch eine Managed Disk provisioniert. Dies wird hiermit umgesetzt:

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

kubectl apply -f pvc-azuredisk.yaml

Sobald ein Pod diese PVC verwendet, erstellt der CSI-Treiber eine Azure Managed Disk im Hintergrund und verbindet sie mit der Node, auf dem der Pod läuft. Der PVC-Status sollte danach Bound sein.

Hier gibt es zudem weitere Parameter zu beachten. So unterstützen Azure Disks nur ReadWriteOnce, also nur eine Node zur gleichen Zeit. Mehrere Pods auf derselben Node können denselben PVC verwenden, solange sie auf dieser Node zusammen ausgeführt werden.

Der Admin muss wissen, dass die erzeugte Disk ist in der Azure-Resource-Gruppe sichtbar ist, meist in der Node Resource Group von AKS. Es ist auch möglich, statisch existierende Disks als PVs zu referenzieren, das ist aber ein Spezialfall, der mehr manuelle Konfiguration erfordert.

Schritt 4: Funktion prüfen und Verwendungen testen

Nach dem Erstellen der PVC und der StorageClass kann der Administrator die Funktionsfähigkeit testen. Dafür prüfen Sie zuerst, ob der CSI-Treiber wie erwartet funktioniert beziehungsweise aktiviert ist, ebenso die Node- und Controller-Komponenten. Das erfolgt mittels:

kubectl get pods -n kube-system | grep azure

Der Admin sollte die Pods als azure-disk-csi-node und azure-disk-csi-controller angezeigt sehen. Die StorageClass wird mit kubectl get storageclass aufgelistet und mit kubectl get pvc wird der Status abgerufen, der als Bound angegeben sein sollte. In der Azure-Portal-Oberfläche sollte die neu erstellte Disk unter Disks sichtbar sein

Im sicherzustellen, dass alles wie gewünscht operiert, kann der Administrator einen Test-Pod mit Mount bereitstellen. Dafür gibt er folgendes ein:

apiVersion: v1
kind: Pod
metadata:
  name: disk-test-pod
spec:
  containers:
  - name: test-container
    image: ubuntu
    command: ["sleep", "3600"]
    volumeMounts:
    - name: test-volume
      mountPath: /data
  volumes:
  - name: test-volume
    persistentVolumeClaim:
      claimName: azure-disk-pvc

Dann kann er mit kubectl exec prüfen, ob Schreib-/Leseoperationen im Pfad /data funktionieren. Als Erweiterung kann man Snapshot- oder Cloning-Funktionen testen.

Besonderheiten, technische Details und Tipps

Die Nutzung des Azure Disk CSI-Treibers bietet weit mehr als nur die grundlegende Bereitstellung von Storage. Um die volle Leistung und Zuverlässigkeit zu erreichen, sollten Sie einige wichtige Funktionen und Besonderheiten kennen.

Snapshot, Restore, Cloning

Für effiziente Backup-Strategien und die Replikation von Daten ist die Unterstützung von Snapshots und dem Klonen von Volumes durch den Azure Disk CSI-Treiber unverzichtbar. Diese Funktionen erlauben Point-in-Time-Sicherungen Ihrer Persistent Volumes und die darauffolgende Wiederherstellung oder das Erstellen identischer Kopien, sofern dies von Azure unterstützt wird.

Volume Expansion

Die Anforderung an Speicherplatz wächst oft mit der Zeit. Glücklicherweise unterstützt der CSI-Treiber die Erweiterung von Volumes, auch online, ohne dass die Anwendung neu gestartet werden muss. Voraussetzung ist, dass dies sowohl von der eingesetzten Kubernetes-Version als auch der Treiberversion unterstützt wird.

Skalierbarkeit und Limits: Maximale Disks pro VM-SKU

Bei der Planung der Workloads ist es essenziell, die Grenzen der zugrunde liegenden VM-SKUs zu beachten. Jede VM-Klasse hat ein striktes Limit, wie viele Datenträger sie anbinden kann. Wenn Sie planen, viele PVCs (Persistent Volume Claims) pro Node zu erstellen, müssen Sie diese Limits im Voraus prüfen, um unliebsame Überraschungen zu vermeiden.

Topologie und Zonenbewusstsein

Azure Disks sind zonengebunden. Das bedeutet, ein Pod kann nur auf eine Disk zugreifen, die sich in derselben Verfügbarkeitszone befindet. Der WaitForFirstConsumer-Modus ist hier der Schlüssel: Er verzögert die Erstellung der Disk, bis ein Pod den PVC beansprucht, und wählt dann automatisch die Zone des Pods aus. So wird verhindert, dass eine Disk in einer Zone erstellt wird, in der kein Pod sie nutzen kann. Zusätzlich unterstützt der Treiber in verfügbaren Regionen auch zonenredundante Storage-Klassen (ZRS) für erhöhte Ausfallsicherheit.

Alternative Speicherlösungen: Azure Files und Blob Storage

Nicht jeder Anwendungsfall ist für blockbasierte Disks geeignet. Für andere Szenarien bietet Azure zwei weitere CSI-Treiber.

Azure Files CSI-Treiber für geteilte Volumes

Wenn Sie Dateifreigaben benötigen, die von mehreren Pods gleichzeitig gemountet werden können (ReadWriteMany), ist der Azure Files CSI-Treiber die richtige Wahl. Dieser verwendet den Provisioner file.csi.azure.com und kann sowohl SMB- als auch NFS-Protokolle nutzen. Für einen schnellen Start stehen integrierte StorageClasses wie azurefile-csi (Standard) und azurefile-csi-premium zur Verfügung.

Azure Blob CSI-Treiber für unstrukturierte Daten

Für spezielle Szenarien mit großen Mengen unstrukturierter Daten, wie Logs oder Backups, kann die direkte Einbindung von Blob Storage sinnvoll sein. Der Blob-CSI-Treiber macht dies möglich, indem er entweder Blobfuse oder das NFSv3-Protokoll unterstützt. Hierfür gibt es entsprechende StorageClasses, zum Beispiel azureblob-fuse-premium. Beachten Sie jedoch, dass das Verkleinern (Shrinking) von Volumes derzeit nicht unterstützt wird.

Darüber hinaus sollen weitere wichtige strategische Überlegungen in den Prozess einfließen, darunter unter anderem die folgenden.

Migration von In-Tree zu CSI

Falls Sie noch ältere Kubernetes-Cluster mit den traditionellen In-Tree-Azure-Treibern (erkennbar an kubernetes.io/azure-disk) betreiben, ist eine Migration zum CSI-Treiber dringend zu empfehlen. Zukünftige AKS-Versionen werden die alten Treiber nicht mehr vollständig unterstützen.

Managed vs. Manuelle Treiber

Aus Betriebssicht ist die Nutzung der von AKS verwalteten CSI-Treiber der manuellen Installation aus GitHub vorzuziehen. Microsoft aktualisiert und unterstützt diese verwalteten Treiber automatisch, was den Wartungsaufwand reduziert und die Stabilität erhöht.

Performance und Kosten im Blick behalten

Zuletzt sollten Performance und Kosten nicht vernachlässigt werden. Parameter wie der cachingmode, die Netzwerklatenz und die Wahl zwischen Standard- oder Premium-Speicherklassen (inklusive ZRS) haben direkten Einfluss auf die Anwendungsleistung. Gleichzeitig verursachen nicht nur die reinen Speicherkosten von Managed Disks und Azure Files Ausgaben, sondern auch Snapshots, IOPS und die reservierte Speichergröße. Eine durchdachte Lifecycle-Strategie, die nicht mehr benötigte Volumes und Snapshots zeitnah löscht, ist essenziell für die Kosteneffizienz.

Troubleshooting

Trotz der Integration der CSI-Treiber in AKS kann es in der Praxis zu Fehlern bei Provisionierung, Mounting oder Bindung von Volumes kommen. Nachfolgend listen wir die häufigsten Ursachen und deren Lösungsmöglichkeiten auf und geben praktische YAML-Beispiele.

PVC bleibt im Status Pending

Die Ursache für einen PVC, der im Status Pending bleibt ist, dass der Pod, der das Volume benötigt, noch nicht geplant wurde, und die StorageClass das WaitForFirstConsumer nutzt. Um dies zu beheben, muss der Admin einen Pod erstellen, der den PVC verwendet. Danach wird das Volume provisioniert. Daraufhin kann dies wie folgt überprüft werden:

kubectl describe pvc <PVC_NAME>

Dort steht meist der Grund im Event-Abschnitt, beispielsweise waiting for first consumer.

PVC- oder Volume-Erstellung schlägt fehl

Hierbei erhält der Admin die Fehlermeldung could not create volume. Die Ursache sind fehlende IAM-/RBAC-Berechtigungen oder API-Zugriff des Managed Identity des AKS-Clusters. Zunächst müssen Sie prüfen, ob der Cluster über eine System- oder Benutzeridentität verfügt (az aks show --query identity). Danach muss sichergestellt sein, dass diese Identität im Azure-Ressourcenbereich Contributor- oder Disk Contributor-Rollenrechte besitzt. Alternativ kann der IT-Verantwortliche die Berechtigung gezielt auf die Resource Group beschränken, in der die Disks erzeugt werden.

Volume wird nicht gemountet

In diesem Fall verbleibt der Pod im Status ContainerCreating. Der Grund hierfür ist, dass die Node das Volume nicht anhängen kann, beispielsweise wegen eines Zonen-Mismatch oder zu vieler Disks pro virtueller Maschine (VM). Im ersten Schritt muss der Pod kontrolliert werden:

kubectl describe pod <POD_NAME>

Die hier aufgelisteten Events enthalten Meldungen wie AttachVolume.Attach failed for volume. Nun prüft der Admin, ob Node und Disk in der gleichen Verfügbarkeitszone (Availability Zone) liegen:

az disk show -n <DISK_NAME> --resource-group <RG> --query zones
az vm show -n <NODE_VM> --query zones

Wenn unterschiedliche Zonen vorhanden sind, muss die StorageClass auf WaitForFirstConsumer gesetzt werden oder der Admin gibt die Zonen explizit an.

Volume Expansion schlägt fehl

Für dieses Problem können verschiedene Gründe verantwortlich sein. Entweder erlaubt die StorageClass keine Erweiterung (allowVolumeExpansion: false) oder der PVC wird von einem alten In-Tree-Treiber verwaltet. Das heißt, dass die StorageClass überprüft werden muss:

kubectl get sc <SC_NAME> -o yaml

Wenn nötig, muss der Anwender den PVC löschen und mit CSI-StorageClass neu erstellen. Allgemein sollte sichergestellt werden, dass das AKS-Cluster auf Kubernetes 1.23 und jünger läuft, da diese Versionen weitaus stabiler sind.

Permission denied bei Azure Files Mount

Wird bei Azure Files Mount die Erlaubnis verweigert, kann es sein, dass der SMB-/NFS-Mount Point nicht korrekt ist oder die Secrets für Azure Storage Account fehlen. In diesem Fall prüfen Sie Secret mit Storage-Account-Name und Key:

kubectl get secret azure-storage-secret -o yaml

Die StorageClass muss secretName korrekt referenzieren.

Bei NFS-Freigaben muss der Administrator prüfen, dass die AKS-Nodes in derselben VNet-Region und Subnet liegen wie die File-Share-Ressource.

Fehler beim Snapshot und Restore

In diesem Fall ist häufig der Snapshot-Controller nicht installiert oder CRDs nicht vorhanden. Dies lässt sich mit folgendem Befehl kontrollieren:

kubectl get crd | grep snapshot

Falls hier kein Ergebnis angezeigt wird, muss in der Regel der Snapshot-Controller nachinstalliert oder mit --enable-csi-snapshot-controller im AKS-Cluster aktiviert werden, was je nach Version unterschiedlich sein kann.

Praktische YAML-Beispiele

Im Folgenden einige vollständige Manifeste für gängige Anwendungsfälle bei der Installation.

StorageClass für Premium Managed Disks

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

PersistentVolumeClaim für Azure Disk

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

Test-Pod mit Disk-Mount

apiVersion: v1
kind: Pod
metadata:
  name: disk-test-pod
spec:
  containers:
  - name: test-container
    image: ubuntu
    command: ["sleep", "3600"]
    volumeMounts:
    - name: azure-disk
      mountPath: /mnt/data
  volumes:
  - name: azure-disk
    persistentVolumeClaim:
      claimName: azure-disk-pvc

Azure Files mit Secret (SMB-Freigabe)

apiVersion: v1
kind: Secret
metadata:
  name: azure-storage-secret
type: Opaque
stringData:
  azurestorageaccountname: <STORAGE_ACCOUNT_NAME>
  azurestorageaccountkey: <STORAGE_ACCOUNT_KEY>
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi
provisioner: file.csi.azure.com
parameters:
  skuName: Premium_LRS
  protocol: smb
  secretName: azure-storage-secret
reclaimPolicy: Delete
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azurefile-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi
  resources:
    requests:
      storage: 100Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: azurefile-test
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: azurefile-vol
      mountPath: /usr/share/nginx/html
  volumes:
  - name: azurefile-vol
    persistentVolumeClaim:
      claimName: azurefile-pvc

Snapshot eines Azure Disk PVC

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-snapshot-class
driver: disk.csi.azure.com
deletionPolicy: Delete
---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: disk-snapshot
spec:
  volumeSnapshotClassName: csi-snapshot-class
  source:
    persistentVolumeClaimName: azure-disk-pvc

Ob der Snapshot erfolgreich eingerichtet wurde, lässt sich einfach überprüfen:

kubectl get volumesnapshot

Wiederherstellung aus Snapshot

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-disk-pvc
spec:
  dataSource:
    name: disk-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 20Gi

Azure Blob CSI mit Blobfuse2

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azureblob-fuse2
provisioner: blob.csi.azure.com
parameters:
  skuName: Premium_LRS
  containerName: kube-blobs
  protocol: fuse2
reclaimPolicy: Delete
allowVolumeExpansion: false
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azureblob-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azureblob-fuse2
  resources:
    requests:
      storage: 50Gi

Hier ist die Voraussetzung, dass der Blob-CSI-Treiber im AKS-Cluster aktiviert und der Storage Account vorhanden ist.