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

Artikel
01/11/2024

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.

Static volume workflow diagram.

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

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.

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.

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

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 PVC-Erstellungszeit im Format yyyy-mm-ddthh:mm:ssz
- endTimeStamp – Gibt eine Endzeit im Format jjjj-mm-dddhh:mm:ssz an.
```
./CreatePV.sh <namespace> <sourceIntreeStorageClass> <targetCSIStorageClass> <startTimestamp> <endTimestamp>
```
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).

Dynamic volume workflow diagram.

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"

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.

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

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>
```
Aktualisiert Ihre Anwendung so, dass der neue PVC verwendet wird.
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.

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

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"}}'

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

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.
Rufen Sie secretName und shareName aus den vorhandenen PersistentVolumes ab, indem Sie den folgenden Befehl ausführen:
```
kubectl describe pv pvName
```

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

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

Verwenden Sie den kubectl-Befehl, um das PersistentVolume zu erstellen.
```
kubectl apply -f azurefile-mount-pv.yaml
```
Verwenden Sie den kubectl-Befehl, um den PersistentVolumeClaim zu erstellen.
```
kubectl apply -f azurefile-mount-pvc.yaml
```

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

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

Weitere Informationen zu bewährten Methoden bei der Speicherung finden Sie unter Best Practices für Speicherung und Sicherungen in Azure Kubernetes Service.
Schützen Sie Ihre neu migrierten, auf CSI-Treibern basierenden PVs, indem Sie sie mithilfe von Azure Backup für AKS sichern.

Share via

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

Voraussetzungen

Migrieren von Datenträgervolumes

Erstellen eines statischen Volumes

Migration

Erstellen eines dynamischen Volumes

Migration

Migration

Nächste Schritte

Zusätzliche Ressourcen

Share via

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

Voraussetzungen

Migrieren von Datenträgervolumes

Erstellen eines statischen Volumes

Migration

Erstellen eines dynamischen Volumes

Migration

Migrieren von Dateifreigabevolumes

Migration

Nächste Schritte

Zusätzliche Ressourcen