Dela via

Använda CSI-drivrutinen (Azure Disk Container Storage Interface) i Azure Kubernetes Service (AKS)

  • Artikel

CSI-drivrutinen (Azure Disks Container Storage Interface) är en CSI-kompatibel drivrutin som används av Azure Kubernetes Service (AKS) för att hantera livscykeln för Azure Disk.

CSI är en standard för att exponera godtyckliga block- och fillagringssystem för containerbaserade arbetsbelastningar på Kubernetes. Genom att implementera och använda CSI kan AKS nu skriva, distribuera och iterera plugin-program för att exponera nya eller förbättra befintliga lagringssystem i Kubernetes. Att använda CSI-drivrutiner i AKS undviker att behöva röra kubernetes-kärnkoden och vänta på dess lanseringscykler.

Information om hur du skapar ett AKS-kluster med stöd för CSI-drivrutin finns i Aktivera CSI-drivrutin på AKS. Den här artikeln beskriver hur du använder Azure Disk CSI-drivrutinen version 1.

Kommentar

Azure Disk CSI-drivrutinen v2 (förhandsversion) förbättrar skalbarheten och minskar svarstiden för poddredundans. Den använder delade diskar för att etablera repliker för bifogade filer på flera klusternoder och integreras med poddschemaläggaren för att säkerställa att en nod med en replik för bifogade filer väljs vid poddredundans. Azure Disk CSI driver v2 (förhandsversion) ger också möjlighet att finjustera prestanda. Om du är intresserad av att delta i förhandsversionen skickar du en begäran: https://aka.ms/DiskCSIv2Preview. Den här förhandsversionen tillhandahålls utan ett serviceavtal och du kan ibland förvänta dig icke-bakåtkompatibla ändringar i förhandsversionen. Förhandsversionen rekommenderas inte för produktionsarbetsbelastningar. Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.

Kommentar

In-tree-drivrutiner refererar till de aktuella lagringsdrivrutinerna som ingår i kubernetes-kärnkoden jämfört med de nya CSI-drivrutinerna, som är plugin-program.

Funktioner för Azure Disk CSI-drivrutin

Förutom drivrutinsfunktioner i träd har Azure Disk CSI-drivrutinen stöd för följande funktioner:

  • Prestandaförbättringar vid samtidig diskanslutning och frånkoppling
    • In-tree-drivrutiner ansluter eller kopplar från diskar i seriellt, medan CSI-drivrutiner ansluter eller kopplar från diskar i batch. Det finns betydande förbättringar när det finns flera diskar som ansluter till en nod.
  • Premium SSD v1 och v2 stöds.
    • PremiumV2_LRS stöder None endast cachelagringsläge
  • Stöd för zonredundant lagring (ZRS)
    • Premium_ZRSstöds StandardSSD_ZRS disktyper. ZRS-disken kan schemaläggas på noden zon eller icke-zon, utan begränsningen att diskvolymen ska finnas i samma zon som en viss nod. Mer information, inklusive vilka regioner som stöds, finns i Zonredundant lagring för hanterade diskar.
  • Ögonblicksbild
  • Volymkloning
  • Ändra storlek på disk-PV utan stilleståndstid

Kommentar

Beroende på vilken VM SKU som används kan Azure Disk CSI-drivrutinen ha en volymgräns per nod. För vissa kraftfulla virtuella datorer (till exempel 16 kärnor) är gränsen 64 volymer per nod. Om du vill identifiera gränsen per VM SKU läser du kolumnen Max datadiskar för varje VM SKU som erbjuds. En lista över vm-SKU:er som erbjuds och deras motsvarande detaljerade kapacitetsgränser finns i Storlekar på virtuella datorer för generell användning.

Använda CSI-beständiga volymer med Azure Disks

En beständig volym (PV) representerar en lagringsdel som har etablerats för användning med Kubernetes-poddar. En PV kan användas av en eller flera poddar och kan etableras dynamiskt eller statiskt. Den här artikeln visar hur du dynamiskt skapar PV:er med Azure-disk för användning av en enda podd i ett AKS-kluster. För statisk etablering, se Skapa en statisk volym med Azure Disks.

Mer information om Kubernetes-volymer finns i Lagringsalternativ för program i AKS.

Skapa Azure Disks-PV:er dynamiskt med hjälp av de inbyggda lagringsklasserna

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

När du använder Azure Disk CSI-drivrutinen i AKS finns det ytterligare två inbyggda StorageClasses som använder Azure Disk CSI-lagringsdrivrutinen. De andra CSI-lagringsklasserna skapas med klustret tillsammans med standardlagringsklasserna i trädet.

  • managed-csi: Använder Azure Standard SSD lokalt redundant lagring (LRS) för att skapa en hanterad disk. Från och med Kubernetes version 1.29, i AKS-kluster (Azure Kubernetes Service) som distribuerats över flera tillgänglighetszoner, använder den här lagringsklassen Azure Standard SSD zone-redundant lagring (ZRS) för att skapa hanterade diskar.
  • managed-csi-premium: Använder Azure Premium LRS för att skapa en hanterad disk. Från och med Kubernetes version 1.29, i AKS-kluster (Azure Kubernetes Service) som distribuerats i flera tillgänglighetszoner, använder den här lagringsklassen Azure Premium zonredundant lagring (ZRS) för att skapa hanterade diskar.

Återtagandeprincipen i båda lagringsklasserna säkerställer att de underliggande Azure-diskarna tas bort när respektive PV tas bort. Lagringsklasserna konfigurerar också att PV:erna ska vara utökningsbara. Du behöver bara redigera det beständiga volymanspråket (PVC) med den nya storleken.

Om du vill använda dessa lagringsklasser skapar du en PVC och respektive podd som refererar till och använder dem. En PVC används för att automatiskt etablera lagring baserat på en lagringsklass. En PVC kan använda en av de förskapade lagringsklasserna eller en användardefinierad lagringsklass för att skapa en Azure-hanterad disk för önskad SKU och storlek. När du skapar en podddefinition anges PVC för att begära önskad lagring.

Skapa en exempelpodd och respektive PVC genom att köra kommandot 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

Kommandots utdata liknar följande exempel:

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

När podden är i körningstillståndet kör du följande kommando för att skapa en ny fil med namnet test.txt.

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

Kontrollera att disken är korrekt monterad genom att köra följande kommando och kontrollera att du ser test.txt filen i utdata:

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

lost+found
outfile
test.txt

Skapa en anpassad lagringsklass

Standardlagringsklasserna är lämpliga för de vanligaste scenarierna. I vissa fall kanske du vill att din egen lagringsklass ska anpassas med dina egna parametrar. Du kanske till exempel vill ändra volumeBindingMode klassen.

Du kan använda en volumeBindingMode: Immediate klass som garanterar att den inträffar omedelbart när PVC:en har skapats. När nodpoolerna är topologibegränsade, till exempel när du använder tillgänglighetszoner, skulle PV:er bindas eller etableras utan kunskap om poddens schemaläggningskrav.

För att hantera det här scenariot kan du använda volumeBindingMode: WaitForFirstConsumer, vilket fördröjer bindningen och etableringen av en PV tills en podd som använder PVC har skapats. På så sätt överensstämmer PV:en och etableras i tillgänglighetszonen (eller annan topologi) som anges av poddens schemaläggningsbegränsningar. Standardlagringsklasserna använder volumeBindingMode: WaitForFirstConsumer klass.

Skapa en fil med namnet sc-azuredisk-csi-waitforfirstconsumer.yamloch klistra sedan in följande manifest. Lagringsklassen är samma som vår managed-csi lagringsklass, men med en annan volumeBindingMode klass.

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

Skapa lagringsklassen genom att köra kommandot kubectl apply och ange filen sc-azuredisk-csi-waitforfirstconsumer.yaml :

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

Kommandots utdata liknar följande exempel:

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

Ögonblicksbilder av volymer

Azure Disk CSI-drivrutinen har stöd för att skapa ögonblicksbilder av beständiga volymer. Som en del av den här funktionen kan drivrutinen utföra antingen fullständiga eller inkrementella ögonblicksbilder beroende på värdet som anges i parametern incremental (som standard är det sant).

Följande tabell innehåller information om alla parametrar.

Name Innebörd Tillgängligt värde Obligatorisk Default value
resourceGroup Resursgrupp för lagring av ögonblicksbildbilder BEFINTLIG RESURSGRUPP Nej Om den inte anges lagras ögonblicksbilden i samma resursgrupp som Azure-källdiskar
Inkrementell Ta fullständig eller inkrementell ögonblicksbild true, false Nej true
taggar Azure Disks-taggar Taggformat: 'key1=val1,key2=val2' Nej ""
userAgent Användaragent som används för kundanvändningsatribution Nej Genererad useragent formaterad driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Ange azure-prenumerations-ID där Azure Disks ska skapas Azure-prenumerations-ID Nej Om den inte är tom resourceGroup måste den anges incremental som false

Skapa en ögonblicksbild av volymen

Kommentar

Kontrollera att programmet inte skriver data till källdisken innan du fortsätter.

Ett exempel på den här funktionen är att skapa en volymögonblicksbildklass med kommandot kubectl apply :

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

Kommandots utdata liknar följande exempel:

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

Nu ska vi skapa en ögonblicksbild av volymen från PVC:en som vi skapade dynamiskt i början av den här självstudien. pvc-azuredisk

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

Kommandots utdata liknar följande exempel:

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

Kontrollera att ögonblicksbilden har skapats korrekt genom att köra följande kommando:

kubectl describe volumesnapshot azuredisk-volume-snapshot

Kommandots utdata liknar följande exempel:

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>

Skapa en ny PVC baserat på en ögonblicksbild av volymen

Du kan skapa en ny PVC baserat på en ögonblicksbild av volymen. Använd ögonblicksbilden som skapades i föregående steg och skapa en ny PVC och en ny podd för att använda den.

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

Kommandots utdata liknar följande exempel:

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

Slutligen ska vi se till att det är samma PVC som skapats tidigare genom att kontrollera innehållet genom att köra följande kommando:

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

Kommandots utdata liknar följande exempel:

lost+found
outfile
test.txt

Som förväntat kan vi fortfarande se vår tidigare skapade test.txt fil.

Klona volymer

En klonad volym definieras som en dubblett av en befintlig Kubernetes-volym. Mer information om kloning av volymer i Kubernetes finns i den konceptuella dokumentationen för volymkloning.

CSI-drivrutinen för Azure Disks stöder volymkloning. För att demonstrera skapar du en klonad volym av den tidigare skapade azuredisk-pvc och en ny podd för att använda den.

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

Kommandots utdata liknar följande exempel:

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

Du kan kontrollera innehållet i den klonade volymen genom att köra följande kommando och bekräfta att filen test.txt har skapats:

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

Kommandots utdata liknar följande exempel:

lost+found
outfile
test.txt

Ändra storlek på en beständig volym utan stilleståndstid

Du kan begära en större volym för en PVC. Redigera PVC-objektet och ange en större storlek. Den här ändringen utlöser expansionen av den underliggande volymen som stöder PV:en.

Kommentar

En ny PV skapas aldrig för att uppfylla anspråket. I stället ändras storlek på en befintlig volym.

I AKS stöder den inbyggda managed-csi lagringsklassen redan expansion, så använd DEN PVC som skapades tidigare med den här lagringsklassen. PVC begärde en beständig volym på 10 Gi. Du kan bekräfta genom att köra följande kommando:

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

Kommandots utdata liknar följande exempel:

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

Expandera PVC genom att öka fältet spec.resources.requests.storage som kör följande kommando:

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

Kommentar

Krympande beständiga volymer stöds inte för närvarande. Försök att korrigera en befintlig PVC med en mindre storlek än den aktuella leder till följande felmeddelande: The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

Kommandots utdata liknar följande exempel:

persistentvolumeclaim/pvc-azuredisk patched

Kör följande kommando för att bekräfta att volymstorleken har ökat:

kubectl get pv

Kommandots utdata liknar följande exempel:

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
(...)

Och efter några minuter kör du följande kommandon för att bekräfta storleken på PVC:

kubectl get pvc pvc-azuredisk

Kommandots utdata liknar följande exempel:

NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk   Bound    pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            managed-csi    2d2h

Kör följande kommando för att bekräfta diskens storlek i podden:

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

Kommandots utdata liknar följande exempel:

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

Bursting på begäran

Disksprängningsmodellen på begäran tillåter disktoppar när dess behov överskrider den aktuella kapaciteten. Den här modellen genererar extra avgifter när disken spricker. Bursting på begäran är endast tillgängligt för premium-SSD:er som är större än 512 GiB. Mer information om premium-SSD:er etablerade IOPS och dataflöde per disk finns i Premium SSD-storlek. Alternativt är kreditbaserad bursting där disken bara kommer att brista om den har burst-krediter ackumulerade i sin kredit bucket. Kreditbaserad bursting genererar inte extra avgifter när disken spricker. Kreditbaserad bursting är endast tillgängligt för premium SSD 512 GiB och mindre, och standard SSD 1024 GiB och mindre. Mer information om bursting på begäran finns i Bursting på begäran.

Viktigt!

Standardlagringsklassen managed-csi-premium har bursting på begäran inaktiverad och använder kreditbaserad bursting. Premium SSD som skapas dynamiskt av ett beständigt volymanspråk baserat på standardlagringsklassen managed-csi-premium har också bursting på begäran inaktiverat.

Om du vill skapa en beständig premium-SSD-volym med bursting på begäran aktiverat kan du skapa en ny lagringsklass med parametern enableBursting inställd true på enligt följande YAML-mall. Mer information om hur du aktiverar burst-prestanda på begäran finns i Bursting på begäran. Mer information om hur du skapar en egen lagringsklass med bursting på begäran aktiverad finns i Skapa en burstbar hanterad CSI Premium Storage-klass.

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-containrar

Azure Disk CSI-drivrutinen stöder Windows-noder och containrar. Om du vill använda Windows-containrar följer du snabbstarten windowscontainrar för att lägga till en Windows-nodpool.

När du har en Windows-nodpool kan du nu använda de inbyggda lagringsklasserna som managed-csi. Du kan distribuera ett exempel på en Windows-baserad tillståndskänslig uppsättning som sparar tidsstämplar i filen data.txt genom att köra följande kubectl apply-kommando :

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

Kommandots utdata liknar följande exempel:

statefulset.apps/busybox-azuredisk created

Kör följande kommando för att verifiera volymens innehåll:

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

Kommandots utdata liknar följande exempel:

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

Nästa steg