Delen via


Persistent volumes (PV's) maken en beheren met Azure Disks in Azure Kubernetes Service (AKS)

Dit artikel laat zien hoe je met Azure Disks permanente volumes (PV's) dynamisch en statisch maakt voor gebruik door één pod in een Azure Kubernetes Service (AKS)-cluster.

Vereiste voorwaarden

  • Azure CLI versie 2.0.59 of hoger geïnstalleerd en geconfigureerd. Zoek de versie met behulp van de az --version opdracht. Voor het installeren of upgraden, zie Azure CLI installeren.

  • Het CSI-stuurprogramma voor Azure Disks ingeschakeld op uw AKS-cluster.

  • Het CSI-stuurprogramma voor Azure Disks heeft een volumelimiet per knooppunt. Het aantal volumes verandert op basis van de grootte van de knooppunt-/knooppuntgroep. U kunt het aantal volumes bepalen dat per knooppunt kan worden toegewezen met behulp van de kubectl get opdracht. Voorbeeld:

    kubectl get CSINode <node-name> -o yaml
    

    Als de volumelimiet per knooppunt een probleem is voor uw workload, kunt u Overwegen Om Azure Container Storage te gebruiken voor permanente volumes in plaats van CSI-stuurprogramma's.

Ingebouwde opslagklassen voor dynamische PV's met Azure Disks

Opslagklassen definiëren hoe een opslageenheid dynamisch wordt gemaakt met een permanent volume.

Elk AKS-cluster bevat vier ingebouwde opslagklassen, waarbij er twee zijn geconfigureerd voor gebruik met Azure Disks:

  • De standaardopslagklasse richt een Standard SSD Azure Disk in.
    • Standaard-schijven ondersteunen standaard-opslag en leveren kosteneffectieve opslag, terwijl ze nog steeds betrouwbare prestaties leveren.
  • De managed-csi-premium opslagklasse voorziet in een premium Azure-schijf.
    • SSD-schijven met hoge prestaties en lage latentie ondersteunen Premium-schijven. Ze zijn ideaal voor virtuele machines (VM's) die productieworkloads uitvoeren. Wanneer u het Azure Disk CSI-stuurprogramma op AKS gebruikt, kunt u ook de managed-csi opslagklasse gebruiken, die wordt ondersteund door Standard SSD lokaal redundante opslag (LRS).
  • Effectief vanaf Kubernetes versie 1.29: Wanneer u AKS-clusters implementeert in meerdere beschikbaarheidszones, maakt AKS nu gebruik van zone-redundante opslag (ZRS) om beheerde schijven te maken binnen ingebouwde opslagklassen.
    • ZRS zorgt voor synchrone replicatie van uw Azure Managed Disks in meerdere Azure-beschikbaarheidszones in uw gekozen regio. Deze redundantiestrategie verbetert de tolerantie van uw toepassingen en beschermt uw gegevens tegen datacenterfouten.
      • Het is echter belangrijk om te weten dat ZRS een hogere kosten heeft in vergelijking met lokaal redundante opslag (LRS). Als kostenoptimalisatie een prioriteit is, kunt u een nieuwe opslagklasse maken met de naamparameter LRS SKU en deze gebruiken in uw PVC.

Het verkleinen van een PVC wordt niet ondersteund vanwege het risico op gegevensverlies. U kunt een bestaande opslagklasse bewerken met behulp van de kubectl edit sc opdracht of u kunt uw eigen aangepaste opslagklasse maken.

Opmerking

Permanente volumeverzoeken worden opgegeven in GiB, maar Azure Managed Disks worden gefactureerd volgens het SKU voor een specifieke grootte. Deze SKU's variëren van 32 GiB voor S4- of P4-schijven tot 32 TiB voor S80- of P80-schijven (in preview). De doorvoer en IOPS-prestaties van een Premium SSD zijn afhankelijk van zowel de SKU als de instantiegrootte van de knooppunten in het AKS-cluster. Zie Prijzen en prestaties van beheerde schijven voor meer informatie.

Bekijk de vooraf gemaakte opslagklassen met behulp van de kubectl get sc opdracht. In het volgende voorbeeld ziet u de vooraf gemaakte opslagklassen die beschikbaar zijn in een AKS-cluster:

kubectl get sc

Uw uitvoer moet lijken op de volgende voorbeelduitvoer, waaronder de default en managed-csi opslagklassen die vooraf zijn gemaakt voor Azure Disks:

NAME                PROVISIONER                AGE
default (default)   disk.csi.azure.com         1h
managed-csi         disk.csi.azure.com         1h

Aangepaste opslagklassen maken voor dynamische PV's met Azure Disks

De standaardopslagklassen zijn geschikt voor de meeste 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 node-pools beperkt zijn, bijvoorbeeld wanneer u beschikbaarheidszones gebruikt, worden PV's gebonden of ingericht zonder rekening te houden met de planningsvereisten van de Pod.

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

  1. Maak een bestand met de naam sc-azuredisk-csi-waitforfirstconsumer.yaml en plak het volgende YAML-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
    
  2. Maak de opslagklasse met behulp van de kubectl apply opdracht en geef het sc-azuredisk-csi-waitforfirstconsumer.yaml bestand op:

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

    De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

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

Parameters voor opslagklasse voor dynamische PV's met Azure Disks

De volgende tabel bevat parameters die u kunt gebruiken om een aangepaste opslagklasse te definiëren voor uw dynamische permanente volumeclaims (PVC's) met Azure Disks:

Naam Meaning Beschikbare waarden Verplicht Standaardwaarde
skuName Azure Disks opslagaccounttype (alias: storageAccountType). PremiumV2_LRS en UltraSSD_LRS biedt ondersteuning voor directe toegang voor incrementele herstelbewerkingen van momentopnamen. Standard_LRS, , Premium_LRSStandardSSD_LRS, PremiumV2_LRS, , UltraSSD_LRS, , Premium_ZRSStandardSSD_ZRS Nee. StandardSSD_LRS
fsType Bestandssysteemtype ext4, , ext3ext2, , xfsbtrfsvoor Linux
ntfs voor Windows
Nee. ext4 voor Linux
ntfs voor Windows
cachingMode Azure Data Disk Host Cache-instelling (PremiumV2_LRS en UltraSSD_LRS bieden alleen ondersteuning voor None de cachemodus) None, ReadOnly, ReadWrite Nee. ReadOnly
resourceGroup De resourcegroep voor de Azure-schijven opgeven Naam van bestaande resourcegroep Nee. Als het stuurprogramma leeg is, gebruikt het stuurprogramma dezelfde naam van de resourcegroep als het huidige AKS-cluster
DiskIOPSReadWrite Ultra Disk of Premium SSD v2 IOPS-mogelijkheid (minimaal: 2 IOPS/GiB) 100~160000 Nee. 500
DiskMBpsReadWrite Ultra Disk of Premium SSD v2 doorvoermogelijkheid (minimaal: 0,032/GiB) 1~2000 Nee. 100
LogicalSectorSize Grootte van logische sector in bytes voor Ultra Disk. 512, 4096 Nee. 4096
tags Azure Disk tags Tagindeling: key1=val1,key2=val2 Nee. ""
diskEncryptionSetID Resource ID van de schijfversleutelingsset die moet worden gebruikt voor het inschakelen van versleuteling in rusttoestand formatteren: /subscriptions/{subs-id}/resourceGroups/{rg-name}/providers/Microsoft.Compute/diskEncryptionSets/{diskEncryptionSet-name} Nee. ""
diskEncryptionType Versleutelingstype van de schijfversleutelingsset. EncryptionAtRestWithCustomerKey (standaard), EncryptionAtRestWithPlatformAndCustomerKeys Nee. ""
writeAcceleratorEnabled Schrijfversneller op Azure Disks true, false Nee. ""
networkAccessPolicy NetworkAccessPolicy eigenschap om het genereren van de SAS-URI voor een schijf of een momentopname te voorkomen. AllowAll, DenyAll, AllowPrivate Nee. AllowAll
diskAccessID Azure-resource-ID van de DiskAccess-resource voor gebruik van privé-eindpunten op schijven Nee. ``
enableBursting Schakel on-demand bursting in buiten het geconfigureerde prestatiedoel van de schijf. Bursting op aanvraag mag alleen worden toegepast op Premium-schijf en wanneer de schijfgrootte 512 GB is > . Ultra- en gedeelde schijf wordt niet ondersteund. Bursting is standaard uitgeschakeld. true, false Nee. false
useragent Gebruikersagent die wordt gebruikt voor het toewijzen van klantgebruik Nee. Gegenereerde indeling van gebruikersagent: driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Geef de Azure-abonnements-id op waarin de Azure-schijven worden gemaakt. Azure-abonnements-id Nee. Indien niet leeg, resourceGroup moet worden opgegeven.
--- De volgende parameters zijn alleen voor v2 --- --- ---
maxShares Het totale aantal gedeelde schijfkoppelingen dat is toegestaan voor de schijf. Als u de waarde instelt op 2 of meer, worden replica's van bijlagen mogelijk gemaakt. Ondersteunde waarden zijn afhankelijk van de schijfgrootte. Zie Een Azure Managed Disk delen voor ondersteunde waarden. Nee. 1
maxMountReplicaCount Het aantal replicabijlagen dat moet worden onderhouden. Deze waarde moet binnen het bereik [0..(maxShares - 1)] liggen. Nee. Als accessModeReadWriteMany is, is de standaard 0. Anders is de standaardwaarde maxShares - 1

Een PVC maken met Azure Disks

Een PVC richt automatisch opslag in op basis van een opslagklasse. In dit geval kan een PVC een van de vooraf gemaakte opslagklassen gebruiken om een Standard- of Premium Azure Managed Disk te maken.

  1. Maak een bestand met de naam azure-pvc.yaml en plak het volgende manifest. De claim vraagt een schijf met de naam azure-managed-disk5 GB aan met ReadWriteOnce-toegang . De beheerde csi-opslagklasse wordt opgegeven als de opslagklasse.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
        name: azure-managed-disk
    spec:
    accessModes:
    - ReadWriteOnce
    storageClassName: managed-csi
    resources:
        requests:
        storage: 5Gi
    

    Aanbeveling

    Als u een schijf wilt maken die gebruikmaakt van Premium Storage, gebruikt u storageClassName: managed-csi-premium in plaats van managed-csi.

  2. Maak het PVC met behulp van de kubectl apply opdracht en geef uw azure-pvc.yaml-bestand op:

    kubectl apply -f azure-pvc.yaml
    

    De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

    persistentvolumeclaim/azure-managed-disk created
    
  3. Controleer of de PV gereed is voor gebruik door een pod door de kubectl describe pvc opdracht:

    kubectl describe pvc azure-managed-disk
    

    De uitvoer moet er ongeveer uitzien als de volgende voorbeeldoutput, waarin wordt weergegeven dat de PV de status In behandeling heeft.

    Name:            azure-managed-disk
    Namespace:       default
    StorageClass:    managed-csi
    Status:          Pending
    [...]
    

Een pod maken die gebruikmaakt van een PVC met Azure Disks

  1. Maak een bestand met de naam azure-pvc-disk.yaml en plak het volgende manifest. Met dit manifest maakt u een eenvoudige NGINX-pod die gebruikmaakt van de permanente volumeclaim met de naam azure-beheerde schijf om de Azure-schijf aan het pad /mnt/azurete koppelen. (Geef voor Windows Server-containers een mountPath met behulp van de Windows-padconventie op, zoals 'D:').

    kind: Pod
    apiVersion: v1
    metadata:
      name: mypod
    spec:
      containers:
        - name: mypod
          image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi
          volumeMounts:
            - mountPath: "/mnt/azure"
              name: volume
              readOnly: false
      volumes:
        - name: volume
          persistentVolumeClaim:
            claimName: azure-managed-disk
    
  2. Maak de pod met behulp van de kubectl apply opdracht.

    kubectl apply -f azure-pvc-disk.yaml
    

    De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

    pod/mypod created
    
  3. U hebt nu een actieve pod waarop uw Azure Disk is gekoppeld in de /mnt/azure directory. Controleer de podconfiguratie met behulp van de kubectl describe opdracht.

    kubectl describe pod mypod
    

    De uitvoer moet lijken op de volgende voorbeelduitvoer, die laat zien dat het volume met de naam volume het PVC met de naam azure-managed-disk gebruikt.

    [...]
    Volumes:
    volume:
        Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
        ClaimName:  azure-managed-disk
        ReadOnly:   false
        default-token-smm2n:
        Type:        Secret (a volume populated by a Secret)
        SecretName:  default-token-smm2n
        Optional:    false
    [...]
    Events:
    Type    Reason                 Age   From                               Message
    ----    ------                 ----  ----                               -------
    Normal  Scheduled              2m    default-scheduler                  Successfully assigned mypod to aks-nodepool1-12345678-9
    Normal  SuccessfulMountVolume  2m    kubelet, aks-nodepool1-12345678-9  MountVolume.SetUp succeeded for volume "default-token-smm2n"
    Normal  SuccessfulMountVolume  1m    kubelet, aks-nodepool1-12345678-9  MountVolume.SetUp succeeded for volume "pvc-abc0d123-4e5f-67g8-901h-ijk23l45m678"
    [...]
    

Parameters voor volumemomentopnameklasse voor Azure Disks

Het CSI-stuurprogramma van Azure Disks ondersteunt 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.

De volgende tabel bevat details over de parameters die u kunt gebruiken om een aangepaste volumemomentopnameklasse te definiëren voor uw volumemomentopnamen met Azure Disks:

Naam Meaning Beschikbare waarden Verplicht Standaardwaarde
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
incremental Maak een volledige of incrementele momentopname true, false Nee. true
tags Azure Disks labels Labelindeling: 'key1=val1,key2=val2' Nee. ""
userAgent Gebruikersagent die wordt gebruikt voor het toewijzen van klantgebruik Nee. Gegenereerde useragent geformatteerd 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, moet resourceGroup worden opgegeven en moet incremental worden ingesteld als false.

Een momentopname van een volume maken op basis van een PVC met Azure Disks

Opmerking

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

  1. Maak een volumemomentopnameklasse met behulp van de kubectl apply opdracht:

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

    De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

    volumesnapshotclass.snapshot.storage.k8s.io/csi-azuredisk-vsc created
    
  2. Maak een volumemomentopname van het dynamische PVC dat u eerder in deze zelfstudie hebt gemaakt met behulp van de kubectl apply opdracht:

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

    De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

    volumesnapshot.snapshot.storage.k8s.io/azuredisk-volume-snapshot created
    
  3. Controleer of de momentopname van het volume succesvol is gemaakt met behulp van de kubectl describe commando:

    kubectl describe volumesnapshot azuredisk-volume-snapshot
    

    De uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer, waarin wordt weergegeven dat de momentopname van het volume gereed is om te worden gebruikt:

    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:               00aa00aa-bb11-cc22-dd33-44ee44ee44ee
    Spec:
      Source:
        Persistent Volume Claim Name:  pvc-azuredisk
      Volume Snapshot Class Name:      csi-azuredisk-vsc
    Status:
      Bound Volume Snapshot Content Name:  snapcontent-00aa00aa-bb11-cc22-dd33-44ee44ee44ee
      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 met Azure Disks

U kunt een nieuw PVC maken op basis van een momentopname van een volume. In deze sectie gebruiken we de momentopname uit de sectie 'Een volumemomentopname maken van een PVC met Azure Disks', en maken we een nieuw PVC en een nieuwe pod voor het gebruik ervan.

  1. Maak het PVC en de pod met behulp van de volgende kubectl apply opdrachten:

    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 zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

    persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
    pod/nginx-restored created
    
  2. Valideer dat het dezelfde PVC is die u eerder hebt gemaakt door de inhoud van het volume te controleren met behulp van de kubectl exec opdracht, waarmee u de ls opdracht binnen de pod uitvoert.

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

    De uitvoer moet lijken op de volgende voorbeelduitvoer, waarin dezelfde inhoud wordt weergegeven als de oorspronkelijke PVC, inclusief het test.txt bestand dat is gemaakt in het oorspronkelijke PVC:

    lost+found
    outfile
    test.txt
    

Volumes klonen met Azure Disks

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 het dynamische PVC dat u eerder in deze zelfstudie hebt gemaakt en een nieuwe pod om deze te gebruiken.

  1. Maak de gekloonde PVC en pod met behulp van de volgende kubectl apply opdrachten:

    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 zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

    persistentvolumeclaim/pvc-azuredisk-cloning created
    pod/nginx-restored-cloning created
    
  2. Controleer of het gekloonde volume dezelfde inhoud heeft als het oorspronkelijke volume door de inhoud van het volume te controleren met behulp van de kubectl exec opdracht om de ls opdracht in de pod uit te voeren:

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

    De uitvoer moet lijken op de volgende voorbeelduitvoer, waarin dezelfde inhoud wordt weergegeven als de oorspronkelijke PVC, inclusief het test.txt bestand dat is gemaakt in het oorspronkelijke PVC:

    lost+found
    outfile
    test.txt
    

Het formaat van een permanent volume wijzigen zonder uitvaltijd met Azure Disks

Opmerking

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.

U kunt een groter volume voor een PVC aanvragen door het PVC-object te bewerken om een grotere grootte op te geven. Deze wijziging resulteert in de uitbreiding van het onderliggende volume dat het PV ondersteuning biedt. 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, zodat u het dynamische PVC kunt gebruiken dat u eerder in deze zelfstudie hebt gemaakt. De PVC vroeg om een permanent volume van 10 Gi.

  1. Controleer de huidige grootte van het volume met behulp van de kubectl exec opdracht om de df -h opdracht in de pod uit te voeren:

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

    De uitvoer moet lijken op de volgende voorbeelduitvoer, waarin de huidige grootte van het volume 10 Gi is:

    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sdc        9.8G   42M  9.8G   1% /mnt/azuredisk
    
  2. Vouw het PVC uit door het spec.resources.requests.storage veld te vergroten met behulp van de kubectl patch opdracht. In dit voorbeeld vergroten we de grootte van het PVC tot 15 Gi:

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

    De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

    persistentvolumeclaim/pvc-azuredisk patched
    
  3. Controleer de PV om te bevestigen dat de nieuwe grootte wordt weergegeven in de PV met behulp van de kubectl get pv opdracht:

    kubectl get pv
    

    De uitvoer moet eruitzien als het volgende voorbeeld, dat toont dat de PV is vergroot tot 15 Gi.

    NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
    pvc-a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1   15Gi       RWO            Delete           Bound    default/pvc-azuredisk                     managed-csi             2d2h
    (...)
    
  4. Controleer na enkele minuten of de nieuwe grootte in de PVC wordt weergegeven met behulp van de kubectl get pvc opdracht.

    kubectl get pvc pvc-azuredisk
    

    De uitvoer moet lijken op de volgende voorbeelduitvoer, waarin wordt weergegeven dat het pvc is aangepast aan 15 Gi:

    NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    pvc-azuredisk   Bound    pvc-a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1   15Gi       RWO            managed-csi    2d2h
    
  5. Controleer of de grootte van de schijf in de pod is bijgewerkt naar de nieuwe grootte met behulp van de kubectl exec opdracht om de df -h opdracht in de pod uit te voeren:

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

    De uitvoer moet lijken op de volgende voorbeelduitvoer, waarin de grootte van het volume is bijgewerkt naar 15 Gi:

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

On-demand bursting voor Premium SSD's met Azure Disks

Met het on-demand schijfburst-model kunnen schijf-bursts worden uitgevoerd wanneer de benodigdheden de huidige capaciteit overstijgen. Dit model genereert extra kosten telkens wanneer de schijf opengaat. Bursting op aanvraag is alleen beschikbaar voor Premium SSD's die groter zijn dan 512 GiB. Zie Premium SSD-grootte voor meer informatie over door Premium SSD's ingerichte IOPS en doorvoer per schijf. Bursting op basis van tegoed gebeurt alleen wanneer de schijf genoeg burst-tegoeden heeft verzameld in zijn creditsboek. 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. Voor meer informatie over bursting op aanvraag, zie 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 Premium SSD-persistent volume wilt maken met bursting op aanvraag ingeschakeld, kunt u een nieuwe opslagklasse maken waarbij de enableBursting-parameter is ingesteld zoals aangegeven 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

Azure Disks gebruiken met Windows-containers

Het Azure Disk CSI-stuurprogramma 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 de ingebouwde opslagklassen gebruiken, zoals managed-csi.

  1. Implementeer een voorbeeld van een stateful set op basis van Windows waarmee tijdstempels in het bestand data.txt worden opgeslagen met behulp van de volgende kubectl apply opdracht:

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

    De uitvoer zou ongeveer moeten lijken op de volgende voorbeelduitvoer:

    statefulset.apps/busybox-azuredisk created
    
  2. Valideer de inhoud van het bestand data.txt in de pod met behulp van de kubectl exec opdracht om de type opdracht in de pod uit te voeren:

    kubectl exec -it statefulset-azuredisk-win-0 -- powershell -c "type c:/mnt/azuredisk/data.txt"
    

    De uitvoer moet lijken op de volgende voorbeelduitvoer, waarin de tijdstempels worden weergegeven die in het bestand data.txtworden opgeslagen:

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

Een statische HW maken met Azure Disks

In de volgende secties vind je instructies voor het maken van een statische PV met Azure Disks. Een statische PV is een permanent volume dat een beheerder handmatig maakt. Deze PV is beschikbaar voor gebruik van pods in het cluster. Als u een statische PV wilt gebruiken, maakt u een PVC dat verwijst naar de PV en maakt u vervolgens een pod die verwijst naar het PVC.

Opslagklasseparameters voor statische tv's met Azure Disks

De volgende tabel bevat parameters die u kunt gebruiken om een aangepaste opslagklasse te definiëren voor uw statische PVC's met Azure Disks:

Naam Meaning Beschikbare waarden Verplicht Standaardwaarde
volumeHandle Azure-schijf-URI /subscriptions/{sub-id}/resourcegroups/{group-name}/providers/microsoft.compute/disks/{disk-id} Ja N/A
volumeAttributes.fsType Bestandssysteemtype ext4, , ext3ext2, , xfsbtrfsvoor Linux
ntfs voor Windows
Nee. ext4 voor Linux
ntfs voor Windows
volumeAttributes.partition Partitienummer van de bestaande schijf (alleen ondersteund in Linux) 1, 2, 3 Nee. Leeg (geen partitie) Zorg ervoor dat de partitie-indeling is: -part1
volumeAttributes.cachingMode Instelling voor schijfhostcache None, ReadOnly, ReadWrite Nee. ReadOnly

Een Azure-schijf maken

Wanneer u een Azure-schijf maakt voor gebruik met AKS, kunt u de schijfresource maken in de knooppuntresourcegroep. Met deze methode kan het AKS-cluster toegang krijgen tot de schijfresource en deze beheren. Als u in plaats daarvan de schijf in een afzonderlijke resourcegroep maakt, moet u de beheerde AKS-identiteit voor uw cluster de Contributor rol verlenen aan de resourcegroep van de schijf.

  1. Identificeer de naam van de knooppuntresourcegroep met behulp van de az aks show opdracht met de --query nodeResourceGroup parameter.

    az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
    

    De uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer, waarin de naam van de knooppuntresourcegroep voor het AKS-cluster wordt weergegeven:

    MC_myResourceGroup_myAKSCluster_eastus
    
  2. Maak een schijf met behulp van de az disk create opdracht. Geef de naam van de knooppuntresourcegroep en een naam op voor de schijfresource, zoals myAKSDisk. In het volgende voorbeeld wordt een 20 GiB-schijf gemaakt en wordt de ID van de schijf weergegeven nadat deze is gemaakt. Als u een schijf wilt maken voor gebruik met Windows Server-containers, voegt u de --os-type windows parameter toe om de schijf correct te formatteren.

    az disk create \
      --resource-group MC_myResourceGroup_myAKSCluster_eastus \
      --name myAKSDisk \
      --size-gb 20 \
      --query id --output tsv
    

    Opmerking

    Azure Disks worden gefactureerd op basis van SKU voor een specifieke maat. Deze SKU's variëren van 32 GiB voor S4- of P4-schijven tot 32 TiB voor S80- of P80-schijven (in preview). De doorvoer en IOPS-prestaties van een beheerde Premium-schijf zijn afhankelijk van zowel de SKU als de instantiegrootte van de knooppunten in het AKS-cluster. Zie prijzen en prestaties van Managed Disks.

    De uitvoer moet er ongeveer uitzien als in de volgende voorbeelduitvoer, waarin de resource-id van de schijf wordt weergegeven die is gemaakt:

    /subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk
    

Een PV en PVC maken die verwijzen naar de Azure-schijf

  1. Maak een pv-azuredisk.yaml-bestand met een PV met behulp van het volgende manifest. Werk volumeHandle bij met de resource-id van de schijf uit de vorige stap. Geef voor Windows Server-containers ntfs op voor de parameter fsType.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      annotations:
        pv.kubernetes.io/provisioned-by: disk.csi.azure.com
      name: pv-azuredisk
    spec:
      capacity:
        storage: 20Gi
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      storageClassName: managed-csi
      csi:
        driver: disk.csi.azure.com
        volumeHandle: /subscriptions/<subscriptionID>/resourceGroups/MC_myAKSCluster_myAKSCluster_eastus/providers/Microsoft.Compute/disks/myAKSDisk
        volumeAttributes:
          fsType: ext4
    

    Zoals vermeld in Een Azure-schijf maken, moet u, als de schijf voor de volumeHandle schijf is gemaakt in een afzonderlijke resourcegroep, de beheerde identiteit van het AKS-cluster de Contributor rol toewijzen aan de resourcegroep van de schijf.

  2. Maak een pvc-azuredisk.yaml-bestand met een PVC dat gebruikmaakt van de PV met behulp van het volgende voorbeeldmanifest:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc-azuredisk
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 20Gi
      volumeName: pv-azuredisk
      storageClassName: managed-csi
    
  3. Maak de PV en PVC met behulp van de volgende kubectl apply opdrachten:

    kubectl apply -f pv-azuredisk.yaml
    kubectl apply -f pvc-azuredisk.yaml
    
  4. Controleer of de PVC succesvol is gemaakt en gebonden aan de PV met behulp van het kubectl get pvc commando.

    kubectl get pvc pvc-azuredisk
    

    De uitvoer moet vergelijkbaar zijn met de volgende voorbeelduitvoer, waarin wordt weergegeven dat de PVC een Gebonden status heeft.

    NAME            STATUS   VOLUME         CAPACITY    ACCESS MODES   STORAGECLASS   AGE
    pvc-azuredisk   Bound    pv-azuredisk   20Gi        RWO                           5s
    

Een pod maken die gebruikmaakt van pvc met Azure Disks

  1. Maak een azure-disk-pod.yaml-bestand om te verwijzen naar uw PVC met behulp van het volgende voorbeeldmanifest. (Specificeer voor Windows Server-containers een mountPath met gebruikmaking van de Windows-padconventie, zoals 'D:').

    apiVersion: v1
    kind: Pod
    metadata:
      name: mypod
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
        name: mypod
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 250m
            memory: 256Mi
        volumeMounts:
          - name: azure
            mountPath: /mnt/azure
      volumes:
        - name: azure
          persistentVolumeClaim:
            claimName: pvc-azuredisk
    
  2. Pas de configuratie toe en koppel het volume met behulp van de kubectl apply opdracht.

    kubectl apply -f azure-disk-pod.yaml
    

De hulpbronnen opschonen

  • Verwijder de resources die u in deze zelfstudie hebt gemaakt met behulp van de volgende opdrachten [kubectl delete][kubectl-delete]:

    # Remove the pod
    kubectl delete -f azure-pvc-disk.yaml
    
    # Remove the persistent volume claim
    kubectl delete -f azure-pvc.yaml