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

  • Artikel

Drivrutinen för Azure Disks Container Storage Interface (CSI) är en CSI-specifikationskompatibel 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. Om du använder CSI-drivrutiner i AKS slipper du 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.

Anteckning

Azure Disk CSI-drivrutin 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-drivrutin 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.

Anteckning

Drivrutiner i träd 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 stöder Azure Disk CSI-drivrutinen följande funktioner:

  • Prestandaförbättringar vid samtidig diskanslutning och frånkoppling
    • Drivrutiner i träd ansluter eller kopplar från diskar i serie, 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å zonen eller noden som inte är 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

Anteckning

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. Statisk etablering finns i Skapa en statisk volym med Azure Disks.

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

Skapa PV:er för Azure Disks 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 på AKS finns det ytterligare två inbyggda som använder Azure Disk CSI-lagringsdrivrutinen StorageClasses . 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.
  • managed-csi-premium: Använder Azure Premium LRS för att skapa en hanterad disk.

Återtagandeprincipen i båda lagringsklasserna säkerställer att de underliggande Azure-diskarna tas bort när respektive PV tas bort. Lagringsklasserna konfigurerar också PV:erna så att de kan expanderas. 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 en 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 någon 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 har skapats. När nodpoolerna är topologibegränsade, till exempel när du använder tillgänglighetszoner, skulle PV:er bindas eller etableras utan kännedom 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 följer 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 stöder skapande av ö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 Standardvärde
resourceGroup Resursgrupp för lagring av ögonblicksbilder BEFINTLIG RESURSGRUPP Inga Om det inte anges lagras ögonblicksbilden i samma resursgrupp som Källans Azure Disks
Inkrementell Ta en fullständig eller inkrementell ögonblicksbild true, false Inga true
tags Azure Disks-taggar Taggformat: 'key1=val1,key2=val2' Inga ""
Useragent Användaragent som används för kundanvändningsatribution Inga Genererad useragent formaterad driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Ange azure-prenumerations-ID där Azure-diskar ska skapas Azure-prenumerations-ID Inga Om det inte är tomt, resourceGroup måste anges, incremental måste anges som false

Skapa en ögonblicksbild av volymen

Anteckning

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 volymögonblicksbild 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 kontrollerar vi 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 konceptdokumentationen för volymkloning.

CSI-drivrutinen för Azure Disks stöder volymkloning. För att demonstrera skapar du en klonad volym av den tidigare skapadeazuredisk-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.

Anteckning

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:en 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:en genom att öka fältet spec.resources.requests.storage med följande kommando:

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

Anteckning

Krympande beständiga volymer stöds inte för närvarande. Om du försöker korrigera en befintlig PVC med en mindre storlek än den aktuella leder det 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:en:

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 storleken på disken 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

Burst-trafik på begäran

Modellen med disktoppar på begäran tillåter disktoppar när dess behov överskrider den aktuella kapaciteten. Den här modellen genererar extra avgifter varje gång disken bursts. Burst på begäran är endast tillgängligt för premium-SSD 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 burst endast där disken bara kommer att brista om den har burst-krediter som ackumulerats i sin kreditbucket. Kreditbaserade burst-fel genererar inte extra avgifter när disken spricker. Kreditbaserad burst är endast tillgängligt för premium SSD 512 GiB och mindre, och standard SSD 1024 GiB och mindre. Mer information om burst på begäran finns i Bursting på begäran.

Viktigt

managed-csi-premium Standardlagringsklassen 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-åtgärder på begäran finns i Bursting på begäran. Mer information om hur du skapar en egen lagringsklass med bursting på begäran aktiverat 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 för Windows-containrar 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 kommando kubectl apply :

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