Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Containeranwendungen in einem vSphere Kubernetes Service-Cluster mit Trident Protect sichern und wiederherstellen

09/01/2026 Beitragende

PDFs

Containeranwendungen in einem vSphere Kubernetes Service (VKS) Cluster mithilfe von Trident Protect Snapshots und Backups sichern und wiederherstellen. Dieses Verfahren umfasst die Erstellung eines AppVault mit ONTAP S3 Objektspeicher, die Konfiguration von Trident Protect zum Erfassen von Anwendungsdaten einschließlich Kubernetes-Ressourcenobjekten und persistenten Volumes sowie die Wiederherstellung der Daten bei Bedarf.

Container-Anwendungen, die in einem VKS-Cluster ausgeführt werden, werden als Kubernetes-Workloads in Worker-Node-Namespaces verwaltet. Es ist wichtig, sowohl die Anwendungsmetadaten als auch die persistenten Volumes zu schützen, damit sie im Falle eines Verlusts oder einer Beschädigung wiederhergestellt werden können.

Die persistenten Volumes von VKS-Anwendungen können durch ONTAP Storage, der in den VKS-Cluster integriert ist, mit "Trident CSI" unterstützt werden. Dieses Verfahren verwendet "Trident Protect" zur Erstellung von Anwendungssnapshots, deren Metadaten im ONTAP Objektspeicher gespeichert werden, während die Volume-Snapshot-Daten im Storage-Backend verbleiben, sowie Backups, deren Daten in den ONTAP Objektspeicher kopiert werden. Eine Wiederherstellung ist sowohl aus einem Snapshot als auch aus einem Backup möglich.

Trident Protect ermöglicht Snapshots, Backups, Wiederherstellung und Notfallwiederherstellung von Anwendungen auf einem Kubernetes-Cluster. Zu den mit Trident Protect schutzfähigen Daten gehören Kubernetes-Ressourcenobjekte, die mit den Anwendungen und deren persistenten Volumes verknüpft sind.

Im Folgenden sind die Versionen der verschiedenen Komponenten aufgeführt, die in den Beispielen dieses Abschnitts verwendet werden.

VMware Cloud Foundation (VCF) 9.1 mit vSphere Kubernetes Service
"Trident 26.06"
"Trident Protect 26.06"
"ONTAP 9.16"

Trident Protect auf dem vSphere Kubernetes-Cluster installieren

Installieren Sie Trident Protect

Helm wird verwendet, um Trident Protect auf dem vSphere Kubernetes Service Cluster zu installieren. Die Beispiele in diesem Abschnitt verwenden tridentctl-protect, die Trident Protect CLI. Die Installation erfolgt gemäß den Anweisungen in der "Trident Protect CLI Dokumentation". Weitere Methoden zur Installation von Trident Protect sind in der "Trident Protect Dokumentation" dokumentiert.

Zuerst den `trident-protect`Namespace erstellen und kennzeichnen. Das `enforce=privileged`Label ist erforderlich, da Trident Protect privilegierte Workloads ausführt. Ohne dieses Label verhindert der Kubernetes Pod Security Admission Controller den Start der Trident Protect Pods.

kubectl create namespace trident-protect
kubectl label namespace trident-protect pod-security.kubernetes.io/enforce=privileged

Dann das Helm-Repository hinzufügen und Trident Protect im Namespace installieren.

helm repo add netapp-trident-protect https://netapp.github.io/trident-protect-helm-chart
helm install trident-protect netapp-trident-protect/trident-protect --set clusterName=<name-of-cluster> --version 100.2606.0 --namespace trident-protect

Falls Trident Protect Pods aufgrund eines PodSecurity Zulassungsfehlers nicht starten, wurden die Pod-Sicherheitslabels möglicherweise nicht auf den trident-protect Namespace vor der Installation angewendet. Mit --overwrite können sie erneut angewendet werden, anschließend lässt sich überprüfen, ob die Pods starten.

kubectl label namespace trident-protect pod-security.kubernetes.io/enforce=privileged --overwrite

kubectl get pods -n trident-protect

App Vault für Objektspeicher erstellen

Erstellen AppVault

Bevor Snapshots und Backups für eine Anwendung erstellt werden, muss der Objektspeicher in Trident Protect konfiguriert werden. Dies erfolgt durch das Erstellen eines AppVault CR. Nur Administratoren können ein AppVault CR erstellen und konfigurieren.

AppVault-Objekte sind die Kubernetes Custom Resource-Darstellung eines Speicher-Buckets. Ein AppVault CR enthält die Konfigurationen, die erforderlich sind, damit ein Bucket in Datensicherungsoperationen wie Backups, Snapshots, Wiederherstellungsvorgängen und SnapMirror-Replikation verwendet werden kann.

Die folgenden Schritte erstellen eine für ONTAP S3 konfigurierte AppVault CR: . Erstellen eines S3-Objektspeicherservers in der SVM im ONTAP Cluster. . Erstellen eines Buckets im Objektspeicherserver. . Erstellen eines S3-Benutzers in der SVM. Den Zugriffsschlüssel und den geheimen Schlüssel an einem sicheren Ort aufbewahren.

+ HINWEIS: Trident Protect erfordert, dass der S3-Benutzer mindestens PutObject, GetObject, ListBucket und DeleteObject Berechtigungen besitzt. Ohne diese Berechtigungen schlagen AppVault Backup- und Wiederherstellungsvorgänge mit Zugriffsverweigerungsfehlern fehl. Weitere Informationen finden sich unter "Trident Protect AppVault Dokumentation". . Im VKS-Cluster ein Secret zum Speichern der ONTAP S3-Anmeldeinformationen erstellen. . Ein AppVault Objekt für ONTAP S3 erstellen.

Trident Protect AppVault für ONTAP S3 konfigurieren

Das untenstehende Manifest verwendet HTTPS mit aktivierter Zertifikatsvalidierung, was für den Produktivbetrieb erforderlich ist. Wenn Ihr ONTAP S3-Endpunkt ein von einer öffentlichen Zertifizierungsstelle signiertes Zertifikat verwendet, das vom Cluster bereits als vertrauenswürdig eingestuft wird, ist keine zusätzliche Zertifikatskonfiguration notwendig. Wenn ein selbstsigniertes oder internes Zertifikat einer Zertifizierungsstelle verwendet wird, ist das benutzerdefinierte Stammzertifikat der Zertifizierungsstelle im rootCA Feld wie im Manifest gezeigt bereitzustellen. Am Ende dieses Abschnitts findet sich eine ausschließlich für Labore vorgesehene Variante, falls eine HTTP-Konfiguration für isolierte Tests außerhalb des Produktivbetriebs benötigt wird.

# alias tp='tridentctl-protect'

# cat appvault-secret.yaml
apiVersion: v1
data:
  accessKeyID: <base64 encoded access key>
  secretAccessKey: <base64 encoded secret access key>
# Alternatively, remove the data section above and use:
# stringData:
#   accessKeyID: "<access key of S3>"
#   secretAccessKey: "<secret access key of S3>"
kind: Secret
metadata:
  name: ontap-s3-appvault-secret1
  namespace: trident-protect
type: Opaque

# cat appvault.yaml
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: ontap-s3-appvault1
  namespace: trident-protect
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: trident-protect
      endpoint: <lif for S3 access>
      secure: "true"
      skipCertValidation: "false"
      # If your ONTAP S3 endpoint uses a certificate signed by a public CA
      # already trusted by the cluster, no additional certificate config is needed.
      # If it uses a self-signed or internal CA certificate, provide the
      # root CA certificate:
      # rootCA: <root CA certificate>
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: ontap-s3-appvault-secret1
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: ontap-s3-appvault-secret1
  providerType: OntapS3

# kubectl create -f appvault-secret.yaml -n trident-protect
# kubectl create -f appvault.yaml -n trident-protect

Nur für Laborzwecke (HTTP, keine Zertifikatsprüfung)

Nur die folgenden `s3`Einstellungen in einer isolierten Laborumgebung verwenden, in der keine sensiblen Daten vorhanden sind. Diese Einstellungen nicht in der Produktion verwenden.

    s3:
      bucketName: trident-protect
      endpoint: <lif for S3 access>
      secure: "false"
      skipCertValidation: "true"

Eine Trident Protect Anwendung erstellen

Dieses Beispiel behandelt den Datenschutz für die Beispielanwendung postgres, die im Namespace postgres installiert ist. Einzelheiten zur Installation finden sich unter "VKS-Workloads mit NetApp Storage bereitstellen".

Die Beispiel-PostgreSQL-PVCs fordern den RWO-Zugriffsmodus an. Der Zugriffsmodus muss im PVC-Manifest explizit angegeben werden; Trident wählt keinen Zugriffsmodus automatisch anhand des Speicherprotokolls aus. RWX wird für NAS-basierte PVCs unterstützt, und SAN-basierte PVCs können RWX mit zusätzlicher Konfiguration unterstützen. Weitere Informationen finden sich in der "Trident Protect Dokumentation".

Im Beispiel enthält der Namespace postgres eine Anwendung, und alle Ressourcen des Namespace werden beim Erstellen der Trident Protect Application einbezogen.

# alias tp='tridentctl-protect'
# tp create app postgres-app --namespaces postgres -n postgres --dry-run > postgres-app.yaml

# cat postgres-app.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
  name: postgres-app
spec:
  includedNamespaces:
  - namespace: postgres
  resourceFilter: {}
# kubectl create -f postgres-app.yaml -n postgres

Die App wird durch das Erstellen eines Backups geschützt.

Backups erstellen

On-Demand-Backup erstellen

Erstellen Sie eine Sicherung für die zuvor erstellte postgres-app, die alle Ressourcen im postgres-Namespace umfasst. Geben Sie den Namen des appvault an, in dem die Sicherungen gespeichert werden.

# cat postgres-backup-on-demand.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  name: postgres-backup-on-demand
spec:
  appVaultRef: ontap-s3-appvault1
  applicationRef: postgres-app
  cleanupSnapshot: true
  replicateSnapshot: false

kubectl create -f postgres-backup-on-demand.yaml -n postgres

Der Anwendungsschutzstatus ist teilweise

Backups nach Zeitplan erstellen

Erstellen Sie einen Zeitplan für die Backups, wobei die Granularität und die Anzahl der aufzubewahrenden Backups festgelegt werden.

# tp create schedule backup-schedule1 --app postgres-app --appvault ontap-s3-appvault1 --granularity Hourly --minute 45 --backup-retention 1 -n postgres --dry-run>postgres-backup-schedule1.yaml

#cat postgres-backup-schedule1.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: backup-schedule1
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault1
  applicationRef: postgres-app
  backupRetention: "1"
  dayOfMonth: ""
  dayOfWeek: ""
  enabled: true
  granularity: Hourly
  hour: ""
  minute: "45"
  recurrenceRule: ""
  replicationRetention: "0"
  runImmediately: false
  snapshotRetention: "0"
# kubectl create -f postgres-backup-schedule1.yaml -n postgres

Wiederherstellung aus Backup

Wiederherstellung aus Backups

Wiederherstellung der Anwendung im selben Namensraum

In diesem Beispiel enthält das Backup postgres-backup-on-demand das Backup für die postgres-app.

Bevor die Anwendung gelöscht wird, sollte überprüft werden, dass sich die Sicherung, von der wiederhergestellt werden soll, im Completed Zustand befindet. Eine laufende oder fehlgeschlagene Sicherung kann nicht zur Wiederherstellung der Anwendung verwendet werden.

kubectl get backup -n postgres

Nachdem bestätigt wurde, dass der Backup-Status Completed ist, die postgres-Anwendung löschen und sicherstellen, dass die PVCs und Pod-Objekte aus dem Namespace "postgres" entfernt werden.

Nun wird ein Backup-in-Place-Wiederherstellungsobjekt erstellt.

# tp create bir postgres-app-restore --backup postgres/postgres-backup-on-demand -n postgres --dry-run>postgres-app-bir.yaml

# cat postgres-app-bir.yaml
apiVersion: protect.trident.netapp.io/v1
kind: BackupInplaceRestore
metadata:
  annotations:
    protect.trident.netapp.io/max-parallel-restore-jobs: "25"
  name: postgres-app-restore
  namespace: postgres
spec:
  appArchivePath: postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/backups/postgres-backup-on-demand_63efc9d1-92d7-45ce-84fe-846ce7db7b29
  appVaultRef: ontap-s3-appvault1
  cleanUpAdditionalExecHooks: true
  cleanUpArchivedExecHooks: false
  resourceFilter: {}
  runArchivedExecHooks: true

# kubectl create -f postgres-app-bir.yaml -n postgres

Es wird überprüft, ob die PostgreSQL-Anwendungsbereitstellung, der Service, das Pod und die PVCs wiederhergestellt sind.

Wiederherstellung der Anwendung in einem anderen Namensraum

Zuerst einen neuen Namespace erstellen, in dem die App wiederhergestellt werden soll, in diesem Beispiel postgres2. Ein stündliches Backup, das durch den Zeitplan erstellt wurde, ist jetzt für die postgres-app verfügbar. Dieses Backup kann verwendet werden, um die Anwendung im neuen Namespace postgres2 wiederherzustellen.

# tp create backuprestore --appvault ontap-s3-appvault1 --path postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/backups/hourly-cbd11-20260831124500_2b57bda9-5cb0-4c8f-ae7a-20f94c23c3b9 --namespace-mapping postgres:postgres2 -n postgres2 --dry-run>postgres-app-postgres2-br.yaml

Um den Pfad für die Sicherung zu erhalten, verwenden Sie den Befehl kubectl get backups <backup-name> -n postgres -o jsonpath='{.status.appArchivePath}'.

apiVersion: protect.trident.netapp.io/v1
kind: BackupRestore
metadata:
  annotations:
    protect.trident.netapp.io/max-parallel-restore-jobs: "25"
  name: postgres-app-z2woek
  namespace: postgres2
spec:
  appArchivePath: postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/backups/hourly-cbd11-20260831124500_2b57bda9-5cb0-4c8f-ae7a-20f94c23c3b9
  appVaultRef: ontap-s3-appvault1
  cleanUpAdditionalExecHooks: true
  cleanUpArchivedExecHooks: false
  namespaceMapping:
  - destination: postgres2
    source: postgres
  resourceFilter: {}
  runArchivedExecHooks: true
  skipApplicationCreation: false

# kubectl create -f postgres-app-postgres2-br.yaml -n postgres2

Es sollte überprüft werden, ob die Postgres-Anwendungsobjekte und PVCs im neuen Namespace postgres2 erstellt wurden.

Die Postgres Anwendung wurde im neuen Namensraum wiederhergestellt.

Die App mit Snapshots schützen

Snapshots erstellen

Erstellen eines On-Demand-Snapshots Ein Snapshot für die App wird erstellt und der AppVault angegeben, in dem die Snapshot-Metadaten gespeichert werden. Die Volume-Snapshot-Daten selbst werden nicht in den Objektspeicher kopiert, sondern verbleiben im Storage-Backend.

# tp create snapshot postgres-app-snapshot-ondemand --app postgres-app --appvault ontap-s3-appvault1 -n postgres --dry-run>postgres-app-snapshot-ondemand.yaml

# cat postgres-app-snapshot-ondemand.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Snapshot
metadata:
  name: postgres-app-snapshot-ondemand
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault1
  applicationRef: postgres-app
  cleanupSnapshot: false
  completionTimeout: 0s
  volumeSnapshotsCreatedTimeout: 0s
  volumeSnapshotsReadyToUseTimeout: 0s

# kubectl create -f postgres-app-snapshot-ondemand.yaml
snapshot.protect.trident.netapp.io/postgres-app-snapshot-ondemand created

Zeitplan für Snapshots erstellen Ein Zeitplan für die Snapshots wird erstellt. Die Granularität und die Anzahl der aufzubewahrenden Snapshots werden angegeben.

# tp create schedule snapshot-schedule1 --app postgres-app --appvault ontap-s3-appvault1 --granularity Hourly --minute 55 --snapshot-retention 1 -n postgres --dry-run>postgres-app-snapshot-schedule1.yaml

# cat postgres-app-snapshot-schedule1.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: snapshot-schedule1
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault1
  applicationRef: postgres-app
  backupRetention: "0"
  dayOfMonth: ""
  dayOfWeek: ""
  enabled: true
  granularity: Hourly
  hour: ""
  minute: "55"
  recurrenceRule: ""
  replicationRetention: "0"
  runImmediately: false
  snapshotRetention: "1"

# kubectl create -f postgres-app-snapshot-schedule1.yaml
schedule.protect.trident.netapp.io/snapshot-schedule1 created

Wiederherstellung aus Snapshot

Wiederherstellung der Anwendung aus einem Snapshot im selben Namespace

Bevor Sie die Anwendung löschen, vergewissern Sie sich, dass sich der Snapshot, von dem Sie die Anwendung wiederherstellen möchten, im Completed Status befindet. Ein Snapshot, der sich noch in Bearbeitung befindet oder fehlgeschlagen ist, kann nicht zur Wiederherstellung der Anwendung verwendet werden.

kubectl get snapshot -n postgres

Nachdem bestätigt wurde, dass der Snapshot-Status Completed korrekt ist, werden die Anwendungsobjekte und die PVCs für Postgres aus dem Postgres-Namespace gelöscht.

Ein Snapshot-in-Place-Restore-Objekt aus dem Snapshot erstellen.

# tp create sir postgres-restore-from-snapshot --snapshot postgres/hourly-f1dd9-20260831135500 -n postgres --dry-run > postgres-sir.yaml

# cat postgres-sir.yaml
apiVersion: protect.trident.netapp.io/v1
kind: SnapshotInplaceRestore
metadata:
  name: postgres-restore-from-snapshot
  namespace: postgres
spec:
  appArchivePath: postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/snapshots/20260831135500_hourly-f1dd9-20260831135500_36c2bd2a-9405-4424-88a7-75e6bbc5b315
  appVaultRef: ontap-s3-appvault1
  cleanUpAdditionalExecHooks: true
  cleanUpArchivedExecHooks: false
  resourceFilter: {}
  runArchivedExecHooks: true

# kubectl create -f postgres-sir.yaml
snapshotinplacerestore.protect.trident.netapp.io/postgres-restore-from-snapshot created

Es sollte sichergestellt sein, dass die Objekte und PVCs der Anwendung im postgres-Namespace erstellt wurden.

Die Postgres Anwendung wurde aus einem Snapshot wiederhergestellt.

Wiederherstellung der Anwendung aus einem Snapshot in einen anderen Namensraum

Die Anwendung im Namespace postgres2, die zuvor aus dem Backup wiederhergestellt wurde, wird gelöscht.

Das Snapshot-Wiederherstellungsobjekt wird aus dem Snapshot erstellt, und die Namespace-Zuordnung wird bereitgestellt.

# tp create sr postgres-sr --snapshot postgres/hourly-f1dd9-20260831135500 --namespace-mapping postgres:postgres2 -n postgres2 --dry-run>postgres-sr.yaml

# cat postgres-sr.yaml
apiVersion: protect.trident.netapp.io/v1
kind: SnapshotRestore
metadata:
  name: postgres-sr
  namespace: postgres2
spec:
  appArchivePath: postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/snapshots/20260831135500_hourly-f1dd9-20260831135500_36c2bd2a-9405-4424-88a7-75e6bbc5b315
  appVaultRef: ontap-s3-appvault1
  cleanUpAdditionalExecHooks: true
  cleanUpArchivedExecHooks: false
  namespaceMapping:
  - destination: postgres2
    source: postgres
  resourceFilter: {}
  runArchivedExecHooks: true
  skipApplicationCreation: false

# kubectl create -f postgres-sr.yaml
snapshotrestore.protect.trident.netapp.io/postgres-sr created

Es sollte überprüft werden, ob die Objekte und PVCs der Anwendung im Namespace postgres2 wiederhergestellt sind.

Anwendung in einem anderen Namensraum wiederhergestellt