Share via

Het CSI-stuurprogramma (Azure Disk Container Storage Interface) gebruiken in Azure Kubernetes Service (AKS)

  • Artikel

Het CSI-stuurprogramma (Azure Disks Container Storage Interface) is een CSI-stuurprogramma dat voldoet aan de specificatie die door Azure Kubernetes Service (AKS) wordt gebruikt om de levenscyclus van Azure Disk te beheren.

De CSI is een standaard voor het beschikbaar maken van willekeurige blok- en bestandsopslagsystemen voor workloads in containers in Kubernetes. Door CSI te gebruiken en te gebruiken, kan AKS nu invoegtoepassingen schrijven, implementeren en herhalen om nieuwe of verbeterde bestaande opslagsystemen in Kubernetes beschikbaar te maken of te verbeteren. Als u CSI-stuurprogramma's in AKS gebruikt, hoeft u de kubernetes-kerncode niet aan te raken en te wachten op de releasecycli.

Als u een AKS-cluster wilt maken met CSI-stuurprogrammaondersteuning, raadpleegt u CSI-stuurprogramma inschakelen op AKS. In dit artikel wordt beschreven hoe u versie 1 van het Azure Disk CSI-stuurprogramma gebruikt.

Notitie

Azure Disk CSI-stuurprogramma v2 (preview) verbetert de schaalbaarheid en vermindert de latentie van podfailover. Het maakt gebruik van gedeelde schijven voor het inrichten van bijlagereplica's op meerdere clusterknooppunten en kan worden geïntegreerd met de podplanner om ervoor te zorgen dat een knooppunt met een bijlagereplica wordt gekozen bij failover van pods. Azure Disk CSI-stuurprogramma v2 (preview) biedt ook de mogelijkheid om de prestaties te verfijnen. Als u geïnteresseerd bent in deelname aan de preview, dient u een aanvraag in: https://aka.ms/DiskCSIv2Preview Deze preview-versie wordt geleverd zonder service level agreement en u kunt af en toe belangrijke wijzigingen verwachten in de preview-versie. De preview-versie wordt niet aanbevolen voor productieworkloads. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure-previews voor meer informatie.

Notitie

Stuurprogramma's in de structuur verwijzen naar de huidige opslagstuurprogramma's die deel uitmaken van de kubernetes-kerncode en de nieuwe CSI-stuurprogramma's, die invoegtoepassingen zijn.

Stuurprogrammafuncties voor Azure Disk CSI

Naast de functies van stuurprogramma's in de structuur ondersteunt het Azure Disk CSI-stuurprogramma de volgende functies:

  • Prestatieverbeteringen tijdens gelijktijdige schijfkoppeling en loskoppelen
    • Stuurprogramma's in de structuur koppelen of loskoppelen schijven in serie, terwijl CSI-stuurprogramma's schijven in batch koppelen of loskoppelen. Er is een aanzienlijke verbetering als er meerdere schijven zijn gekoppeld aan één knooppunt.
  • Premium SSD v1 en v2 worden ondersteund.
    • PremiumV2_LRSNone ondersteunt alleen de cachemodus
  • Ondersteuning voor zone-redundante opslagschijven (ZRS)
    • Premium_ZRS, StandardSSD_ZRS schijftypen worden ondersteund. ZRS-schijf kan worden gepland op het zone- of niet-zoneknooppunt, zonder de beperking dat het schijfvolume zich in dezelfde zone moet bevinden als een bepaald knooppunt. Zie Zone-redundante opslag voor beheerde schijven voor meer informatie, waaronder welke regio's worden ondersteund.
  • Momentopname
  • Volumeklonen
  • Grootte van schijf HW wijzigen zonder uitvaltijd

Notitie

Afhankelijk van de VM-SKU die wordt gebruikt, heeft het Azure Disk CSI-stuurprogramma mogelijk een volumelimiet per knooppunt. Voor sommige krachtige VM's (bijvoorbeeld 16 kernen) is de limiet 64 volumes per knooppunt. Als u de limiet per VM-SKU wilt identificeren, bekijkt u de kolom Max-gegevensschijven voor elke aangeboden VM-SKU. Zie De grootten van virtuele machines voor algemeen gebruik voor een lijst met aangeboden VM-SKU's en de bijbehorende gedetailleerde capaciteitslimieten.

Permanente CSI-volumes gebruiken met Azure Disks

Een permanent volume (PV) vertegenwoordigt een stuk opslag dat is ingericht voor gebruik met Kubernetes-pods. Een HW kan worden gebruikt door een of meer pods en kan dynamisch of statisch worden ingericht. In dit artikel leest u hoe u dynamisch pc's maakt met Een Azure-schijf voor gebruik door één pod in een AKS-cluster. Zie Een statisch volume maken met Azure Disks voor statische inrichting.

Zie Opslagopties voor toepassingen in AKS voor meer informatie over Kubernetes-volumes.

Dynamisch Azure Disks-VM's maken met behulp van de ingebouwde opslagklassen

Een opslagklasse wordt gebruikt om te definiëren hoe een opslageenheid dynamisch wordt gemaakt met een permanent volume. Zie Kubernetes-opslagklassen voor meer informatie over Kubernetes-opslagklassen.

Wanneer u het Azure Disk CSI-stuurprogramma op AKS gebruikt, zijn er nog twee ingebouwde stuurprogramma's StorageClasses die gebruikmaken van het Stuurprogramma voor Azure Disk CSI-opslag. De andere CSI-opslagklassen worden gemaakt met het cluster naast de standaardopslagklassen in de structuur.

  • managed-csi: Maakt gebruik van Azure Standard SSD lokaal redundante opslag (LRS) om een beheerde schijf te maken. Vanaf Kubernetes versie 1.29, in AKS-clusters (Azure Kubernetes Service) die zijn geïmplementeerd in meerdere beschikbaarheidszones, maakt deze opslagklasse gebruik van Zone-redundante opslag (ZRS) van Azure Standard SSD om beheerde schijven te maken.
  • managed-csi-premium: Maakt gebruik van Azure Premium LRS om een beheerde schijf te maken. Vanaf Kubernetes versie 1.29, in AKS-clusters (Azure Kubernetes Service) die zijn geïmplementeerd in meerdere beschikbaarheidszones, maakt deze opslagklasse gebruik van Azure Premium zone-redundante opslag (ZRS) om beheerde schijven te maken.

Het claimbeleid in beide opslagklassen zorgt ervoor dat de onderliggende Azure-schijven worden verwijderd wanneer de respectieve HW wordt verwijderd. De opslagklassen configureren ook de TV's die kunnen worden uitgebreid. U hoeft alleen de permanente volumeclaim (PVC) te bewerken met de nieuwe grootte.

Als u deze opslagklassen wilt gebruiken, maakt u een PVC en de respectieve pod die ernaar verwijst en gebruikt. Een PVC wordt gebruikt om automatisch opslag in te richten op basis van een opslagklasse. Een PVC kan een van de vooraf gemaakte opslagklassen of een door de gebruiker gedefinieerde opslagklasse gebruiken om een door Azure beheerde schijf te maken voor de gewenste SKU en grootte. Wanneer u een poddefinitie maakt, wordt het PVC opgegeven om de gewenste opslag aan te vragen.

Maak een voorbeeldpod en respectieve PVC door de opdracht kubectl apply uit te voeren:

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Nadat de pod de status Actief heeft, voert u de volgende opdracht uit om een nieuw bestand met de naam test.txtte maken.

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

Als u wilt controleren of de schijf correct is gekoppeld, voert u de volgende opdracht uit en controleert u of het test.txt bestand in de uitvoer wordt weergegeven:

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

lost+found
outfile
test.txt

Een aangepaste opslagklasse maken

De standaardopslagklassen zijn geschikt voor de meest voorkomende scenario's. In sommige gevallen wilt u mogelijk uw eigen opslagklasse aanpassen met uw eigen parameters. U kunt bijvoorbeeld de volumeBindingMode klasse wijzigen.

U kunt een volumeBindingMode: Immediate klasse gebruiken die garandeert dat deze direct plaatsvindt zodra het PVC is gemaakt. Wanneer uw knooppuntgroepen zijn beperkt, bijvoorbeeld wanneer u beschikbaarheidszones gebruikt, worden DEV's gebonden of ingericht zonder kennis van de planningsvereisten van de pod.

Om dit scenario aan te pakken, kunt volumeBindingMode: WaitForFirstConsumeru gebruiken, waardoor de binding en inrichting van een HW wordt vertraagd totdat een pod die gebruikmaakt van het PVC wordt gemaakt. Op deze manier voldoet de HW aan en wordt deze ingericht in de beschikbaarheidszone (of andere topologie) die is opgegeven door de planningsbeperkingen van de pod. De standaardopslagklassen maken gebruik van volumeBindingMode: WaitForFirstConsumer klasse.

Maak een bestand met de naam sc-azuredisk-csi-waitforfirstconsumer.yamlen plak het volgende manifest. De opslagklasse is hetzelfde als onze managed-csi opslagklasse, maar met een andere volumeBindingMode klasse.

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

Maak de opslagklasse door de opdracht kubectl apply uit te voeren en geef het sc-azuredisk-csi-waitforfirstconsumer.yaml bestand op:

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Momentopnamen van volumes

Het Azure Disk CSI-stuurprogramma biedt ondersteuning voor het maken van momentopnamen van permanente volumes. Als onderdeel van deze mogelijkheid kan het stuurprogramma volledige of incrementele momentopnamen uitvoeren, afhankelijk van de waarde die is ingesteld in de incremental parameter (standaard is dit waar).

De volgende tabel bevat details voor alle parameters.

Naam Betekenis Beschikbare waarde Verplicht Default value
resourceGroup Resourcegroep voor het opslaan van momentopnamen BESTAANDE RESOURCEGROEP Nee Als dit niet is opgegeven, wordt de momentopname opgeslagen in dezelfde resourcegroep als de azure-bronschijven
Incrementele Volledige of incrementele momentopname maken true, false Nee true
tags Azure Disks-tags Labelindeling: 'key1=val1,key2=val2' Nee ""
userAgent Gebruikersagent die wordt gebruikt voor het toewijzen van klantgebruik Nee Gegenereerde useragent opgemaakt driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Geef de Azure-abonnements-id op waar Azure Disks worden gemaakt Azure-abonnements-id Nee Als deze niet leeg is, resourceGroup moet worden opgegeven als incrementalfalse

Een momentopname van een volume maken

Notitie

Voordat u doorgaat, moet u ervoor zorgen dat de toepassing geen gegevens naar de bronschijf schrijft.

Voor een voorbeeld van deze mogelijkheid maakt u een volumemomentopnameklasse met de opdracht kubectl apply :

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

We gaan nu een volumemomentopname maken van het PVC dat we dynamisch aan het begin van deze zelfstudie hebben gemaakt. pvc-azuredisk

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Voer de volgende opdracht uit om te controleren of de momentopname juist is gemaakt:

kubectl describe volumesnapshot azuredisk-volume-snapshot

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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>

Een nieuw PVC maken op basis van een momentopname van een volume

U kunt een nieuw PVC maken op basis van een momentopname van een volume. Gebruik de momentopname die u in de vorige stap hebt gemaakt en maak een nieuw PVC en een nieuwe pod om deze te gebruiken.

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Laten we ten slotte controleren of het hetzelfde PVC is dat eerder is gemaakt door de inhoud te controleren door de volgende opdracht uit te voeren:

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

lost+found
outfile
test.txt

Zoals verwacht, kunnen we nog steeds ons eerder gemaakte test.txt bestand zien.

Volumes klonen

Een gekloond volume wordt gedefinieerd als een duplicaat van een bestaand Kubernetes-volume. Zie de conceptuele documentatie voor het klonen van volumes in Kubernetes voor meer informatie over het klonen van volumes.

Het CSI-stuurprogramma voor Azure Disks ondersteunt het klonen van volumes. Ter illustratie maakt u een gekloond volume van de eerder gemaakte azuredisk-pvc en een nieuwe pod om deze te gebruiken.

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

U kunt de inhoud van het gekloonde volume controleren door de volgende opdracht uit te voeren en te bevestigen dat het bestand test.txt is gemaakt:

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

lost+found
outfile
test.txt

Het formaat van een permanent volume wijzigen zonder uitvaltijd

U kunt een groter volume aanvragen voor een PVC. Bewerk het PVC-object en geef een groter formaat op. Deze wijziging resulteert in de uitbreiding van het onderliggende volume dat het PV ondersteuning biedt.

Notitie

Er wordt nooit een nieuwe PV gemaakt om aan de claim te voldoen. In plaats daarvan wordt het formaat van een bestaand volume gewijzigd.

In AKS ondersteunt de ingebouwde managed-csi opslagklasse al uitbreiding, dus gebruik het PVC dat eerder is gemaakt met deze opslagklasse. De PVC vroeg om een permanent volume van 10 Gi. U kunt dit bevestigen door de volgende opdracht uit te voeren:

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Vouw het PVC uit door het spec.resources.requests.storage veld met de volgende opdracht uit te voeren:

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

Notitie

Het verkleinen van permanente volumes wordt momenteel niet ondersteund. Het patchen van een bestaand PVC met een kleinere grootte dan de huidige leidt tot het volgende foutbericht: The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

persistentvolumeclaim/pvc-azuredisk patched

Voer de volgende opdracht uit om te bevestigen dat de volumegrootte is toegenomen:

kubectl get pv

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Voer na een paar minuten de volgende opdrachten uit om de grootte van het PVC te bevestigen:

kubectl get pvc pvc-azuredisk

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Voer de volgende opdracht uit om de grootte van de schijf in de pod te bevestigen:

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Bursting op aanvraag

Met schijf-burstingmodel op aanvraag kunnen schijf-bursts worden uitgevoerd wanneer de huidige capaciteit wordt overschreden. Dit model genereert extra kosten wanneer de schijf bursts. Bursting op aanvraag is alleen beschikbaar voor premium SSD's die groter zijn dan 512 GiB. Zie Premium SSD-grootte voor meer informatie over premium SSD's die zijn ingericht voor IOPS en doorvoer per schijf. U kunt ook bursting op basis van tegoed alleen barsten als de schijf burst-tegoeden bevat die zijn verzameld in de kredietbucket. Bursting op basis van tegoed genereert geen extra kosten wanneer de schijf bursts. Bursting op basis van tegoed is alleen beschikbaar voor premium SSD's 512 GiB en kleiner, en standard SSD's 1024 GiB en kleiner. Zie Bursting op aanvraag voor meer informatie over bursting op aanvraag.

Belangrijk

De standaardopslagklasse managed-csi-premium heeft bursting op aanvraag uitgeschakeld en maakt gebruik van bursting op basis van tegoed. Elke Premium SSD die dynamisch is gemaakt door een permanente volumeclaim op basis van de standaardopslagklasse managed-csi-premium , heeft ook bursting op aanvraag uitgeschakeld.

Als u een permanent premium SSD-volume wilt maken waarvoor bursting op aanvraag is ingeschakeld, kunt u een nieuwe opslagklasse maken met de parameter enableBursting ingesteld true op zoals wordt weergegeven in de volgende YAML-sjabloon. Zie Bursting op aanvraag voor meer informatie over het inschakelen van bursting op aanvraag. Zie Een beheerde CSI Premium-opslagklasse maken voor meer informatie over het bouwen van uw eigen opslagklasse waarvoor bursting op aanvraag is ingeschakeld.

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

Het CSI-stuurprogramma voor Azure-schijven ondersteunt Windows-knooppunten en -containers. Als u Windows-containers wilt gebruiken, volgt u de quickstart voor Windows-containers om een Windows-knooppuntgroep toe te voegen.

Nadat u een Windows-knooppuntgroep hebt, kunt u nu de ingebouwde opslagklassen gebruiken, zoals managed-csi. U kunt een voorbeeld van een stateful set op basis van Windows implementeren waarmee tijdstempels in het bestand data.txt worden opgeslagen door de volgende kubectl-opdracht toe te passen :

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

statefulset.apps/busybox-azuredisk created

Voer de volgende opdracht uit om de inhoud van het volume te valideren:

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

De uitvoer van de opdracht lijkt op het volgende voorbeeld:

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

Volgende stappen