Volume aus einem Snapshot wiederherstellen

Version 1.28 

• Neueste Version
• Version 1.16
• Frühere Versionen (nicht unterstützt)

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

In diesem Dokument wird gezeigt, wie Sie einen Volume-Snapshot erstellen und ihn anschließend verwenden, um das Volume wiederherzustellen. Diese Anleitung gilt für Cluster, die den vSphere-CSI-Treiber verwenden.

Hinweise

Weitere Informationen finden Sie unter vSphere Container Storage Interface-Treiber verwenden.

Prüfen Sie, ob Ihr Cluster die Speicherklasse standard-rwo hat und der vSphere-CSI-Treiber installiert ist.

Bei Ihrer vSphere-Version ESXi und vCenter Server muss Version 7.0 Update 3 oder höher installiert sein. Weitere Informationen finden Sie unter Fehlerbehebung beim Speicherplatz.

Die einzelnen Schritte im Überblick

Dies sind die Hauptschritte der in diesem Dokument dargestellten Übung:

1. Erstellen Sie einen PersistentVolumeClaim.

   Erstellen Sie einen PersistentVolumeClaim, der die Speicherklasse standard-rwo anfordert. Der Cluster stellt dann dynamisch ein nichtflüchtiges Volume bereit und verknüpft es mit Ihrem PersistentClaim.

2. Deployment erstellen.

   Erstellen Sie ein Deployment mit einem Pod. Der Pod gibt ein Volume basierend auf Ihrem PersistentVolumeClaim an. Der eine Container im Pod stellt das Volume unter /hello/ bereit.

3. Schreiben Sie eine Datei in das Pod-Volume.

   Erstellen Sie im Pod-Volume eine Datei mit dem Namen hello.txt. Der Inhalt der Datei ist „Hello World!“.

4. Erstellen Sie einen VolumeSnapshot.

   Erstellen Sie einen VolumeSnapshot, der den Status des Pod-Volumes erfasst.

5. Die Datei ist beschädigt.

   Ändern Sie die Datei hello.txt so, dass sie wie eine beschädigte Datei aussieht. Der Inhalt der Datei lautet jetzt "Hello W-corrupted-file-orld!"

6. Verwenden Sie den Snapshot, um das Volume wiederherzustellen.

   Erstellen Sie einen zweiten PersistentVolumeClaim, der Ihren VolumeSnapshot als Datenquelle verwendet. Bearbeiten Sie das Deployment so, dass das zugehörige Volume dem neuen PersistentVolumeClaim zugeordnet ist. Prüfen Sie dann, ob die Datei hello.txt wiederhergestellt wurde.

PersistentVolumeClaim erstellen

Hier ist ein Manifest für einen PersistentClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard-rwo

Im vorherigen Manifest sehen Sie, dass storageClassName auf standard-rwo gesetzt ist. Dies ist die Speicherklasse, die dem vSphere-CSI-Treiber zugeordnet ist.

Speichern Sie das Manifest in einer Datei mit dem Namen my-pvc.yaml. Erstellen und rufen Sie die nichtflüchtige Speicherressource auf:

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-pvc.yaml

kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc my-pvc

In der Ausgabe sehen Sie, dass der nichtflüchtige Speicher an ein dynamisch bereitgestelltes nichtflüchtiges Volume gebunden ist. Die folgende Ausgabe zeigt beispielsweise, dass der nichtflüchtige Speicher mit dem Namen my-pvc an ein nichtflüchtiges Speichermedium mit dem Namen pvc-467d211c-26e4-4d69-aaa5-42219aee6fd5 gebunden ist:

my-pvc   Bound    pvc-467d211c-26e4-4d69-aaa5-42219aee6fd5  …  standard-rwo   100s

Deployment erstellen

Hier ist ein Manifest für ein Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-app
        image: google/cloud-sdk:slim
        args: [ "sleep", "3600" ]
        volumeMounts:
        - name: my-volume
          mountPath: /hello/
      volumes:
      - name: my-volume
        persistentVolumeClaim:
          claimName: my-pvc

Im Kontext dieser Übung sollten Sie die folgenden wichtigen Punkte zum vorherigen Deployment-Manifest verstehen:

• Der Pod fordert Speicher an, indem er das zuvor erstellte RESOURCEClaim my-pvc angibt.

• Der Pod hat einen Container und der Container stellt das Volume unter /hello/ bereit.

Speichern Sie das Manifest in einer Datei mit dem Namen my-deployment.yaml und erstellen Sie das Deployment:

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-deployment.yaml

Das Deployment hat einen Pod. Rufen Sie den Namen des Pods ab:

kubectl --kubeconfig CLUSTER_KUBECONFIG get pods

Notieren Sie sich den Pod-Namen. In der folgenden Ausgabe lautet der Pod-Name beispielsweise my-deployment-7575c4f5bf-r59nt:

my-deployment-7575c4f5bf-r59nt   1/1     Running   0          65s

Erstellen Sie eine Datei im Pod-Volume und rufen Sie sie auf.

kubectl --kubeconfig CLUSTER_KUBECONFIG \
    exec POD_NAME \
    -- sh -c 'echo "Hello World!" > /hello/hello.txt'

kubectl --kubeconfig CLUSTER_KUBECONFIG \
    exec POD_NAME \
    -- sh -c 'cat /hello/hello.txt'

Die Ausgabe zeigt den Inhalt der Datei /hello/hello.txt:

Hello World!

Snapshot erstellen

Hier ist ein Manifest für einen VolumeSnapshot:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
spec:
  volumeSnapshotClassName: csi-vsphere-snapshot-class
  source:
    persistentVolumeClaimName: my-pvc

Speichern Sie das Manifest in einer Datei mit dem Namen my-snapshot.yaml und erstellen Sie den VolumeSnapshot:

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-snapshot.yaml

Beschädigen der Datei im Volume

Ändern Sie den Inhalt von hello.txt so, dass er anscheinend beschädigt ist:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
    exec POD_NAME \
    -- sh -c 'echo "Hello W-corrupted-file-orld!" > /hello/hello.txt'

kubectl --kubeconfig CLUSTER_KUBECONFIG \
    exec POD_NAME \
    -- sh -c 'cat /hello/hello.txt'

In der Ausgabe sehen Sie, dass die Datei geändert wurde:

Hello W-corrupted-file-orld!

Wiederherstellen

Hier ist ein Manifest für einen zweiten PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc-2
spec:
  storageClassName: standard-rwo
  dataSource:
    name: my-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Im vorherigen Manifest können Sie sehen, dass die Datenquelle für die neue Persistent-Anforderung der VolumeSnapshot ist, den Sie zuvor erstellt haben.

Speichern Sie das Manifest in einer Datei mit dem Namen my-pvc-2.yaml. Erstellen und rufen Sie die nichtflüchtige Speicherressource auf:

kubectl --kubeconfig CLUSTER_KUBECONFIG apply -f my-pvc-2.yaml

kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc my-pvc-2

Öffnen Sie das Deployment zur Bearbeitung:

kubectl --kubeconfig CLUSTER_KUBECONFIG edit deployment my-deployment

Ändern Sie my-pvc in my-pvc-2 und schließen Sie den Editor:

…
  volumes:
  - name: my-volume
    persistentVolumeClaim:
    claimName: my-pvc-2

Das Deployment löscht den Pod und erstellt einen neuen Pod, der den neuen PersistentVolumeClaim verwendet.

Warten Sie einige Minuten und rufen Sie dann den neuen Pod-Namen ab:

kubectl --kubeconfig CLUSTER_KUBECONFIG get pods

Prüfen Sie, ob das Pod-Volume wiederhergestellt wurde:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
   exec NEW_POD_NAME \
   -- sh -c 'cat /hello/hello.txt'

Die Ausgabe zeigt, dass das Volume wiederhergestellt wurde:

Hello World!

Fehlerbehebung

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung beim Speicher.