Datenspeicher zu SPBM migrieren

In diesem Dokument wird beschrieben, wie Sie einen vSphere-Datenspeicher zu Storage Policy Based Management (SPBM) migrieren.

Diese Seite richtet sich an Speicherspezialisten, die Speicherleistung, ‑nutzung und ‑kosten konfigurieren und verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

1.30: Allgemein verfügbar
1.29: Vorabversion
1.16 und älter: Nicht verfügbar

Kontext

Sie können einen Datenspeicher in Clusterkonfigurationsdateien an vier Stellen angeben:

Die Übernahme für diese Felder ist folgendermaßen:

adminCluster.vCenter.datastore ->
  userCluster.vCenter.datastore ->
    (userCluster.masterNode.vsphere.datastore and userCluster.nodePools[i].vsphere.datastore)

Beispiele:

  • Wenn userCluster.vCenter.datastore leer ist, wird der Wert von adminCluster.vCenter.datastore übernommen.

  • Wenn userCluster.nodePools[i].vsphere.datastore leer ist, wird der Wert von userCluster.vCenter.datastore übernommen.

Es gibt vier Stellen, an denen Sie eine Speicherrichtlinie angeben können:

Die Übernahme für die storagePolicyName-Felder ist dieselbe wie für die datastore-Felder.

Hinweise

  • Dies ist eine einseitige Migration. Die Migration zum vorherigen Status wird nicht unterstützt.
  • Der Datenspeicher muss mit der neuen Speicherrichtlinie kompatibel sein, die Sie festlegen möchten.
  • Es werden nur Administratorcluster mit Hochverfügbarkeit (HA) unterstützt. Wenn Ihr Administratorcluster nicht hochverfügbar ist, müssen Sie ihn zuerst zu HA migrieren.

Nutzercluster migrieren

Die Schritte, die Sie für die Migration ausführen, hängen davon ab, ob Sie den gesamten Nutzercluster oder die Knoten der Steuerungsebene und die Worker-Knotenpools separat migrieren möchten. Mit dieser Option können Sie verschiedene Speicherrichtlinien für Knoten der Steuerungsebene und Worker-Knotenpools auswählen.

Beachten Sie bei der Planung eines Wartungsfensters Folgendes:

  • Für die Migration des gesamten Clusters ist nur ein Cluster-Update erforderlich.

  • Für die separate Migration der Steuerungsebenenknoten und Worker-Knotenpools sind zwei Clusterupdates erforderlich.

Gesamter Cluster

Führen Sie diese Schritte aus, wenn Sie den gesamten Cluster migrieren möchten, einschließlich aller Knoten der Steuerungsebene und Worker-Knotenpools. Die Version Ihres Nutzerclusters muss mindestens 1.30 sein.

  1. Ändern Sie die Konfigurationsdatei des Nutzerclusters so:

    1. Legen Sie für das Feld vCenter.storagePolicyName den Namen der Speicherrichtlinie fest.

    2. Entfernen oder kommentieren Sie Folgendes aus, falls es angegeben ist:

      • Feld vCenter.datastore
      • masterNode.vsphere-Abschnitt
      • nodepools[i].vsphere.datastore
      • nodepools[i].vsphere.storagePolicyName

    Die folgenden Beispielkonfigurationen zeigen diese Änderungen.

    Vor den Änderungen:

    vCenter:
  datastore: ds-1

    Nach den Änderungen:

    vCenter:
  storagePolicyName: sp-1
  # datastore: ds-1

  2. Aktualisieren Sie den Nutzercluster:

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_KUBECONFIG: Pfad der kubeconfig-Datei des Administratorclusters.

    • USER_CLUSTER_CONFIG: der Pfad zur Konfigurationsdatei des Nutzerclusters.

Mitgelieferte StorageClass aktualisieren

Nachdem Sie die Konfigurationseinstellungen im Cluster aktualisiert haben, müssen Sie das gebündelte StorageClass aktualisieren.

  1. Rufen Sie den aktuellen Standardwert für StorageClass für das gebündelte vsphere-csi-driver mit dem Namen standard-rwo ab und speichern Sie ihn in einer lokalen Datei mit dem Namen storage-class.yaml.

    kubectl get storageclass standard-rwo -oyaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml

    Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

  2. Erstellen Sie als Vorsichtsmaßnahme eine Kopie von storage-class.yaml, da Sie Änderungen an der Datei vornehmen müssen:

    cp storage-class.yaml storage-class.yaml-backup.yaml

  3. Löschen Sie die Standard-StorageClass aus dem Cluster:

    kubectl delete storageclass standard-rwo \
    --kubeconfig USER_CLUSTER_KUBECONFIG

  4. Aktualisieren Sie die Konfiguration in storage-class.yaml so:

    1. Löschen Sie die folgenden Felder oder kommentieren Sie sie aus:

      • parameters.datastoreURL
      • resourceVersion

    2. Fügen Sie das Feld parameters.storagePolicyName hinzu und legen Sie es auf den Namen der Speicherrichtlinie fest.

    Die folgenden Beispielkonfigurationen zeigen diese Änderungen.

    Vor den Änderungen:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Nach den Änderungen:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Wenden Sie die geänderte Datei StorageClass auf den Nutzercluster an:

    kubectl apply -f storage-class.yaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG

Nur Kubeception-Nutzercluster

Bei Kubeception-Nutzerclustern müssen Sie die StorageClass für die Knoten der Steuerungsebene des Nutzerclusters im Administratorcluster aktualisieren. In Kubeception-Clustern ist das Konfigurationsfeld enableControlplaneV2 auf false festgelegt. Wenn Controlplane V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Nutzercluster selbst ausgeführt. Wenn Controlplane V2 nicht aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Administratorcluster ausgeführt. Dies wird als Kubeception bezeichnet.

Führen Sie den folgenden Befehl aus, um festzustellen, ob Controlplane V2 für den Cluster aktiviert ist:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Wenn die Ausgabe false ist, führen Sie die folgenden Schritte aus, um die Standard-StorageClass für die Knoten der Steuerungsebene des Nutzerclusters im Administratorcluster zu aktualisieren:

  1. Rufen Sie den aktuellen Standardwert für StorageClass für das gebündelte vsphere-csi-driver mit dem Namen USER_CLUSTER_NAME-csi ab und speichern Sie ihn in einer lokalen Datei mit dem Namen storage-class-kubeception.yaml.

    kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml

    Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig des Administratorclusters.

  2. Erstellen Sie als Vorsichtsmaßnahme eine Kopie von storage-class-kubeception.yaml, da Sie Änderungen an der Datei vornehmen müssen:

    cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml

  3. Löschen Sie die Standard-StorageClass aus dem Cluster:

    kubectl delete storageclass USER_CLUSTER_NAME-csi \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Aktualisieren Sie die Konfiguration in storage-class-kubeception.yaml so:

    1. Löschen Sie die folgenden Felder oder kommentieren Sie sie aus:

      • parameters.datastoreURL
      • resourceVersion

    2. Fügen Sie das Feld parameters.storagePolicyName hinzu und legen Sie es auf den Namen der Speicherrichtlinie fest.

    Die folgenden Beispielkonfigurationen zeigen diese Änderungen.

    Vor den Änderungen:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Nach den Änderungen:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Wenden Sie die geänderte Datei StorageClass auf den Administratorcluster an:

    kubectl apply -f storage-class-kubeception.yaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Nach der Migration

Wenn Sie nach einer Migration einen neuen Knotenpool erstellen, folgt der neue Pool den Übernahmeregeln des aktualisierten Clusters.

Angenommen, Sie haben vCenter.datastore zu einer Speicherrichtlinie migriert.

Wenn Sie jetzt einen neuen Knotenpool erstellen und sowohl nodePools[i].vsphere.datastore als auch nodePools[i].vsphere.storagePolicyName leer lassen, wird die in vCenter.storagePolicyName angegebene Speicherrichtlinie auf den neuen Knotenpool angewendet.

Knoten separat

Führen Sie diese Schritte aus, wenn Sie die Knoten der Steuerungsebene und die Worker-Knotenpools separat migrieren möchten.

  1. Nur Version 1.29: Rufen Sie die aktuelle Clusterkonfiguration ab. Dieser Schritt ist nicht erforderlich, wenn der Nutzercluster Version 1.30 oder höher hat.

    gkectl get-config cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster-name USER_CLUSTER_NAME \
  --output-dir ./gen-files

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei für den Administratorcluster.

    • USER_CLUSTER_NAME: Der Name des Nutzerclusters.

    Suchen Sie in ./gen-files nach user-cluster.yaml.

    Weitere Informationen zum Abrufen der Konfigurationsdatei finden Sie unter Konfigurationsdateien aus einem Cluster generieren.

    In der generierten Konfigurationsdatei ist der Name datastore auf jeder Ebene festgelegt: Cluster, masterNode (für Steuerungsebenenknoten) und nodepools (für Worker-Knoten), wie im folgenden Beispiel gezeigt:

    apiVersion: v1
kind: UserCluster
...
# VCenter config in cluster level:
vCenter:
  datastore: ds-1
...
# VCenter config in master node level:
masterNode:
  vsphere:
    datastore: ds-1
...
# VCenter config in nodepool level:
nodepools:
- name: pool-1
  vsphere:
    datastore: ds-1
- name: pool-2
  vsphere:
    datastore: ds-1

Knoten der Steuerungsebene migrieren

Führen Sie die folgenden Schritte aus, um die Knoten der Steuerungsebene zu migrieren:

  1. Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Nutzerclusters vor:

    • Legen Sie das Feld masterNode.vsphere.storagePolicyName mit dem Namen der Speicherrichtlinie fest.
    • Löschen Sie das Feld masterNode.vsphere.datastore oder kommentieren Sie es aus.

    Die folgenden Beispielkonfigurationen zeigen diese Änderungen.

    Vor den Änderungen:

    masterNode:
  vsphere:
    datastore: ds-1

    Nach den Änderungen:

    masterNode:
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1

  2. Aktualisieren Sie den Nutzercluster:

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_KUBECONFIG: Pfad der kubeconfig-Datei des Administratorclusters.

    • USER_CLUSTER_CONFIG: der Pfad zur Konfigurationsdatei des Nutzerclusters.

    Warten Sie, bis der Aktualisierungsbefehl abgeschlossen ist, bevor Sie Knotenpools aktualisieren.

Knotenpools migrieren

Führen Sie die folgenden Schritte aus, um alle Knotenpools zu migrieren:

  1. Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Nutzerclusters vor:

    • Legen Sie für jedes Feld nodePools[i].vsphere.storagePolicyName den Namen der Speicherrichtlinie fest.
    • Löschen Sie jedes nodePools[i].vsphere.datastore-Feld oder kommentieren Sie es aus.

    Die folgenden Beispielkonfigurationen zeigen diese Änderungen.

    Vor den Änderungen:

    nodepools:
- name: pool-1
  vsphere:
    datastore: ds-1
- name: pool-2
  vsphere:
    datastore: ds-1

    Nach den Änderungen:

    nodepools:
- name: pool-1
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1
- name: pool-2
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1

  2. Aktualisieren Sie den Nutzercluster:

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

Optional: Speicherrichtlinie auf Clusterebene aktualisieren

Für Nutzercluster sind die Felder datastore und storagePolicyName im Abschnitt vCenter auf Clusterebene ein Standardwert, der von den Abschnitten masterNode und nodepools verwendet wird. Nachdem Sie die vorherigen Schritte ausgeführt haben, werden die Einstellungen für vCenter datastore und storagePolicyName auf Clusterebene von keinen Clusterkomponenten mehr verwendet. Sie können den Abschnitt vCenter auf Clusterebene beibehalten oder ihn so aktualisieren, dass er mit masterNode und nodepools übereinstimmt.

Wenn Sie die Einstellung beibehalten, empfehlen wir, dass Sie über dem vCenter-Abschnitt auf Clusterebene einen Kommentar hinzufügen, in dem Sie darauf hinweisen, dass die Einstellung ignoriert wird, weil sie durch Einstellungen in den Abschnitten masterNode und nodepools überschrieben wird.

Sie können den Abschnitt vCenter auf Clusterebene an die Abschnitte masterNode und nodepools anpassen und den Cluster mit den folgenden Schritten aktualisieren:

  1. Ändern Sie die Konfigurationsdatei des Nutzerclusters so:

    • Legen Sie für das Feld vCenter.storagePolicyName den Namen der Speicherrichtlinie fest.
    • Entfernen Sie das Feld vCenter.datastore oder kommentieren Sie es aus.

  2. Aktualisieren Sie den Nutzercluster:

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Mit diesem Updatebefehl werden keine Änderungen am Cluster vorgenommen, aber die Felder OnPremUserCluster, vCenter.datastore und vCenter.storagePolicyName auf der Serverseite werden aktualisiert.

Mitgelieferte StorageClass aktualisieren

Nachdem Sie die Konfigurationseinstellungen aktualisiert haben, müssen Sie das gebündelte StorageClass aktualisieren.

  1. Rufen Sie den aktuellen Standardwert für StorageClass für das gebündelte vsphere-csi-driver mit dem Namen standard-rwo ab und speichern Sie ihn in einer lokalen Datei mit dem Namen storage-class.yaml.

    kubectl get storageclass standard-rwo -oyaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml

    Ersetzen Sie USER_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

  2. Erstellen Sie als Vorsichtsmaßnahme eine Kopie von storage-class.yaml, da Sie Änderungen an der Datei vornehmen müssen:

    cp storage-class.yaml storage-class.yaml-backup.yaml

  3. Löschen Sie die Standard-StorageClass aus dem Cluster:

    kubectl delete storageclass standard-rwo \
    --kubeconfig USER_CLUSTER_KUBECONFIG

  4. Aktualisieren Sie die Konfiguration in storage-class.yaml so:

    1. Löschen Sie die folgenden Felder oder kommentieren Sie sie aus:

      • parameters.datastoreURL
      • resourceVersion

    2. Fügen Sie das Feld parameters.storagePolicyName hinzu und legen Sie es auf den Namen der Speicherrichtlinie fest.

    Die folgenden Beispielkonfigurationen zeigen diese Änderungen.

    Vor den Änderungen:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Nach den Änderungen:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Wenden Sie die geänderte Datei StorageClass auf den Nutzercluster an:

    kubectl apply -f storage-class.yaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG

Nur Kubeception-Nutzercluster

Bei Kubeception-Nutzerclustern müssen Sie die StorageClass für die Knoten der Steuerungsebene des Nutzerclusters im Administratorcluster aktualisieren. In Kubeception-Clustern ist das Konfigurationsfeld enableControlplaneV2 auf false festgelegt. Wenn Controlplane V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Nutzercluster selbst ausgeführt. Wenn Controlplane V2 nicht aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Administratorcluster ausgeführt. Dies wird als Kubeception bezeichnet.

Führen Sie den folgenden Befehl aus, um festzustellen, ob Controlplane V2 für den Cluster aktiviert ist:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Wenn die Ausgabe false ist, führen Sie die folgenden Schritte aus, um die Standard-StorageClass für die Knoten der Steuerungsebene des Nutzerclusters im Administratorcluster zu aktualisieren:

  1. Rufen Sie den aktuellen Standardwert für StorageClass für das gebündelte vsphere-csi-driver mit dem Namen USER_CLUSTER_NAME-csi ab und speichern Sie ihn in einer lokalen Datei mit dem Namen storage-class-kubeception.yaml.

    kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml

    Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig des Administratorclusters.

  2. Erstellen Sie als Vorsichtsmaßnahme eine Kopie von storage-class-kubeception.yaml, da Sie Änderungen an der Datei vornehmen müssen:

    cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml

  3. Löschen Sie die Standard-StorageClass aus dem Cluster:

    kubectl delete storageclass USER_CLUSTER_NAME-csi \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Aktualisieren Sie die Konfiguration in storage-class-kubeception.yaml so:

    1. Löschen Sie die folgenden Felder oder kommentieren Sie sie aus:

      • parameters.datastoreURL
      • resourceVersion

    2. Fügen Sie das Feld parameters.storagePolicyName hinzu und legen Sie es auf den Namen der Speicherrichtlinie fest.

    Die folgenden Beispielkonfigurationen zeigen diese Änderungen.

    Vor den Änderungen:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Nach den Änderungen:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Wenden Sie die geänderte StorageClass auf den Administratorcluster an:

    kubectl apply -f storage-class-kubeception.yaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Administratorcluster migrieren

Achten Sie darauf, dass der Administratorcluster auch mit dem Namen der Speicherrichtlinie aktualisiert wird.

  1. Nehmen Sie die folgenden Änderungen an der Konfigurationsdatei des Administratorclusters vor:

    • Entfernen Sie das Feld vCenter.datastore oder kommentieren Sie es aus.
    • Legen Sie für das Feld vCenter.storagePolicyName den Namen der Speicherrichtlinie fest.

  2. Aktualisieren Sie den Administratorcluster:

    gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG

    Ersetzen Sie Folgendes:

    • ADMIN_CLUSTER_KUBECONFIG: Der Pfad zur kubeconfig-Datei des Administratorclusters.
    • ADMIN_CLUSTER_CONFIG: der Pfad zur Konfigurationsdatei des Administratorclusters.

Speichermigration mit richtlinienbasierter Verwaltung

Nach der Migration von Datenspeicher zu SPBM verwenden Ihre Cluster jetzt SPBM. Bei der Migration werden jedoch keine Speicherarbeitslasten (z. B. Maschinendatenlaufwerke oder Container-Volumes) aus dem alten Datenspeicher verschoben.

Informationen zum Verschieben von Speicherarbeitslasten finden Sie unter Speichermigration mit richtlinienbasierter Verwaltung.