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 Ersetzungsregel ist eine Gruppe von Abgleichskriterien, die zusammen mit einem Ersatzfeldwert angegeben werden. Sie können Substitutionsregeln im Wiederherstellungsprozess so verwenden:

  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 vergleicht jede für die Wiederherstellung ausgewählte Ressource mit der geordneten Liste der Ersetzungsregeln. Wenn eine Regel mit der Ressource übereinstimmt, wird die Ressource mit dem substituierten Feldwert aktualisiert. Alle Ressourcen werden mit allen Regeln abgeglichen. Für dieselbe Ressource können mehrere Ersetzungen vorgenommen 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 Ersetzungsregel 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, werden nur clusterbezogene Ressourcen abgeglichen. In der Google Cloud -Konsole 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, stimmen alle Ressourcen überein (keine Einschränkungen basierend auf Gruppe/Art).
  • Wenn eine oder mehrere Gruppen/Arten angegeben werden, müssen Ressourcen mit einer von diesen übereinstimmen.
targetJsonPath erforderlich Dies ist ein JSONPath-Ausdruck, 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 nicht angegeben, wird das Attribut immer abgeglichen.
newValue erforderlich Das ist der neue Wert, der für den abgeglichenen 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 wird die StorageClass in allen wiederhergestellten PersistentVolumeClaim-Ressourcen von standard in premium-rwo geändert:

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 Replikatanzahl in einem geklonten Namespace ändern

In diesem Beispiel wird ein Namespace geklont und dann eine Reihe von Änderungen auf Ressourcen im neuen Namespace angewendet:

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

  • Ändern Sie die Replikatanzahl für Bereitstellungen 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'