Share via

Använda CSI-diskdrivrutiner (Container Storage Interface) i AKS som aktiveras av Azure Arc

  • Artikel

> Gäller för: AKS på Azure Stack HCI 22H2, AKS på Windows Server, AKS på Azure Stack HCI 23H2

Den här artikeln beskriver hur du använder inbyggda CSI-lagringsklasser (Container Storage Interface) för att dynamiskt skapa diskbeständiga volymer och skapa anpassade lagringsklasser i AKS som aktiveras av Arc.

Översikt över CSI i AKS aktiverat av Arc

CSI (Container Storage Interface) är en standard för att exponera godtyckliga block- och fillagringssystem för containerbaserade arbetsbelastningar på Kubernetes. Med hjälp av CSI kan AKS som aktiveras av Arc skriva, distribuera och iterera plugin-program för att exponera nya lagringssystem. CSI kan också förbättra befintliga i Kubernetes utan att behöva röra kubernetes-kärnkoden och sedan vänta på dess lanseringscykler.

De CSI-drivrutiner för diskar och filer som används av AKS Arc är CSI-kompatibla drivrutiner.

Med stöd för CSI-lagringsdrivrutinen på AKS Arc kan du använda:

  • AKS Arc-diskar som du kan använda för att skapa en Kubernetes DataDisk-resurs . De monteras som ReadWriteOnce, så de är bara tillgängliga för en enda podd i taget. För lagringsvolymer som kan nås av flera poddar samtidigt använder du AKS Arc-filer.

  • AKS Arc-filer som du kan använda för att montera en SMB- eller NFS-resurs till poddar. Dessa monteras som ReadWriteMany, så du kan dela data över flera noder och poddar. De kan också monteras som ReadWriteOnce baserat på PVC-specifikationen (beständigt volymanspråk).

Skapa permanent diskvolym dynamiskt med inbyggd lagringsklass

En lagringsklass används för att definiera hur en lagringsenhet skapas dynamiskt med en beständig volym. Mer information om hur du använder lagringsklasser finns i Kubernetes-lagringsklasser.

I AKS Arc skapas standardlagringsklassen som standard och använder CSI för att skapa VHDX-baserade volymer. Återtagandeprincipen säkerställer att den underliggande VHDX tas bort när den beständiga volymen som använde den tas bort. Lagringsklassen konfigurerar också beständiga volymer så att de kan expanderas. du behöver bara redigera det beständiga volymanspråket med den nya storleken.

Om du vill använda den här lagringsklassen skapar du en PVC och en respektive podd som refererar till och använder den. En PVC används för att automatiskt etablera lagring baserat på en lagringsklass. En PVC kan använda någon av de förskapade lagringsklasserna eller en användardefinierad lagringsklass för att skapa en VHDX med önskad storlek. När du skapar en podddefinition anges PVC:en för att begära önskad lagring.

Skapa anpassad lagringsklass för diskar

Standardlagringsklassen är lämplig för de vanligaste scenarierna. Men i vissa fall kanske du vill skapa en egen lagringsklass som lagrar PV:er på en viss plats som är mappad till en specifik prestandanivå.

Om du har Linux-arbetsbelastningar (poddar) måste du skapa en anpassad lagringsklass med parametern fsType: ext4. Det här kravet gäller för Kubernetes version 1.19 och 1.20 eller senare. I följande exempel visas en anpassad definition för lagringsklassen med fsType en definierad 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

Om du skapar en anpassad lagringsklass kan du ange den plats där du vill lagra PV:er. Om den underliggande infrastrukturen är Azure Stack HCI kan den här nya platsen vara en volym som backas upp av högpresterande SSD:n/NVMe eller en kostnadsoptimerad volym som backas upp av hårddiskar.

Att skapa en anpassad lagringsklass är en tvåstegsprocess:

  1. Skapa en ny lagringssökväg med hjälp av stack-hci-vm storagepath cmdletarna för att skapa, visa och lista lagringssökvägarna i ditt Azure Stack HCI-kluster. Mer information om hur du skapar lagringssökväg finns i Lagringssökväg.

    För $pathskapar du en lagringssökväg med namnet $storagepathname, till exempel C:\ClusterStorage\test-storagepath:

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

    Hämta resurs-ID:t för lagringssökvägen:

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

  2. Skapa en ny anpassad lagringsklass med hjälp av den nya lagringssökvägen.

    1. Skapa en fil med namnet sc-aks-hci-disk-custom.yaml och kopiera sedan manifestet från följande YAML-fil. Lagringsklassen är samma som standardlagringsklassen förutom med den nya container. Använd som storage path ID skapades i föregående steg för container. För group och hostnamefrågar du standardlagringsklassen genom att köra kubectl get storageclass default -o yamloch sedan använda de angivna värdena:

      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. Skapa lagringsklassen med kommandot kubectl apply och ange filen sc-aks-hci-disk-custom.yaml :

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

Nästa steg