Migrowanie z klasy magazynu w drzewie do sterowników CSI w usłudze Azure Kubernetes Service (AKS)

Implementacja sterownika interfejsu magazynu kontenerów (CSI) została wprowadzona w usłudze Azure Kubernetes Service (AKS) począwszy od wersji 1.21. Dzięki wdrożeniu i użyciu interfejsu CSI jako standardu istniejące obciążenia stanowe korzystające z woluminów trwałych w drzewie powinny zostać zmigrowane lub uaktualnione do używania sterownika CSI.

Aby ten proces był jak najprostszy i aby zapewnić brak utraty danych, ten artykuł zawiera różne opcje migracji. Te opcje obejmują skrypty, które ułatwiają bezproblemową migrację z poziomu drzewa do dysków platformy Azure i sterowników CSI usługi Azure Files.

Zanim rozpoczniesz

• Interfejs wiersza polecenia platformy Azure w wersji 2.37.0 lub nowszej. Uruchom polecenie az --version , aby znaleźć wersję i uruchomić polecenie az upgrade , aby uaktualnić wersję. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.
• Administratorzy platformy Kubectl i klastra mają dostęp do tworzenia, pobierania, wyświetlania listy, usuwania dostępu do zawartości PVC lub PV, migawki woluminu lub migawki woluminu. W przypadku klastra z włączoną kontrolą dostępu opartą na rolach firmy Microsoft jesteś członkiem roli Administracja klastra RBAC usługi Azure Kubernetes Service.

Migrowanie woluminów dysku

Uwaga

Etykiety failure-domain.beta.kubernetes.io/zone i failure-domain.beta.kubernetes.io/region zostały wycofane w usłudze AKS 1.24 i usunięte w wersji 1.28. Jeśli istniejące woluminy trwałe nadal używają węzłaAffinity pasujące do tych dwóch etykiet, musisz zmienić je na topology.kubernetes.io/zone i topology.kubernetes.io/region etykiety w nowym ustawieniu trwałego woluminu.

Migracja z in-tree do CSI jest obsługiwana przy użyciu dwóch opcji migracji:

• Tworzenie woluminu statycznego
• Tworzenie woluminu dynamicznego

Tworzenie woluminu statycznego

Korzystając z tej opcji, tworzysz pv przez statyczne przypisanie claimRef do nowego PCV, który utworzysz później, i określ parametr volumeName dla persistentVolumeClaim.

Korzyści wynikające z tego podejścia są następujące:

• Jest to proste i można to zautomatyzować.
• Nie trzeba czyścić oryginalnej konfiguracji przy użyciu klasy magazynu w drzewie.
• Niskie ryzyko, ponieważ przeprowadzasz tylko logiczne usunięcie obiektu PV/PVC platformy Kubernetes — nie są usuwane rzeczywiste dane fizyczne.
• Nie są naliczane dodatkowe koszty wynikające z braku konieczności tworzenia dodatkowych obiektów platformy Azure, takich jak dysk, migawki itp.

Poniżej przedstawiono ważne zagadnienia, które należy wziąć pod uwagę:

• Przejście do woluminów statycznych z oryginalnych woluminów w stylu dynamicznym wymaga ręcznego konstruowania obiektów PV i zarządzania nimi dla wszystkich opcji.
• Potencjalny przestój aplikacji podczas ponownego wdrażania nowej aplikacji z odwołaniem do nowego obiektu PVC.

Migracja

1. Zaktualizuj istniejącą sieć PV ReclaimPolicy z Usuń, aby zachować, uruchamiając następujące polecenie:

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

   Zastąp ciąg pvName nazwą wybranego elementu PersistentVolume. Alternatywnie, jeśli chcesz zaktualizować reclaimPolicy dla wielu telewizorów, utwórz plik o nazwie patchReclaimPVs.sh i skopiuj poniższy kod.

   #!/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
   

   Wykonaj skrypt z parametrem , namespace aby określić przestrzeń nazw ./PatchReclaimPolicy.sh <namespace>klastra .

2. Pobierz listę wszystkich kontrolerów PVC w przestrzeni nazw posortowanych według parametru creationTimestamp , uruchamiając następujące polecenie. Ustaw przestrzeń nazw przy użyciu argumentu --namespace wraz z rzeczywistą przestrzenią nazw klastra.

   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
   

   Ten krok jest przydatny, jeśli masz dużą liczbę telewizorów, które muszą zostać zmigrowane i chcesz przeprowadzić migrację kilku naraz. Uruchomienie tego polecenia umożliwia określenie, które karty PVC zostały utworzone w danym przedziale czasu. Po uruchomieniu skryptu CreatePV.sh dwa parametry to czas rozpoczęcia i godzina zakończenia, które umożliwiają migrację tylko kontrolerów PVC w tym okresie.

3. Utwórz plik o nazwie CreatePV.sh i skopiuj go w poniższym kodzie. Skrypt wykonuje następujące czynności:

   • Tworzy nowy element PersistentVolume o nazwie existing-pv-csi dla wszystkich trwałychvolumes w przestrzeniach nazw dla klasy storageClassNamemagazynu .
   • Skonfiguruj nową nazwę PVC jako existing-pvc-csi.
   • Tworzy nowy PVC o podanej nazwie PV.

   #!/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. Aby utworzyć nową wartość PersistentVolume dla wszystkich trwałychvolumes w przestrzeni nazw, wykonaj skrypt CreatePV.sh z następującymi parametrami:

   • namespace — Przestrzeń nazw klastra
   • sourceStorageClass — Klasa StorageClass oparta na sterownikach magazynu w drzewie
   • targetCSIStorageClass — Klasa StorageClass oparta na sterownikach CSI, która może być jedną z domyślnych klas magazynu, które mają aprowizator ustawiony na disk.csi.azure.com lub file.csi.azure.com. Możesz też utworzyć niestandardową klasę magazynu, o ile jest ustawiona na jedną z tych dwóch aprowizacji.
   • startTimeStamp - Podaj godzinę rozpoczęcia przed czasem utworzenia PVC w formacie rrrr-mm-ddthh:mm:ssz
   • endTimeStamp - Podaj godzinę zakończenia w formacie rrrr-mm-ddthh:mm:ssz.

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

5. Zaktualizuj aplikację, aby korzystała z nowego PVC.

Tworzenie woluminu dynamicznego

Ta opcja umożliwia dynamiczne tworzenie woluminu trwałego na podstawie trwałego oświadczenia woluminu.

Korzyści wynikające z tego podejścia są następujące:

• Jest to mniej ryzykowne, ponieważ wszystkie nowe obiekty są tworzone przy zachowywaniu pozostałych kopii w migawkach.

• Nie trzeba oddzielnie konstruować obiektów PV i dodawać nazwy woluminu w manifeście obiektu PVC.

Poniżej przedstawiono ważne zagadnienia, które należy wziąć pod uwagę:

• Chociaż takie podejście jest mniej ryzykowne, powoduje utworzenie wielu obiektów, co zwiększy koszty magazynowania.

• Podczas tworzenia nowych woluminów aplikacja jest niedostępna.

• Kroki usuwania należy wykonywać z ostrożnością. Tymczasowe blokady zasobów można zastosować do grupy zasobów do momentu zakończenia migracji i pomyślnego zweryfikowania aplikacji.

• Przeprowadź weryfikację/sprawdzanie poprawności danych, ponieważ nowe dyski są tworzone na podstawie migawek.

Migracja

Przed kontynuowaniem sprawdź następujące kwestie:

• W przypadku określonych obciążeń, w których dane są zapisywane w pamięci przed zapisaniem na dysku, należy zatrzymać aplikację i umożliwić opróżnianie danych w pamięci na dysk.

• VolumeSnapshot klasa powinna istnieć, jak pokazano w poniższym przykładzie 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. Pobierz listę wszystkich kontrolerów PVC w określonej przestrzeni nazw posortowanej według parametru creationTimestamp , uruchamiając następujące polecenie. Ustaw przestrzeń nazw przy użyciu argumentu --namespace wraz z rzeczywistą przestrzenią nazw klastra.

   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
   

   Ten krok jest przydatny, jeśli masz dużą liczbę telewizorów, które muszą zostać zmigrowane i chcesz przeprowadzić migrację kilku naraz. Uruchomienie tego polecenia umożliwia określenie, które karty PVC zostały utworzone w danym przedziale czasu. Po uruchomieniu skryptu MigrateCSI.sh dwa parametry to czas rozpoczęcia i godzina zakończenia, które umożliwiają migrację tylko kontrolerów PVC w tym okresie.

2. Utwórz plik o nazwie MigrateToCSI.sh i skopiuj go w poniższym kodzie. Skrypt wykonuje następujące czynności:

   • Tworzy pełną migawkę dysku przy użyciu interfejsu wiersza polecenia platformy Azure
   • Tworzy VolumesnapshotContent
   • Tworzy VolumeSnapshot
   • Tworzy nowy element PVC na podstawie VolumeSnapshot
   • Tworzy nowy plik z nazwą pliku <namespace>-timestamp, który zawiera listę wszystkich starych zasobów, które należy wyczyścić.

   #!/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. Aby przeprowadzić migrację woluminów dysków, wykonaj skrypt MigrateToCSI.sh z następującymi parametrami:

   • namespace — Przestrzeń nazw klastra
   • sourceStorageClass — Klasa StorageClass oparta na sterownikach magazynu w drzewie
   • targetCSIStorageClass — Klasa StorageClass oparta na sterownikach CSI
   • volumeSnapshotClass - Nazwa klasy migawki woluminu. Na przykład custom-disk-snapshot-sc.
   • startTimeStamp - Podaj godzinę rozpoczęcia w formacie rrrr-mm-ddthh:mm:ssz.
   • endTimeStamp - Podaj godzinę zakończenia w formacie rrrr-mm-ddthh:mm:ssz.

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

4. Zaktualizuj aplikację, aby korzystała z nowego PVC.

5. Ręcznie usuń starsze zasoby, w tym w drzewie PVC/PV, VolumeSnapshot i VolumeSnapshotContent. W przeciwnym razie utrzymanie obiektów PVC/PC i migawek w drzewie spowoduje wygenerowanie wyższych kosztów.

Migrowanie woluminów udziału plików

Migracja z drzewa do CSI jest obsługiwana przez utworzenie woluminu statycznego:

• Nie trzeba czyścić oryginalnej konfiguracji przy użyciu klasy magazynu w drzewie.
• Niskie ryzyko, ponieważ przeprowadzasz tylko logiczne usunięcie obiektu PV/PVC platformy Kubernetes — nie są usuwane rzeczywiste dane fizyczne.
• Brak dodatkowych kosztów poniesionych w wyniku braku konieczności tworzenia dodatkowych obiektów platformy Azure, takich jak udziały plików itp.

Migracja

1. Zaktualizuj istniejącą sieć PV ReclaimPolicy z Usuń, aby zachować, uruchamiając następujące polecenie:

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

   Zastąp ciąg pvName nazwą wybranego elementu PersistentVolume. Alternatywnie, jeśli chcesz zaktualizować reclaimPolicy dla wielu telewizorów, utwórz plik o nazwie patchReclaimPVs.sh i skopiuj poniższy kod.

   #!/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
   

   Wykonaj skrypt z parametrem , namespace aby określić przestrzeń nazw ./PatchReclaimPolicy.sh <namespace>klastra .

2. Utwórz nową klasę magazynu z ustawieniem aprowizacji na file.csi.azure.com, lub możesz użyć jednej z domyślnych klas StorageClasses z aprowizatorem plików CSI.

3. Pobierz elementy secretName i shareName z istniejących elementów PersistentVolumes , uruchamiając następujące polecenie:

   kubectl describe pv pvName
   

4. Utwórz nową sieć PV przy użyciu nowej klasy StorageClass i shareNamesecretName i z obszaru PV w drzewie. Utwórz plik o nazwie azurefile-mount-pv.yaml i skopiuj go w poniższym kodzie. W obszarze csi, zaktualizuj volumeHandleresourceGroup, i shareName. W przypadku opcji instalacji wartość domyślna parametru fileMode i dirMode to 0777.

   Wartość domyślna elementu fileMode i dirMode to 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
   

5. Utwórz plik o nazwie azurefile-mount-pvc.yaml z elementem PersistentVolumeClaim , który używa elementu PersistentVolume przy użyciu następującego kodu.

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

6. Użyj polecenia , kubectl aby utworzyć element PersistentVolume.

   kubectl apply -f azurefile-mount-pv.yaml
   

7. Użyj polecenia , kubectl aby utworzyć element PersistentVolumeClaim.

   kubectl apply -f azurefile-mount-pvc.yaml
   

8. Sprawdź, czy element PersistentVolumeClaim został utworzony i powiązany z elementem PersistentVolume , uruchamiając następujące polecenie.

   kubectl get pvc azurefile
   

   Dane wyjściowe są podobne do następujących:

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

9. Zaktualizuj specyfikację kontenera, aby odwołać się do elementu PersistentVolumeClaim i zaktualizować zasobnik. Na przykład skopiuj następujący kod i utwórz plik o nazwie azure-files-pod.yaml.

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

10. Nie można zaktualizować specyfikacji zasobnika. Użyj następujących kubectl poleceń, aby usunąć, a następnie ponownie utworzyć zasobnik.

    kubectl delete pod mypod
    

    kubectl apply -f azure-files-pod.yaml
    

Następne kroki

• Aby uzyskać więcej informacji na temat najlepszych rozwiązań dotyczących magazynu, zobacz Best practices for storage and backups in Azure Kubernetes Service (Najlepsze rozwiązania dotyczące magazynu i tworzenia kopii zapasowych w usłudze Azure Kubernetes Service).
• Chroń nowo zmigrowane maszyny wirtualne oparte na sterownikach CSI, tworząc ich kopię zapasową przy użyciu usługi Azure Backup for AKS.