Verwendung von CSI-Datenträgertreibern (Container Storage Interface) in AKS, aktiviert durch Azure Arc.

Gilt für: AKS auf Azure Local

In diesem Artikel wird beschrieben, wie Sie integrierte CSI-Speicherklassen (Container Storage Interface) verwenden, um datenträgerbeständige Volumes dynamisch zu erstellen und benutzerdefinierte Speicherklassen in AKS zu erstellen, die von Arc aktiviert sind.

Eine Übersicht der CSI in AKS, ermöglicht durch Arc

Container Storage Interface (CSI) ist ein Standard für die Bereitstellung beliebiger Block- und Dateispeichersysteme für containerisierte Workloads in Kubernetes. Durch die Verwendung von CSI kann AKS, das durch Arc aktiviert ist, Plug-ins schreiben, bereitstellen und iterieren, um neue Speichersysteme verfügbar zu machen. CSI kann auch vorhandene Komponenten in Kubernetes verbessern, ohne den Kubernetes-Kerncode berühren zu müssen und auf die Veröffentlichungszyklen zu warten.

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

Mit der Unterstützung des CSI-Speichertreibers auf AKS Arc können Sie Folgendes verwenden:

• 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, mit denen Sie eine SMB- oder NFS-Freigabe in Pods einbinden können. Diese werden als ReadWriteMany eingebunden, sodass Sie Daten über mehrere Knoten und Pods hinweg teilen 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 mit integrierter 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 verwendet die Standardspeicherklasse CSI, um VHDX-gesicherte Volumes zu erstellen. 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 verwenden, erstellen Sie einen Persistent Volume Claim (PVC) and a respective pod that references and uses it. Ein PVC wird verwendet, um die Lagerung basierend auf einer Speicherklasse automatisch 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 definiertem fsType 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 angeben, an dem PVs gespeichert werden sollen. Wenn die zugrunde liegende Infrastruktur Azure Local ist, könnte dieser neue Speicherort ein Volume sein, das von leistungsstarken SSDs/NVMe unterstützt wird, oder ein kostenoptimiertes Volume, das von HDDs unterstützt wird.

Das Erstellen einer benutzerdefinierte Speicherklasse umfasst zwei Schritte:

1. Erstellen Sie einen neuen Speicherpfad mithilfe der stack-hci-vm storagepath Cmdlets zum Erstellen, Anzeigen und Auflisten der Speicherpfade in Ihrem lokalen Azure-Cluster. Weitere Informationen zur Erstellung von Speicherpfaden finden Sie unter "Speicherpfad".

   Erstellen Sie für $path einen Speicherpfad mit dem Namen $storagepathname; zum Beispiel C:\ClusterStorage\test-storagepath:

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

   Holen Sie sich die Ressourcen-ID des Speicherpfads.

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

2. Erstellen Sie eine neue benutzerdefinierte Speicherklasse mit dem neuen Speicherpfad.

   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 das im vorherigen Schritt erstellte storage path ID für container. Für group und hostname können Sie die Standardspeicherklasse abfragen, indem Sie kubectl get storageclass default -o yaml ausführen, und anschließend die angegebenen Werte verwenden:

      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

Verwenden der Dateitreiber für die Containerspeicherschnittstelle