Przenoszenie woluminów trwałych usługi Azure Disk do innego klastra usługi AKS w tej samej lub innej subskrypcji

W tym artykule opisano sposób bezpiecznego przenoszenia woluminów trwałych usługi Azure Disk z jednego klastra usługi Azure Kubernetes Service (AKS) do innego w tej samej subskrypcji lub w innej subskrypcji. Subskrypcja docelowa musi znajdować się w tym samym regionie.

Sekwencja kroków, które należy wykonać, to:

Aby uniknąć utraty danych, upewnij się, że stan zasobu dysku Azure w źródłowym klastrze usługi AKS nie jest ustawiony na Dołączony.
Przenieś zasób dysku platformy Azure do docelowej grupy zasobów w tej samej subskrypcji lub innej subskrypcji.
Sprawdź, czy przenoszenie zasobu dysku platformy Azure zakończyło się pomyślnie.
Utwórz trwały wolumin (PV) i żądanie trwałego woluminu (PVC), a następnie zamontuj przeniesiony dysk jako wolumin na podzie w klastrze docelowym.

Zanim rozpoczniesz

Upewnij się, że masz zainstalowany i skonfigurowany interfejs wiersza polecenia platformy Azure w wersji 2.0.59 lub nowszej. Aby dowiedzieć się, jaka wersja jest używana, uruchom polecenie az --version. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.
Przejrzyj szczegóły i wymagania dotyczące przenoszenia zasobów między różnymi regionami w temacie Przenoszenie zasobów do nowej grupy zasobów lub subskrypcji. Przed przeniesieniem zasobów w tym artykule upewnij się, że zapoznałeś się z listą kontrolną.
Klaster źródłowy musi mieć co najmniej jeden wolumin trwały z dołączonym dyskiem Azure.
Musisz mieć klaster usługi Azure Kubernetes Service (AKS) w subskrypcji docelowej.

Weryfikowanie stanu woluminu dysku

Ważne jest, aby uniknąć ryzyka uszkodzenia, niespójności lub utraty danych podczas pracy z woluminami trwałymi. Aby ograniczyć te zagrożenia podczas procesu migracji lub przenoszenia, należy najpierw sprawdzić, czy wolumin dysku nie jest podłączony, wykonując następujące kroki.

Zidentyfikuj grupę zasobów węzła, hostującą dyski zarządzane platformy Azure, za pomocą polecenia az aks show i dodaj parametr --query nodeResourceGroup.
```
az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv
```
Dane wyjściowe polecenia przypominają następujący przykład:
```
MC_myResourceGroup_myAKSCluster_eastus
```
Wyświetl listę dysków zarządzanych przy użyciu az disk list polecenia . Odnieś się do zwróconej w poprzednim kroku grupy zasobów.
```
az disk list --resource-group MC_myResourceGroup_myAKSCluster_eastus
```
Przejrzyj listę i zanotuj woluminy dysków, które planujesz przenieść do innego klastra. Sprawdź również stan tego dysku przez sprawdzenie właściwości diskState. Wynik polecenia jest skróconym przykładem.
```
{
"LastOwnershipUpdateTime": "2023-04-25T15:09:19.5439836+00:00",
"creationData": {
  "createOption": "Empty",
  "logicalSectorSize": 4096
},
"diskIOPSReadOnly": 3000,
"diskIOPSReadWrite": 4000,
"diskMBpsReadOnly": 125,
"diskMBpsReadWrite": 1000,
"diskSizeBytes": 1073741824000,
"diskSizeGB": 1000,
"diskState": "Unattached",
```
Uwaga

Zanotuj wartość pola resourceGroup dla każdego dysku, który chcesz przenieść z powyższych danych wyjściowych. Ta grupa zasobów jest grupą zasobów węzła, a nie grupą zasobów klastra. Aby przenieść dyski, potrzebna będzie nazwa tej grupy zasobów.
Jeśli diskState się pojawi Attached, najpierw sprawdź, czy jakiekolwiek zadania nadal uzyskują dostęp do woluminu i zatrzymaj je. Po upływie czasu stan dysku zwraca stan Unattached , a następnie można go przenieść.

Przenoszenie woluminu trwałego

Aby przenieść trwały wolumin lub woluminy do innego klastra usługi AKS, wykonaj kroki opisane w temacie Przenoszenie zasobów platformy Azure do nowej grupy zasobów lub subskrypcji. Do przeprowadzenia migracji można użyć witryny Azure Portal, programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure.

Podczas tego procesu odwołujesz się do:

Nazwa lub identyfikator zasobu grupy zasobów węzła źródłowego hostującej dyski zarządzane przez platformę Azure. Nazwę grupy zasobów węzła można znaleźć, przechodząc do pulpitu Dyski w witrynie Azure Portal i zauważając przypisaną do dysku grupę zasobów.
Nazwa lub identyfikator zasobu docelowej grupy zasobów, do którego mają być przenoszone dyski zarządzane.
Nazwa lub identyfikator zasobu zasobów dysków zarządzanych.

Uwaga

Ze względu na zależności między dostawcami zasobów wykonanie tej operacji może potrwać do czterech godzin.

Sprawdź, czy wolumin dysku został przeniesiony

Po przeniesieniu woluminu dysku do docelowej grupy zasobów klastra zweryfikuj zasób na liście grup zasobów przy użyciu az disk list polecenia . Odwołaj się do docelowej grupy zasobów, w której przeniesiono zasoby. W tym przykładzie dyski zostały przeniesione do grupy zasobów o nazwie MC_myResourceGroup_myAKSCluster_eastus.

  az disk list --resource-group MC_myResourceGroup_myAKSCluster_eastus

Instalowanie przeniesionego dysku jako woluminu

Aby zainstalować przeniesiony wolumin dysku, utwórz statyczny wolumin trwały z identyfikatorem zasobu skopiowanym w poprzednich krokach, żądanie woluminu trwałego oraz, w tym przykładzie, prosty pod.

Utwórz plik pv-azuredisk.yaml z woluminem trwałym. Zaktualizuj pole volumeHandle przy użyciu identyfikatora zasobu dysku z poprzedniego kroku.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-azuredisk
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: managed-csi
  csi:
    driver: disk.csi.azure.com
    readOnly: false
    volumeHandle: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MC_rg_azure_aks-pvc-target_eastus/providers/Microsoft.Compute/disks/pvc-aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e
    volumeAttributes:
      fsType: ext4

Utwórz plik pvc-azuredisk.yaml za pomocą elementu PersistentVolumeClaim, który używa elementu PersistentVolume.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-azuredisk
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  volumeName: pv-azuredisk
  storageClassName: managed-csi

Utwórz element PersistentVolume i PersistentVolumeClaim przy użyciu kubectl apply polecenia i odwołaj się do dwóch utworzonych plików YAML.
```
kubectl apply -f pv-azuredisk.yaml
kubectl apply -f pvc-azuredisk.yaml
```

Sprawdź, czy PersistentVolumeClaim został utworzony i powiązany z PersistentVolume przy użyciu polecenia kubectl get.

kubectl get pvc pvc-azuredisk

Dane wyjściowe polecenia przypominają następujący przykład:

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

Aby odwołać się do pliku PersistentVolumeClaim, utwórz plik azure-disk-pod.yaml . W przykładowym manifeście nazwa zasobnika to mypod.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  nodeSelector:
    kubernetes.io/os: linux
  containers:
    - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      name: mypod
      resources:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 250m
          memory: 256Mi
      volumeMounts:
        - name: azure
          mountPath: /mnt/azure
  volumes:
    - name: azure
      persistentVolumeClaim:
        claimName: pvc-azuredisk

Zastosuj konfigurację i zamontuj wolumin przy użyciu polecenia kubectl apply.
```
kubectl apply -f azure-disk-pod.yaml
```
Sprawdź status poda oraz dane zmigrowane z woluminem zamontowanym w systemie plików poda na /mnt/azure. Najpierw uzyskaj stan zasobnika przy użyciu kubectl get polecenia .
```
kubectl get pods
```
Dane wyjściowe polecenia przypominają następujący przykład:
```
NAME    READY   STATUS    RESTARTS   AGE
mypod   1/1     Running   0          4m1s
```
Sprawdź dane wewnątrz zamontowanego woluminu /mnt/azure korzystając z polecenia kubectl exec.
```
kubectl exec -it mypod -- ls -l /mnt/azure/
```
Dane wyjściowe polecenia przypominają następujący przykład:
```
total 28
-rw-r--r--    1 root     root       0 Jan 11 10:09 file-created-in-source-aks
```

Następne kroki

Aby uzyskać więcej informacji na temat rozwiązań pamięci masowej opartych na dyskach, zobacz Rozwiązania oparte na dyskach w usłudze AKS.
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).

Opinia

Czy ta strona była pomocna?

Ostatnia aktualizacja o 2025-04-05