Migrieren von einer strukturinternen Speicherklasse zu CSI-Treibern in Azure Kubernetes Service (AKS)

Die Implementierung des CSI-Treibers (Container Storage Interface) wurde in Azure Kubernetes Service (AKS) ab Version 1.21 eingeführt. Durch die Einführung und Verwendung von CSI als Standard sollten Ihre vorhandenen zustandsbehafteten Workloads, die strukturintern persistente Volumes (Persistent Volumes, PVs) verwenden, zum CSI-Treiber migriert oder für dessen Verwendung aktualisiert werden.

Um diesen Prozess so einfach wie möglich zu gestalten und sicherzustellen, dass keine Daten verloren gehen, stellt dieser Artikel verschiedene Migrationsoptionen vor. Diese Optionen umfassen Skripts, um eine reibungslose Migration von strukturintern persistenten Volumes zu CSI-Treibern von Azure Disks und Azure Files sicherzustellen.

Voraussetzungen

  • Die Azure CLI ab Version 2.37.0 Führen Sie az --version aus, um die Version zu finden, und führen Sie az upgrade aus, um ein Upgrade für die Version durchzuführen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.
  • Kubectl- und Clusteradministratoren verfügen über Zugriff, um den Zugriff auf einen PVC oder ein PV, eine Volumemomentaufnahme oder den Inhalt einer Volumemomentaufnahme zu erstellen, abzurufen, aufzulisten und zu löschen. Für einen Cluster mit Microsoft Entra RBAC sind Sie Mitglied der Rolle RBAC-Clusteradministrator für Azure Kubernetes Service.

Migrieren von Datenträgervolumes

Hinweis

Die Bezeichnungen failure-domain.beta.kubernetes.io/zone und failure-domain.beta.kubernetes.io/region wurden in AKS 1.24 als veraltet gekennzeichnet und in Version 1.28 entfernt. Wenn Ihre vorhandenen persistenten Volumes weiterhin Knotenaffinität mit diesen beiden Bezeichnungen verwenden, müssen Sie diese in der neuen Einstellung für die persistenten Volumes in topology.kubernetes.io/zone und topology.kubernetes.io/region ändern.

Die Migration von strukturintern zu CSI wird mithilfe von zwei Migrationsoptionen unterstützt:

  • Erstellen eines statischen Volumes
  • Erstellen eines dynamischen Volumes

Erstellen eines statischen Volumes

Mit dieser Option erstellen Sie ein PV, indem Sie claimRef einem neuen PVC statisch zuweisen, den Sie später erstellen, und den volumeName für persistentVolumeClaim angeben.

Workflowdiagramm: Statische Volumes

Diese Methode bietet folgende Vorteile:

  • Sie ist einfach und kann automatisiert werden.
  • Es ist nicht erforderlich, die ursprüngliche Konfiguration mithilfe der strukturinternen Speicherklasse zu bereinigen.
  • Geringes Risiko, da Sie nur eine logische Löschung von Kubernetes PV/PVC durchführen, die tatsächlichen physischen Daten werden nicht gelöscht.
  • Es entstehen keine zusätzlichen Kosten, da sie keine zusätzlichen Azure-Objekte wie Datenträger, Momentaufnahmen usw. erstellen müssen.

Im Folgenden finden Sie wichtige Überlegungen, die berücksichtigt werden müssen:

  • Der Übergang zu statischen Volumes von ursprünglichen Volumes im dynamischen Stil erfordert das manuelle Erstellen und Verwalten von PV-Objekten für alle Optionen.
  • Potenzielle Anwendungsdowntime beim erneuten Bereitstellen der neuen Anwendung mit Verweis auf das neue PVC-Objekt.

Migration

  1. Aktualisieren Sie das vorhandene PV ReclaimPolicy von Löschen auf Beibehalten, indem Sie den folgenden Befehl ausführen:

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

    Ersetzen Sie pvName durch den Namen des ausgewählten PersistentVolume. Wenn Sie die reclaimPolicy für mehrere PVs aktualisieren möchten, erstellen Sie alternativ eine Datei namens patchReclaimPVs.sh, und kopieren Sie den folgenden Codein diese Datei.

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

    Führen Sie das Skript mit dem namespace-Parameter aus, um den Clusternamespace ./PatchReclaimPolicy.sh <namespace>anzugeben.

  2. Rufen Sie eine Liste aller PVCs im Namespace ab, die nach creationTimestamp sortiert sind, indem Sie den folgenden Befehl ausführen. Legen Sie den Namespace mithilfe des --namespace-Arguments zusammen mit dem tatsächlichen Clusternamespace fest.

    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
    

    Dieser Schritt ist hilfreich, wenn Sie über eine große Anzahl von PVs verfügen, die migriert werden müssen, und Sie mehrere PVs gleichzeitig migrieren möchten. Wenn Sie diesen Befehl ausführen, können Sie ermitteln, welche PVCs in einem bestimmten Zeitraum erstellt wurden. Wenn Sie das Skript CreatePV.sh ausführen, sind zwei der Parameter die Startzeit und die Endzeit. Sie ermöglichen es Ihnen, die PVCs nur während dieses Zeitraums zu migrieren.

  3. Erstellen Sie eine Datei namens CreatePV.sh, und kopieren Sie den folgenden Code in diese Datei. Das Skript führt Folgendes aus:

    • Erstellt ein neues PersistentVolume mit dem Namen existing-pv-csi für alle PersistentVolumes in Namespaces für die Speicherklasse storageClassName.
    • Konfigurieren des neuen PVC-Namens als existing-pvc-csi.
    • Erstellt einen neuen PVC mit dem von Ihnen angegebenen PV-Namen.
    #!/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. Um ein neues PersistentVolume für alle PersistentVolumes im Namespace zu erstellen, führen Sie das Skript CreatePV.sh mit den folgenden Parametern aus:

    • namespace – Der Clusternamespace
    • sourceStorageClass – Die strukturinterne, auf dem Speichertreiber-basierende StorageClass
    • targetCSIStorageClass – Die auf dem CSI-Speichertreiber basierende StorageClass, bei der es sich entweder um eine der Standardspeicherklassen handeln kann, für die der Provisioner auf disk.csi.azure.com oder file.csi.azure.com festgelegt ist. Sie können auch eine benutzerdefinierte Speicherklasse erstellen, solange sie auf einen dieser beiden Provisioner festgelegt ist.
    • startTimeStamp: Geben Sie eine Startzeit vor der Erstellung des persistenten Volumeanspruchs (Persistent Volume Claim, PVC) im Format jjjj-mm-ttthh:mm:ssz an.
    • endTimeStamp – Gibt eine Endzeit im Format jjjj-mm-dddhh:mm:ssz an.
    ./CreatePV.sh <namespace> <sourceIntreeStorageClass> <targetCSIStorageClass> <startTimestamp> <endTimestamp>
    
  5. Aktualisiert Ihre Anwendung so, dass der neue PVC verwendet wird.

Erstellen eines dynamischen Volumes

Mit dieser Option erstellen Sie dynamisch ein persistentes Volume (Persistent Volume, PV) aus einem Anspruch eines persistenten Volumes (Persistent Volume Claim, PVC).

Workflowdiagramm: Dynamische Volumes

Diese Methode bietet folgende Vorteile:

  • Dies ist weniger riskant, weil alle neuen Objekte erstellt werden, während andere Kopien mit Momentaufnahmen beibehalten werden.

  • Es ist nicht erforderlich, PVs separat zu erstellen und den Volumenamen im PVC-Manifest hinzuzufügen.

Im Folgenden finden Sie wichtige Überlegungen, die berücksichtigt werden müssen:

  • Obwohl dieser Ansatz weniger riskant ist, werden mehrere Objekte erstellt, die Ihre Speicherkosten erhöhen.

  • Während der Erstellung der neuen Volumes ist Ihre Anwendung nicht verfügbar.

  • Löschschritte sollten mit Vorsicht ausgeführt werden. Temporäre Ressourcensperren können auf Ihre Ressourcengruppe angewendet werden, bis die Migration abgeschlossen und Ihre Anwendung erfolgreich überprüft wurde.

  • Führen Sie Datenvalidierung/-überprüfung aus, wenn neue Datenträger aus Momentaufnahmen erstellt werden.

Migration

Stellen Sie Folgendes sicher, bevor Sie fortfahren:

  • Bei bestimmten Workloads, bei denen Daten in den Arbeitsspeicher geschrieben werden, bevor sie auf den Datenträger geschrieben werden, sollte die Anwendung beendet werden, damit In-Memory-Daten auf den Datenträger übertragen werden können.

  • Die VolumeSnapshot-Klasse sollte vorhanden sein, wie im folgenden YAML-Beispielcode gezeigt:

    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. Rufen Sie eine Liste aller PVCs im angegebenen Namespace ab, die nach creationTimestamp sortiert sind, indem Sie den folgenden Befehl ausführen. Legen Sie den Namespace mithilfe des --namespace-Arguments zusammen mit dem tatsächlichen Clusternamespace fest.

    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
    

    Dieser Schritt ist hilfreich, wenn Sie über eine große Anzahl von PVs verfügen, die migriert werden müssen, und Sie mehrere PVs gleichzeitig migrieren möchten. Wenn Sie diesen Befehl ausführen, können Sie ermitteln, welche PVCs in einem bestimmten Zeitraum erstellt wurden. Wenn Sie das Skript MigrateCSI.sh ausführen, sind zwei der Parameter die Startzeit und die Endzeit. Sie ermöglichen es Ihnen, die PVCs nur während dieses Zeitraums zu migrieren.

  2. Erstellen Sie eine Datei namens MigrateToCSI.sh, und kopieren Sie den folgenden Code in diese Datei. Das Skript führt Folgendes aus:

    • Erstellt eine vollständige Datenträgermomentaufnahme mithilfe der Azure CLI
    • Erstellt VolumesnapshotContent
    • Erstellt VolumeSnapshot
    • Erstellt einen neuen PVC aus VolumeSnapshot
    • Erstellt eine neue Datei mit dem Dateinamen <namespace>-timestamp, die eine Liste aller alten Ressourcen enthält, die bereinigt werden müssen.
    #!/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. Führen Sie zum Migrieren der Datenträgervolumes das Skript MigrateToCSI.sh mit den folgenden Parametern aus:

    • namespace – Der Clusternamespace
    • sourceStorageClass – Die strukturinterne, auf dem Speichertreiber-basierende StorageClass
    • targetCSIStorageClass – Die auf dem CSI-Speichertreiber-basierende StorageClass
    • volumeSnapshotClass – Name der Volumemomentaufnahme-Klasse. Beispiel: custom-disk-snapshot-sc.
    • startTimeStamp – Gibt eine Startzeit im Format jjjj-mm-dddhh:mm:ssz an.
    • endTimeStamp – Gibt eine Endzeit im Format jjjj-mm-dddhh:mm:ssz an.
    ./MigrateToCSI.sh <namespace> <sourceStorageClass> <TargetCSIstorageClass> <VolumeSnapshotClass> <startTimestamp> <endTimestamp>
    
  4. Aktualisiert Ihre Anwendung so, dass der neue PVC verwendet wird.

  5. Löschen Sie manuell die älteren Ressourcen, einschließlich der strukturinternen PVC-/PV-, VolumeSnapshot- und VolumeSnapshotContent-Objekte. Andernfalls führt die Wartung der strukturinternen PVC-/PC- und Momentaufnahmeobjekte zu höheren Kosten.

Migrieren von Dateifreigabevolumes

Die Migration von strukturintern zu CSI wird durch die Erstellung eines statischen Volumes unterstützt.

  • Es ist nicht erforderlich, die ursprüngliche Konfiguration mithilfe der strukturinternen Speicherklasse zu bereinigen.
  • Geringes Risiko, da Sie nur eine logische Löschung von Kubernetes PV/PVC durchführen, die tatsächlichen physischen Daten werden nicht gelöscht.
  • Es entstehen keine zusätzlichen Kosten, da sie keine zusätzlichen Azure-Objekte wie Dateifreigaben usw. erstellen müssen.

Migration

  1. Aktualisieren Sie das vorhandene PV ReclaimPolicy von Löschen auf Beibehalten, indem Sie den folgenden Befehl ausführen:

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

    Ersetzen Sie pvName durch den Namen des ausgewählten PersistentVolume. Wenn Sie die reclaimPolicy für mehrere PVs aktualisieren möchten, erstellen Sie alternativ eine Datei namens patchReclaimPVs.sh, und kopieren Sie den folgenden Codein diese Datei.

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

    Führen Sie das Skript mit dem namespace-Parameter aus, um den Clusternamespace ./PatchReclaimPolicy.sh <namespace>anzugeben.

  2. Erstellen Sie eine neue Speicherklasse, wobei der Provisioner auf file.csi.azure.com festgelegt ist, oder verwenden Sie eine der Standardspeicherklassen mit dem CSI-Dateiprovisioner.

  3. Rufen Sie secretName und shareName aus den vorhandenen PersistentVolumes ab, indem Sie den folgenden Befehl ausführen:

    kubectl describe pv pvName
    
  4. Erstellen Sie ein neues PV mit der neuen StorageClass und shareName und secretName aus dem strukturinternen PV. Erstellen Sie eine Datei namens azurefile-mount-pv.yaml, und kopieren Sie den folgenden Code in diese Datei. Unter csi, aktualisieren Sie resourceGroup, volumeHandleund shareName. Der Standardwert für die Einbindeoptionen für fileMode und dirMode ist 0777.

    Der Standardwert für fileMode und dirMode lautet 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. Erstellen Sie mithilfe des folgenden Codes eine Datei namens azurefile-mount-pvc.yaml mit einem PersistentVolumeClaim, der PersistentVolume verwendet.

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: azurefile
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: azurefile-csi
      volumeName: azurefile
      resources:
        requests:
          storage: 5Gi
    
  6. Verwenden Sie den kubectl-Befehl, um das PersistentVolume zu erstellen.

    kubectl apply -f azurefile-mount-pv.yaml
    
  7. Verwenden Sie den kubectl-Befehl, um den PersistentVolumeClaim zu erstellen.

    kubectl apply -f azurefile-mount-pvc.yaml
    
  8. Führen Sie den folgenden Befehl aus, um sich zu vergewissern, dass PersistentVolumeClaim erstellt und an PersistentVolume gebunden wurde.

    kubectl get pvc azurefile
    

    Die Ausgabe sieht ungefähr so aus:

    NAME        STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    azurefile   Bound    azurefile   5Gi        RWX            azurefile      5s
    
  9. Aktualisieren Sie die Containerspezifikation so, dass auf PersistentVolumeClaim verwiesen und Ihr Pod aktualisiert wird. Kopieren Sie beispielsweise den folgenden Code, und erstellen Sie eine Datei namens azure-files-pod.yaml.

    ...
      volumes:
      - name: azure
        persistentVolumeClaim:
          claimName: azurefile
    
  10. Die Podspezifikation kann nicht direkt aktualisiert werden. Verwenden Sie die folgenden kubectl-Befehle, um den Pod zu löschen und dann neu zu erstellen.

    kubectl delete pod mypod
    
    kubectl apply -f azure-files-pod.yaml
    

Nächste Schritte