Share via

Verwenden von CSI-Datenträgertreibern (Container Storage Interface) in AKS, die von Azure Arc aktiviert sind

  • Artikel

> Gilt für: AKS in Azure Stack HCI 22H2, AKS unter Windows Server, AKS in Azure Stack HCI 23H2

In diesem Artikel wird beschrieben, wie Sie die integrierten Speicherklassen von Container Storage Interface (CSI) verwenden, um persistente Datenträgervolumes dynamisch zu erstellen und benutzerdefinierte Speicherklassen in AKS zu erstellen, die von Arc aktiviert sind.

Übersicht über CSI in AKS, die von Arc aktiviert ist

Container Storage Interface (CSI) ist ein Standard für die Bereitstellung beliebiger Block- und Dateispeichersysteme für containerisierte Workloads in Kubernetes. Mithilfe von CSI können von Arc aktivierte AKS Plug-Ins schreiben, bereitstellen und durchlaufen, um neue Speichersysteme verfügbar zu machen. Durch die Verwendung von CSI können außerdem vorhandene Speichersysteme in Kubernetes verbessert werden, ohne den Hauptcode von Kubernetes zu ändern und dann die Releasezyklen abwarten zu müssen.

Die von AKS Arc verwendeten Datenträger- und Datei-CSI-Treiber sind CSI-spezifikationskonforme Treiber.

Die CSI-Speichertreiberunterstützung in AKS Arc ermöglicht Folgendes:

  • AKS Arc-Datenträger, die Sie zum Erstellen einer Kubernetes DataDisk-Ressource verwenden können. Diese werden als ReadWriteOnce eingebunden. Sie sind somit nur für jeweils einen einzelnen Pod verfügbar. Verwenden Sie für Speichervolumes, auf die von mehreren Pods gleichzeitig zugegriffen werden kann, AKS Arc-Dateien.

  • AKS Arc-Dateien, die Sie verwenden können, um eine SMB- oder NFS-Freigabe in Pods einzubinden. Diese werden als ReadWriteManyeingebunden, sodass Sie Daten über mehrere Knoten und Pods hinweg freigeben können. Sie können basierend auf der PVC-Spezifikation (Persistent Volume Claim, Anspruch auf ein persistente Volume) auch als ReadWriteOnce eingebunden werden.

Dynamisches Erstellen persistenter Datenträgervolumes mithilfe der integrierten Speicherklasse

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

In AKS Arc wird die Standardspeicherklasse standardmäßig erstellt und verwendet CSI zum Erstellen von VHDX-gestützten Volumes. Mit der Freigaberichtlinie wird sichergestellt, dass das zugrunde liegende VHDX gelöscht wird, wenn das persistente Volume gelöscht wird, das es verwendet hat. Mit der Speicherklasse werden auch die persistenten Volumes so konfiguriert, dass sie erweiterbar sind. Sie müssen lediglich den Anspruch auf ein persistentes Volume entsprechend der neuen Größe anpassen.

Um diese Speicherklasse zu nutzen, erstellen Sie ein PVC und einen entsprechenden Pod, der darauf verweist und 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 ein VHDX der gewünschten Größe zu erstellen. Wenn Sie eine Poddefinition erstellen, wird der Anspruch auf ein persistentes Volume angegeben, um den gewünschten Speicher anzufordern.

Erstellen einer benutzerdefinierten Speicherklasse für Datenträger

Die Standardspeicherklasse eignet sich für die meisten gängigen Szenarien. In einigen Fällen bevorzugen Sie jedoch möglicherweise die Erstellung einer eigenen Speicherklasse, die PVs an einem bestimmten Speicherort speichert, der einer bestimmten Leistungsstufe zugeordnet ist.

Wenn Sie über Linux-Workloads (Pods) verfügen, müssen Sie eine benutzerdefinierte Speicherklasse mit dem Parameter fsType: ext4 erstellen. Diese Anforderung gilt für Kubernetes-Versionen 1.19 und 1.20 oder höher. Das folgende Beispiel zeigt eine benutzerdefinierte Speicherklassendefinition mit fsType definiertem Parameter:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: aks-hci-disk-custom
parameters:
  blocksize: "33554432"
  container: SqlStorageContainer
  dynamic: "true"
  group: clustergroup-summertime
  hostname: TESTPATCHING-91.sys-sqlsvr.local
  logicalsectorsize: "4096"
  physicalsectorsize: "4096"
  port: "55000"
  fsType: ext4
provisioner: disk.csi.akshci.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

Wenn Sie eine benutzerdefinierte Speicherklasse erstellen, können Sie den Speicherort für PVs angeben. Wenn die zugrunde liegende Infrastruktur Azure Stack HCI ist, kann es sich bei diesem neuen Speicherort um ein Volume handeln, das von leistungsstarken SSDs/NVMe oder einem kostenoptimierten Volume mit HDDs unterstützt wird.

Das Erstellen einer benutzerdefinierte Speicherklasse umfasst zwei Schritte:

  1. Erstellen Sie mithilfe der stack-hci-vm storagepath Cmdlets einen neuen Speicherpfad, um die Speicherpfade in Ihrem Azure Stack HCI-Cluster zu erstellen, anzuzeigen und auflisten zu können. Weitere Informationen zur Erstellung des Speicherpfads finden Sie unter Speicherpfad.

    Erstellen Sie für $patheinen Speicherpfad namens $storagepathname, z. B. C:\ClusterStorage\test-storagepath:

    az stack-hci-vm storagepath create --resource-group $resource_group --custom-location $customLocationID --name $storagepathname --path $path

    Rufen Sie die Ressourcen-ID des Speicherpfads ab:

    $storagepathID = az stack-hci-vm storagepath show --name $storagepathname --resource-group $resource_group --query "id" -o tsv

  2. Erstellen Sie mithilfe des neuen Speicherpfads eine neue benutzerdefinierte Speicherklasse.

    1. Erstellen Sie eine Datei mit dem Namen sc-aks-hci-disk-custom.yaml, und kopieren Sie dann das Manifest aus der folgenden YAML-Datei. Die Speicherklasse ist mit der Standardspeicherklasse abgesehen vom neuen container identisch. Verwenden Sie die storage path ID im vorherigen Schritt erstellte für container. Fragen Sie für group und hostnamedie Standardspeicherklasse ab, indem Sie ausführen kubectl get storageclass default -o yaml, und verwenden Sie dann die angegebenen Werte:

      kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: aks-hci-disk-custom
provisioner: disk.csi.akshci.com
parameters:
 blocksize: "33554432"
 container: <storage path ID>
 dynamic: "true"
 group: <e.g clustergroup-akshci> # same as the default storageclass
 hostname: <e.g. ca-a858c18c.ntprod.contoso.com> # same as the default storageclass
 logicalsectorsize: "4096"
 physicalsectorsize: "4096"
 port: "55000"
 fsType: ext4 # refer to the note above to determine when to include this parameter
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate

    2. Erstellen Sie die Speicherklasse mit dem Befehl kubectl apply , und geben Sie die Datei sc-aks-hci-disk-custom.yaml an:

       $ kubectl apply -f sc-aks-hci-disk-custom.yaml
 storageclass.storage.k8s.io/aks-hci-disk-custom created

Nächste Schritte