Eseguire la migrazione dalla classe di archiviazione intree ai driver CSI nel servizio Azure Kubernetes (AKS)

L'implementazione del driver CSI (Container Storage Interface) è stata introdotta nel servizio Azure Kubernetes (AKS) a partire dalla versione 1.21. Adottando e usando CSI come standard, dovrai eseguire la migrazione o l'aggiornamento dei tuoi carichi di lavoro con stato esistenti che usano volumi persistenti (PV) intree per usare il driver CSI.

Per rendere questo processo il più semplice possibile e assicurarsi che non ci sia alcuna perdita di dati, questo articolo offre diverse opzioni di migrazione. Queste opzioni includono script per garantire una migrazione senza problemi da intree ai dischi di Azure e ai driver CSI per File di Azure.

Operazioni preliminari

• Interfaccia della riga di comando di Azure versione 2.37.0 o successiva. Esegui az --version per trovare la versione ed esegui az upgrade per aggiornare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.
• Gli amministratori di Kubectl e del cluster hanno accesso a creare, ottenere, elencare, eliminare l'accesso a un contenuto di snapshot del volume o di uno snapshot del volume PVC o PV. Per un cluster abilitato per il controllo degli accessi in base al ruolo di Microsoft Entra, sei un membro del ruolo di amministratore del cluster di controllo degli accessi in base al ruolo del servizio Azure Kubernetes.

Eseguire la migrazione dei volumi dei dischi

Nota

Le etichette failure-domain.beta.kubernetes.io/zone e failure-domain.beta.kubernetes.io/region sono state deprecate nel servizio Azure Kubernetes 1.24 e rimosse nella versione 1.28. Se i tuoi volumi persistenti esistenti usano ancora nodeAffinity, che corrispondono a queste due etichette, è necessario modificarli in etichette topology.kubernetes.io/zone e topology.kubernetes.io/region nella nuova impostazione del volume permanente.

La migrazione da intree a CSI è supportata usando due diverse opzioni di migrazione:

• Creare un volume statico
• Creare un volume dinamico

Creare un volume statico

Usando questa opzione, crei un PV assegnando in modo statico claimRef a un nuovo PVC che creerai in un secondo momento, e specifichi il volumeName per il PersistentVolumeClaim.

Questo approccio offre i vantaggi seguenti:

• È semplice e può essere automatizzato.
• Non è necessario pulire la configurazione originale usando la classe di archiviazione nell'albero.
• Rischio basso perché si esegue solo un'eliminazione logica di Kubernetes PV/PVC, i dati fisici effettivi non vengono eliminati.
• Non sono previsti costi aggiuntivi perché non è necessario creare oggetti Azure supplementari come dischi, snapshot e così via.

Le seguenti considerazioni sono importanti da valutare:

• La transizione ai volumi statici dai volumi originali di tipo dinamico richiede la creazione e la gestione manuale degli oggetti PV per tutte le opzioni.
• Potenziale tempo di inattività dell'applicazione durante la ridistribuzione della nuova applicazione con riferimento al nuovo oggetto PVC.

Migrazione

1. Aggiorna il PV esistente ReclaimPolicy da Delete a Retain eseguendo il comando seguente:

   kubectl patch pv pvName -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
   

   Sostituisci pvName con il nome del PersistentVolume da te selezionato. In alternativa, se vuoi aggiornare reclaimPolicy per più PVs, crea un file denominato patchReclaimPVs.sh e copialo nel codice seguente.

   #!/bin/bash
   # Patch the Persistent Volume in case ReclaimPolicy is Delete
   NAMESPACE=$1
   i=1
   for PVC in $(kubectl get pvc -n $NAMESPACE | awk '{ print $1}'); do
     # Ignore first record as it contains header
     if [ $i -eq 1 ]; then
       i=$((i + 1))
     else
       PV="$(kubectl get pvc $PVC -n $NAMESPACE -o jsonpath='{.spec.volumeName}')"
       RECLAIMPOLICY="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.persistentVolumeReclaimPolicy}')"
       echo "Reclaim Policy for Persistent Volume $PV is $RECLAIMPOLICY"
       if [[ $RECLAIMPOLICY == "Delete" ]]; then
         echo "Updating ReclaimPolicy for $pv to Retain"
         kubectl patch pv $PV -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
       fi
     fi
   done
   

   Esegui lo script con il parametro namespace per specificare lo spazio dei nomi del cluster ./PatchReclaimPolicy.sh <namespace>.

2. Ottieni un elenco di tutti i PVC nello spazio dei nomi ordinato per creationTimestamp eseguendo il comando seguente. Imposta lo spazio dei nomi usando l'argomento --namespace insieme allo spazio dei nomi effettivo del cluster.

   kubectl get pvc -n <namespace> --sort-by=.metadata.creationTimestamp -o custom-columns=NAME:.metadata.name,CreationTime:.metadata.creationTimestamp,StorageClass:.spec.storageClassName,Size:.spec.resources.requests.storage
   

   Questo passaggio è utile se disponi di un numero elevato di PVs che devono essere migrati e vuoi eseguire la migrazione un po’ per volta. L'esecuzione di questo comando ti consente di identificare quali PVC sono stati creati in un determinato intervallo di tempo. Quando esegui lo script CreatePV.sh, due dei parametri rappresentano l'ora di inizio e l'ora di fine che ti permettono di eseguire la migrazione dei PVC solo in tale periodo di tempo.

3. Crea un file denominato CreatePV.sh e copialo nel codice seguente. Lo script effettua le operazioni seguenti:

   • Crea un nuovo oggetto PersistentVolume con nome existing-pv-csi per tutti i PersistentVolumes negli spazi dei nomi per la classe di archiviazione storageClassName (Storage class).
   • Configura il nuovo nome del PVC come existing-pvc-csi.
   • Crea un nuovo PVC con il nome PV da te specificato.

   #!/bin/bash
   #kubectl get pvc -n <namespace> --sort-by=.metadata.creationTimestamp -o custom-columns=NAME:.metadata.name,CreationTime:.metadata.creationTimestamp,StorageClass:.spec.storageClassName,Size:.spec.resources.requests.storage
   # TimeFormat 2022-04-20T13:19:56Z
   NAMESPACE=$1
   FILENAME=$(date +%Y%m%d%H%M)-$NAMESPACE
   EXISTING_STORAGE_CLASS=$2
   STORAGE_CLASS_NEW=$3
   STARTTIMESTAMP=$4
   ENDTIMESTAMP=$5
   i=1
   for PVC in $(kubectl get pvc -n $NAMESPACE | awk '{ print $1}'); do
     # Ignore first record as it contains header
     if [ $i -eq 1 ]; then
       i=$((i + 1))
     else
       PVC_CREATION_TIME=$(kubectl get pvc  $PVC -n $NAMESPACE -o jsonpath='{.metadata.creationTimestamp}')
       if [[ $PVC_CREATION_TIME >= $STARTTIMESTAMP ]]; then
         if [[ $ENDTIMESTAMP > $PVC_CREATION_TIME ]]; then
           PV="$(kubectl get pvc $PVC -n $NAMESPACE -o jsonpath='{.spec.volumeName}')"
           RECLAIM_POLICY="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.persistentVolumeReclaimPolicy}')"
           STORAGECLASS="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.storageClassName}')"
           echo $PVC
           RECLAIM_POLICY="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.persistentVolumeReclaimPolicy}')"
           if [[ $RECLAIM_POLICY == "Retain" ]]; then
             if [[ $STORAGECLASS == $EXISTING_STORAGE_CLASS ]]; then
               STORAGE_SIZE="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.capacity.storage}')"
               SKU_NAME="$(kubectl get storageClass $STORAGE_CLASS_NEW -o jsonpath='{.parameters.skuname}')"
               DISK_URI="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.azureDisk.diskURI}')"
               PERSISTENT_VOLUME_RECLAIM_POLICY="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.persistentVolumeReclaimPolicy}')"
   
               cat >$PVC-csi.yaml <<EOF
       apiVersion: v1
       kind: PersistentVolume
       metadata:
         annotations:
           pv.kubernetes.io/provisioned-by: disk.csi.azure.com
         name: $PV-csi
       spec:
         accessModes:
         - ReadWriteOnce
         capacity:
           storage: $STORAGE_SIZE
         claimRef:
           apiVersion: v1
           kind: PersistentVolumeClaim
           name: $PVC-csi
           namespace: $NAMESPACE
         csi:
           driver: disk.csi.azure.com
           volumeAttributes:
             csi.storage.k8s.io/pv/name: $PV-csi
             csi.storage.k8s.io/pvc/name: $PVC-csi
             csi.storage.k8s.io/pvc/namespace: $NAMESPACE
             requestedsizegib: "$STORAGE_SIZE"
             skuname: $SKU_NAME
           volumeHandle: $DISK_URI
         persistentVolumeReclaimPolicy: $PERSISTENT_VOLUME_RECLAIM_POLICY
         storageClassName: $STORAGE_CLASS_NEW
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: $PVC-csi
     namespace: $NAMESPACE
   spec:
     accessModes:
       - ReadWriteOnce
     storageClassName: $STORAGE_CLASS_NEW
     resources:
       requests:
         storage: $STORAGE_SIZE
     volumeName: $PV-csi
   EOF
               kubectl apply -f $PVC-csi.yaml
               LINE="PVC:$PVC,PV:$PV,StorageClassTarget:$STORAGE_CLASS_NEW"
               printf '%s\n' "$LINE" >>$FILENAME
             fi
           fi
         fi
       fi
     fi
   done
   

4. Per creare un nuovo PersistentVolume per tutti i PersistentVolumes nello spazio dei nomi , esegui lo script CreatePV.sh con i parametri seguenti:

   • namespace - Lo spazio dei nomi del cluster
   • sourceStorageClass - La StorageClass basata su driver di archiviazione intree
   • targetCSIStorageClass - La StorageClass basata su driver di archiviazione CSI, che può essere una delle classi di archiviazione predefinite con provisioner impostato su disk.csi.azure.com o file.csi.azure.com. In alternativa, puoi creare una classe di archiviazione personalizzata purché sia impostata su uno di questi due provisioner.
   • startTimeStamp - Specifica un'ora di inizio prima dell'ora di creazione del PVC nel formato aaaa-mm-ggthh:mm:ssz
   • endTimeStamp - Specifica un’ora di fine nel formato aaaa-mm-ggthh:mm:ssz.

   ./CreatePV.sh <namespace> <sourceIntreeStorageClass> <targetCSIStorageClass> <startTimestamp> <endTimestamp>
   

5. Aggiorna l'applicazione per usare il nuovo PVC.

Creare un volume dinamico

Usando questa opzione, crei dinamicamente un volume persistente da una richiesta di volume persistente.

Questo approccio offre i vantaggi seguenti:

• È meno rischioso perché tutti i nuovi oggetti vengono creati mantenendo al tempo stesso altre copie con snapshot.

• Non è necessario costruire i PV separatamente e aggiungere il nome del volume nel manifesto di PVC.

Le seguenti considerazioni sono importanti da valutare:

• Anche se questo approccio è meno rischioso, crea più oggetti che aumentano i costi di archiviazione.

• Durante la creazione dei nuovi volumi, l'applicazione non è disponibile.

• I passaggi di eliminazione devono essere eseguiti con cautela. I blocchi di risorse temporanei possono essere applicati al gruppo di risorse fino al completamento della migrazione e al completamento della verifica dell'applicazione.

• Eseguire la convalida/verifica dei dati quando vengono creati nuovi dischi da snapshot.

Migrazione

Prima di procedere, verifica quanto segue:

• Per carichi di lavoro specifici in cui i dati vengono scritti in memoria prima di essere scritti su disco, l'applicazione deve essere arrestata per consentire lo scaricamento dei dati in memoria su disco.

• VolumeSnapshot la classe deve esistere come illustrato nel seguente esempio YAML:

  apiVersion: snapshot.storage.k8s.io/v1
  kind: VolumeSnapshotClass
  metadata:
    name: custom-disk-snapshot-sc
  driver: disk.csi.azure.com
  deletionPolicy: Delete
  parameters:
    incremental: "false"
  

1. Ottieni un elenco di tutti i PVC in uno specifico spazio dei nomi ordinato per creationTimestamp eseguendo il comando seguente. Imposta lo spazio dei nomi usando l'argomento --namespace insieme allo spazio dei nomi effettivo del cluster.

   kubectl get pvc --namespace <namespace> --sort-by=.metadata.creationTimestamp -o custom-columns=NAME:.metadata.name,CreationTime:.metadata.creationTimestamp,StorageClass:.spec.storageClassName,Size:.spec.resources.requests.storage
   

   Questo passaggio è utile se disponi di un numero elevato di PVs che devono essere migrati e vuoi eseguire la migrazione un po’ per volta. L'esecuzione di questo comando ti consente di identificare quali PVC sono stati creati in un determinato intervallo di tempo. Quando esegui lo script MigrateCSI.sh, due dei parametri rappresentano l'ora di inizio e l'ora di fine che ti permettono di eseguire la migrazione dei PVC solo in tale periodo di tempo.

2. Crea un file denominato MigrateToCSI.sh e copialo nel codice seguente. Lo script effettua le operazioni seguenti:

   • Crea uno snapshot completo del disco usando l'interfaccia della riga di comando di Azure
   • Crea VolumesnapshotContent
   • Crea VolumeSnapshot
   • Crea un nuovo PVC da VolumeSnapshot
   • Crea un nuovo file con il nome file <namespace>-timestamp, che contiene un elenco di tutte le risorse precedenti che devono essere pulite.

   #!/bin/bash
   #kubectl get pvc -n <namespace> --sort-by=.metadata.creationTimestamp -o custom-columns=NAME:.metadata.name,CreationTime:.metadata.creationTimestamp,StorageClass:.spec.storageClassName,Size:.spec.resources.requests.storage
   # TimeFormat 2022-04-20T13:19:56Z
   NAMESPACE=$1
   FILENAME=$NAMESPACE-$(date +%Y%m%d%H%M)
   EXISTING_STORAGE_CLASS=$2
   STORAGE_CLASS_NEW=$3
   VOLUME_STORAGE_CLASS=$4
   START_TIME_STAMP=$5
   END_TIME_STAMP=$6
   i=1
   for PVC in $(kubectl get pvc -n $NAMESPACE | awk '{ print $1}'); do
     # Ignore first record as it contains header
     if [ $i -eq 1 ]; then
       i=$((i + 1))
     else
       PVC_CREATION_TIME=$(kubectl get pvc $PVC -n $NAMESPACE -o jsonpath='{.metadata.creationTimestamp}')
       if [[ $PVC_CREATION_TIME > $START_TIME_STAMP ]]; then
         if [[ $END_TIME_STAMP > $PVC_CREATION_TIME ]]; then
           PV="$(kubectl get pvc $PVC -n $NAMESPACE -o jsonpath='{.spec.volumeName}')"
           RECLAIM_POLICY="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.persistentVolumeReclaimPolicy}')"
           STORAGE_CLASS="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.storageClassName}')"
           echo $PVC
           RECLAIM_POLICY="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.persistentVolumeReclaimPolicy}')"
           if [[ $STORAGE_CLASS == $EXISTING_STORAGE_CLASS ]]; then
             STORAGE_SIZE="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.capacity.storage}')"
             SKU_NAME="$(kubectl get storageClass $STORAGE_CLASS_NEW -o jsonpath='{.parameters.skuname}')"
             DISK_URI="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.azureDisk.diskURI}')"
             TARGET_RESOURCE_GROUP="$(cut -d'/' -f5 <<<"$DISK_URI")"
             echo $DISK_URI
             SUBSCRIPTION_ID="$(echo $DISK_URI | grep -o 'subscriptions/[^/]*' | sed 's#subscriptions/##g')"
             echo $TARGET_RESOURCE_GROUP
             PERSISTENT_VOLUME_RECLAIM_POLICY="$(kubectl get pv $PV -n $NAMESPACE -o jsonpath='{.spec.persistentVolumeReclaimPolicy}')"
             az snapshot create --resource-group $TARGET_RESOURCE_GROUP --name $PVC-$FILENAME --source "$DISK_URI" --subscription ${SUBSCRIPTION_ID}
             SNAPSHOT_PATH=$(az snapshot list --resource-group $TARGET_RESOURCE_GROUP --query "[?name == '$PVC-$FILENAME'].id | [0]" --subscription ${SUBSCRIPTION_ID})
             SNAPSHOT_HANDLE=$(echo "$SNAPSHOT_PATH" | tr -d '"')
             echo $SNAPSHOT_HANDLE
             sleep 10
             # Create Restore File
             cat <<EOF >$PVC-csi.yml
       apiVersion: snapshot.storage.k8s.io/v1
       kind: VolumeSnapshotContent
       metadata:
         name: $PVC-$FILENAME
       spec:
         deletionPolicy: 'Delete'
         driver: 'disk.csi.azure.com'
         volumeSnapshotClassName: $VOLUME_STORAGE_CLASS
         source:
           snapshotHandle: $SNAPSHOT_HANDLE
         volumeSnapshotRef:
           apiVersion: snapshot.storage.k8s.io/v1
           kind: VolumeSnapshot
           name: $PVC-$FILENAME
           namespace: $1
   ---
       apiVersion: snapshot.storage.k8s.io/v1
       kind: VolumeSnapshot
       metadata:
         name: $PVC-$FILENAME
         namespace: $1
       spec:
         volumeSnapshotClassName: $VOLUME_STORAGE_CLASS
         source:
           volumeSnapshotContentName: $PVC-$FILENAME
   ---
       apiVersion: v1
       kind: PersistentVolumeClaim
       metadata:
         name: csi-$PVC
         namespace: $1
       spec:
         accessModes:
         - ReadWriteOnce
         storageClassName: $STORAGE_CLASS_NEW
         resources:
           requests:
             storage: $STORAGE_SIZE
         dataSource:
           name: $PVC-$FILENAME
           kind: VolumeSnapshot
           apiGroup: snapshot.storage.k8s.io
   
   EOF
             kubectl create -f $PVC-csi.yml
             LINE="OLDPVC:$PVC,OLDPV:$PV,VolumeSnapshotContent:volumeSnapshotContent-$FILENAME,VolumeSnapshot:volumesnapshot$FILENAME,OLDdisk:$DISK_URI"
             printf '%s\n' "$LINE" >>$FILENAME
           fi
         fi
       fi
     fi
   done
   

3. Per eseguire la migrazione dei volumi del disco, esegui lo script MigrateToCSI.sh con i parametri seguenti:

   • namespace - Lo spazio dei nomi del cluster
   • sourceStorageClass - La StorageClass basata su driver di archiviazione intree
   • targetCSIStorageClass - StorageClass basato su driver di archiviazione CSI
   • volumeSnapshotClass - Nome della classe snapshot del volume. Ad esempio, custom-disk-snapshot-sc.
   • startTimeStamp - Specifica un'ora di inizio nel formato aaaa-mm-ggthh:mm:ssz.
   • endTimeStamp - Specifica un’ora di fine nel formato aaaa-mm-ggthh:mm:ssz.

   ./MigrateToCSI.sh <namespace> <sourceStorageClass> <TargetCSIstorageClass> <VolumeSnapshotClass> <startTimestamp> <endTimestamp>
   

4. Aggiorna l'applicazione per usare il nuovo PVC.

5. Elimina manualmente le risorse precedenti, tra cui PVC/PV intree, VolumeSnapshot e VolumeSnapshotContent. In caso contrario, il mantenimento di PVC/PC nella struttura e di oggetti snapshot comporterà costi superiori.

Esegui la migrazione dei volumi di condivisione file

La migrazione da intree a CSI è supportata creando un volume statico:

• Non è necessario pulire la configurazione originale usando la classe di archiviazione nell'albero.
• Rischio basso perché si esegue solo un'eliminazione logica di Kubernetes PV/PVC, i dati fisici effettivi non vengono eliminati.
• Non sono previsti costi aggiuntivi perché non è necessario creare oggetti Azure supplementari come condivisioni di file e così via.

Migrazione

1. Aggiorna il PV esistente ReclaimPolicy da Delete a Retain eseguendo il comando seguente:

   kubectl patch pv pvName -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
   

   Sostituisci pvName con il nome del PersistentVolume da te selezionato. In alternativa, se vuoi aggiornare reclaimPolicy per più PVs, crea un file denominato patchReclaimPVs.sh e copialo nel codice seguente.

   #!/bin/bash
   # Patch the Persistent Volume in case ReclaimPolicy is Delete
   namespace=$1
   i=1
   for pvc in $(kubectl get pvc -n $namespace | awk '{ print $1}'); do
     # Ignore first record as it contains header
     if [ $i -eq 1 ]; then
       i=$((i + 1))
     else
       pv="$(kubectl get pvc $pvc -n $namespace -o jsonpath='{.spec.volumeName}')"
       reclaimPolicy="$(kubectl get pv $pv -n $namespace -o jsonpath='{.spec.persistentVolumeReclaimPolicy}')"
       echo "Reclaim Policy for Persistent Volume $pv is $reclaimPolicy"
       if [[ $reclaimPolicy == "Delete" ]]; then
         echo "Updating ReclaimPolicy for $pv to Retain"
         kubectl patch pv $pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
       fi
     fi
   done
   

   Esegui lo script con il parametro namespace per specificare lo spazio dei nomi del cluster ./PatchReclaimPolicy.sh <namespace>.

2. Crea una nuova Storage Class con il provisioner impostato su file.csi.azure.comoppure puoi usare una delle classi di archiviazione predefinite con il provisioner di file CSI.

3. Ottieni secretName e shareName dai PersistentVolumes esistenti eseguendo il comando seguente:

   kubectl describe pv pvName
   

4. Crea un nuovo PV usando la nuova StorageClass e shareName e secretName dal PV intree. Crea un file denominato azurefile-mount-pv.yaml e copialo nel codice seguente. In csi, aggiorna resourceGroup, volumeHandlee shareName. Per le opzioni di montaggio, il valore predefinito per fileMode edirMode è 0777.

   Il valore predefinito per fileMode e dirMode è 0777.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     annotations:
       pv.kubernetes.io/provisioned-by: file.csi.azure.com
     name: azurefile
   spec:
     capacity:
       storage: 5Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     storageClassName: azurefile-csi
     csi:
       driver: file.csi.azure.com
       readOnly: false
       volumeHandle: unique-volumeid  # make sure volumeid is unique for every identical share in the cluster
       volumeAttributes:
         resourceGroup: EXISTING_RESOURCE_GROUP_NAME  # optional, only set this when storage account is not in the same resource group as the cluster nodes
         shareName: aksshare
       nodeStageSecretRef:
         name: azure-secret
         namespace: default
     mountOptions:
       - dir_mode=0777
       - file_mode=0777
       - uid=0
       - gid=0
       - mfsymlinks
       - cache=strict
       - nosharesock
       - nobrl  # disable sending byte range lock requests to the server and for applications which have challenges with posix locks
   

5. Crea un file denominato azurefile-mount-pvc.yaml con un PersistentVolumeClaim che usa il PersistentVolume utilizzando il codice seguente.

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: azurefile
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: azurefile-csi
     volumeName: azurefile
     resources:
       requests:
         storage: 5Gi
   

6. Usa il comando kubectl per creare il PersistentVolume.

   kubectl apply -f azurefile-mount-pv.yaml
   

7. Usa il comando kubectl per creare il PersistentVolumeClaim.

   kubectl apply -f azurefile-mount-pvc.yaml
   

8. Verifica che PersistentVolumeClaim sia stato creato e associato al PersistentVolume eseguendo il comando seguente.

   kubectl get pvc azurefile
   

   L'output è simile al seguente:

   NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
   

9. Aggiorna la specifica del tuo contenitore per fare riferimento al tuo PersistentVolumeClaim e aggiorna il pod. Ad esempio, copia il codice seguente e crea un file denominato azure-files-pod.yaml.

   ...
     volumes:
     - name: azure
       persistentVolumeClaim:
         claimName: azurefile
   

10. La specifica del pod non può essere aggiornata sul posto. Usa i seguenti comandi kubectl per eliminare e quindi ricreare il pod.

    kubectl delete pod mypod
    

    kubectl apply -f azure-files-pod.yaml
    

Passaggi successivi

• Per ulteriori informazioni sulle procedure consigliate per l'archiviazione, vedi Procedure consigliate per l'archiviazione e i backup nel servizio Azure Kubernetes.
• Proteggi i tuoi PVs basati su driver CSI appena migrati eseguendo il backup con Backup di Azure per il servizio Azure Kubernetes.