Ressourcen während der Wiederherstellung ändern (verworfen)

Auf dieser Seite wird beschrieben, wie Sie während der Wiederherstellung Änderungen an Kubernetes-Ressourcen vornehmen.

Übersicht

Es gibt mehrere Gründe, warum Kubernetes-Ressourcen im Rahmen der Wiederherstellung geändert werden können. Beispiel:

  • Sie können PVCs mit einem anderen Speicherbereitsteller bereitstellen, z. B. vom integrierten Kubernetes-Treiber zum CSI-Treiber.

  • Sie können einen Namespace unter einem anderen Namen wiederherstellen.

  • Sie können die Anzahl der Replikate in einem Deployment oder StatefulSet ändern.

Die Sicherung für GKE bietet dafür einen Mechanismus namens Substitutionsregeln, den Sie optional als Teil von RestorePlan definieren können.

Eine Substitutionsregel ist ein Satz von Übereinstimmungskriterien, die zusammen mit einem Ersatzfeldwert angegeben werden. So verwenden Sie Substitutionsregeln bei der Wiederherstellung:

  1. Zuerst berechnet Sicherung für GKE die Ressourcen, die wiederhergestellt werden sollen, basierend auf den Bereichsparametern in der Wiederherstellungskonfiguration (z. B. Namespaces, Gruppe/Arten usw.).

  2. Sicherung für GKE wertet jede für die Wiederherstellung ausgewählte Ressource anhand der sortierten Liste der Substitutionsregeln aus. Wenn eine Regel mit der Ressource übereinstimmt, wird die Ressource mit dem ersetzten Feldwert aktualisiert. Alle Ressourcen werden mit allen Regeln abgeglichen. Für dieselbe Ressource können möglicherweise mehrere Substitutionen ausgeführt werden.

  3. Nachdem alle Regeln ausgewertet wurden, erstellt Sicherung für GKE die resultierenden Ressourcen im Zielcluster.

Parameter für Ersetzungsregeln

Geben Sie die folgenden Parameter an, um eine Substitutionsregel zu definieren:

Parameter Erforderlich Beschreibung
targetNamespaces optional Dies ist eine Liste von Namespaces. Damit eine Ressource dieser Regel entspricht, muss sie eine Namespace-Ressource sein und einen der angegebenen Namespaces haben:
  • Wenn für diesen Parameter nichts angegeben ist, stimmen alle Ressourcen überein (alle Namespace- und clusterbezogenen Ressourcen).
  • Wenn ein leerer String („“) angegeben wird, wird nur mit Ressourcen auf Clusterebene abgeglichen. In der Google Cloud Console können Sie Namespace-Ressourcen ausschließen aktivieren, um die Liste auf einen einzelnen leeren String festzulegen.
targetGroupKinds optional Dies ist eine Liste von Gruppe/Art-Tupeln für Kubernetes-Ressourcen:
  • Wenn für diesen Parameter nichts angegeben ist, werden alle Ressourcen abgeglichen (keine Einschränkungen auf der Grundlage von Gruppe/Art).
  • Wenn eine oder mehrere Gruppen/Arten angegeben werden, müssen Ressourcen mit einer von diesen übereinstimmen.
targetJsonPath erforderlich Dies ist ein JSONPath, der mit Ressourcen abgeglichen wird. Beachten Sie, dass diese Regel nicht nur mit der Ressource, sondern auch mit einem bestimmten Attribut in der Ressource übereinstimmt.
originalValuePattern optional Dies ist ein regulärer Ausdruck, der mit dem aktuellen Wert des Attributs abgeglichen wird. Wenn kein Wert angegeben wird, stimmt das Attribut immer überein.
newValue erforderlich Dies ist der neue Wert, der für den übereinstimmenden Attributwert verwendet werden soll.

Weitere Informationen zum Definieren von Substitutionsregeln in der Google Cloud Console finden Sie unter Eine Reihe von Wiederherstellungen planen.

Wenn Sie Substitutionsregeln über die gcloud CLI definieren möchten, erstellen Sie eine Datei mit einem YAML-Array von substitutionRules und fügen Sie im Befehl gcloud beta container backup-restore restore-plans create den Parameter --substitution-rules-file= ein.

Beispiele für Ersetzungsregeln

Die folgenden Beispiele werden im YAML-Format bereitgestellt, das von der gcloud CLI verwendet wird.

StorageClass ändern

In diesem Beispiel ändern wir die StorageClass in allen wiederhergestellten PersistentVolumeClaim-Ressourcen von standard in premium-rwo:

substitutionRules:
- targetGroupKinds:
  - resourceGroup: ''
    resourceKind: PersistentVolumeClaim
  targetJsonPath: "{..storageClassName}"
  originalValuePattern: standard
  newValue: premium-rwo

Namespace klonen

In diesem Beispiel klonen wir einen Namespace von der Alpha- auf die Betaversion. Dabei wird ein neuer Namespace namens „Beta” erstellt und alle Ressourcen aus der Alphaversion werden im neuen „Beta”-Namespace wiederhergestellt. Beachten Sie, dass in diesem Beispiel zwei Substitutionsregeln erforderlich sind – eine für den Namespace selbst und eine für die Ressourcen innerhalb des Namespace.

substitutionRules:
- targetNamespaces:
  - ''
  targetGroupKinds:
  - resourceGroup: ''
    resourceKind: Namespace
  targetJsonPath: "{.metadata.name}"
  originalValuePattern: alpha
  newValue: beta
- targetNamespaces:
  - alpha
  targetJsonPath: "{.metadata.namespace}"
  originalValuePattern: alpha
  newValue: beta

StorageClass und Replikatzahl in einem geklonten Namespace ändern

In diesem Beispiel klonen wir einen Namespace und wenden dann eine Reihe von Änderungen auf die Ressourcen im neuen Namespace an:

  • StorageClass für PVCs von standard in premium-rwo ändern

  • Ändern Sie die Replikatanzahl für Deployments von 7 in 3.

substitutionRules:
- targetNamespaces:
  - ''
  targetGroupKinds:
  - resourceGroup: ''
    resourceKind: Namespace
  targetJsonPath: "{.metadata.name}"
  originalValuePattern: alpha
  newValue: beta
- targetNamespaces:
  - alpha
  targetJsonPath: "{.metadata.namespace}"
  originalValuePattern: alpha
  newValue: beta
- targetNamespaces:
  - beta
  targetGroupKinds:
  - resourceGroup: ''
    resourceKind: PersistentVolumeClaim
  targetJsonPath: "{..storageClassName}"
  originalValuePattern: standard
  newValue: premium-rwo
- targetNamespaces:
  - beta
  targetGroupKinds:
  - resourceGroup: apps
    resourceKind: Deployment
  targetJsonPath: "{$.spec.replicas}"
  originalValuePattern: '7'
  newValue: '3'