Skip to main content
NetApp public and hybrid cloud solutions
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Datenschutz für Container-Apps in OpenShift Container Platform mit Trident Protect

Beitragende banum-netapp kevin-hoke
Änderungen vorschlagen
PDFs

Dieser Abschnitt des Referenzdokuments bietet Details zur Erstellung von Snapshots und Backups von Container Apps mit Trident Protect. NetApp Trident Protect bietet erweiterte Funktionen für das Management von Anwendungsdaten, die die Funktionalität und Verfügbarkeit zustandsbehafteter Kubernetes-Anwendungen verbessern, die durch NetApp ONTAP-Speichersysteme und den NetApp Trident CSI Storage Provisioner unterstützt werden. Trident Protect erstellt Anwendungssnapshots und Backups. Das bedeutet, dass Snapshots und Backups nicht nur für Anwendungsdaten in persistenten Volumes, sondern auch für Anwendungsmetadaten erstellt werden. Die von Trident Protect erstellten Snapshots und Backups können in einem der folgenden Objektspeicher gespeichert und zu einem späteren Zeitpunkt daraus wiederhergestellt werden.

  • AWS S3

  • Azure Blob-Speicher

  • Google Cloud-Speicher

  • ONTAP S3

  • StorageGrid

  • Jeder andere S3-kompatible Speicher

Trident Protect nutzt das Kubernetes-Modell der rollenbasierten Zugriffssteuerung (RBAC). Standardmäßig stellt Trident Protect einen einzelnen System-Namespace namens trident-protect und das zugehörige Standard-Dienstkonto bereit. Wenn Sie eine Organisation mit vielen Benutzern oder spezifischen Sicherheitsanforderungen haben, können Sie die RBAC-Funktionen von Trident Protect nutzen, um den Zugriff auf Ressourcen und Namespaces detaillierter zu steuern.

Weitere Informationen zu RBAC in Trident Protect finden Sie im "Trident Protect Dokumentation"

Hinweis Der Clusteradministrator hat Zugriff auf Ressourcen im Standard-Trident-Protect-Namespace und kann auch auf Ressourcen in allen anderen Namespaces zugreifen. Benutzer können im Trident-Protect-Namespace keine benutzerdefinierten Ressourcen (CRs) für die Anwendungsdatenverwaltung wie Snapshot- und Backup-CRs erstellen. Als bewährte Methode müssen Benutzer diese CRs im Anwendungsnamespace erstellen.

Trident Protect kann mithilfe der in der Dokumentation bereitgestellten Anweisungen installiert werden "hier,". In diesem Abschnitt wird der Workflow für den Datenschutz von Containeranwendungen und die Wiederherstellung der Anwendungen mit Trident Protect gezeigt. 1. Snapshot-Erstellung (auf Anforderung oder geplant) 2. Wiederherstellung aus Snapshot (Wiederherstellung im selben oder in einem anderen Namespace) 3. Backup-Erstellung 4. Wiederherstellung aus Backup

Voraussetzung

Vor dem Erstellen der Snapshots und Backups für eine Anwendung muss der Objektspeicher in Trident Protect konfiguriert werden, um die Snapshots und Backups zu speichern. Dies geschieht mithilfe des Bucket-CR. Nur Administratoren können einen Bucket-CR erstellen und konfigurieren. Der Bucket-CR ist in Trident Protect als AppVault bekannt. AppVault-Objekte sind die deklarative Kubernetes-Workflow-Repräsentation eines Speicher-Buckets. Ein AppVault-CR enthält die Konfigurationen, die erforderlich sind, damit ein Bucket in Schutzvorgängen wie Backups, Snapshots, Wiederherstellungsvorgängen und SnapMirror-Replikation verwendet werden kann.

In diesem Beispiel zeigen wir die Verwendung von ONTAP S3 als Objektspeicher. Hier ist der Workflow zum Erstellen von AppVault CR für ONTAP S3: 1. Erstellen Sie einen S3-Objektspeicherserver in der SVM im ONTAP-Cluster. 2. Erstellen Sie einen Bucket im Objektspeicherserver. 3. Erstellen Sie einen S3-Benutzer in der SVM. Bewahren Sie den Zugriffsschlüssel und den geheimen Schlüssel an einem sicheren Ort auf. 4. Erstellen Sie in OpenShift ein Secret, um die ONTAP S3-Anmeldeinformationen zu speichern. 5. Erstellen Sie ein AppVault-Objekt für ONTAP S3

Trident Protect AppVault für ONTAP S3 konfigurieren

Beispiel-YAML-Datei zur Konfiguration von Trident Protect mit ONTAP S3 als AppVault

# alias tp='tridentctl-protect'

appvault-secret.yaml

apiVersion: v1
stringData:
  accessKeyID: "<access key id created for a user to access ONTAP S3 bucket>"
  secretAccessKey: "corresponding Secret Access Key"
#data:
# base 64 encoded values
#  accessKeyID: <base64 access key id created for a user to access ONTAP S3 bucket>
#  secretAccessKey: <base 64  Secret Access Key>
kind: Secret
metadata:
  name: appvault-secret
  namespace: trident-protect
type: Opaque

appvault.yaml

apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: ontap-s3-appvault
  namespace: trident-protect
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: <bucket-name for storing the snapshots and backups>
      endpoint: <endpoint IP for S3>
      secure: "false"
      skipCertValidation: "true"
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: appvault-secret
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: appvault-secret
  providerType: OntapS3

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

AppVault erstellt

Beispiel-YAML-Datei zum Installieren der PostgreSQL-App 

postgres.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:14
        env:
        - name: POSTGRES_USER
          #value: "myuser"
          value: "admin"
        - name: POSTGRES_PASSWORD
          #value: "mypassword"
          value: "adminpass"
        - name: POSTGRES_DB
          value: "mydb"
        - name: PGDATA
          value: "/var/lib/postgresql/data/pgdata"
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  selector:
    app: postgres
  ports:
  - protocol: TCP
    port: 5432
    targetPort: 5432
  type: ClusterIP

Now create the Trident Protect application CR for the postgres app. Include the objects in the namespace postgres and create it in the postgres namespace.
# tp create app postgres-app --namespaces postgres -n postgres

App erstellt

Snapshots erstellen

Erstellen eines On-Demand-Snapshots

# tp create snapshot postgres-snap1 --app postgres-app --appvault ontap-s3-appvault -n postgres
Snapshot "postgres-snap1" created.

Snapshot erstellt

Snapshot-PVC erstellt

Erstellen eines Zeitplans Mit dem folgenden Befehl werden täglich um 15:33 Uhr Snapshots erstellt und zwei Snapshots und Backups aufbewahrt.

# tp create schedule schedule1 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres
Schedule "schedule1" created.

Zeitplan1 erstellt

Erstellen eines Zeitplans mit YAML

# tp create schedule schedule2 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres --dry-run > hourly-snapshotschedule.yaml

cat hourly-snapshotschedule.yaml

apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  creationTimestamp: null
  name: schedule2
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault
  applicationRef: postgres-app
  backupRetention: "2"
  dataMover: Restic
  dayOfMonth: ""
  dayOfWeek: ""
  enabled: true
  granularity: Hourly
  #hour: "15"
  minute: "33"
  recurrenceRule: ""
  snapshotRetention: "2"
status: {}

Zeitplan2 erstellt

Sie können die nach diesem Zeitplan erstellten Snapshots sehen.

Snap planmäßig erstellt

Außerdem werden Volume-Snapshots erstellt.

PVC Snap termingerecht erstellt

Löschen Sie die Anwendung, um den Verlust der Anwendung zu simulieren 
# oc delete deployment/postgres -n postgres
# oc get pod,pvc -n postgres
No resources found in postgres namespace.
Wiederherstellen aus Snapshot im selben Namespace 
# tp create sir postgres-sir --snapshot postgres/hourly-3f1ee-20250214183300 -n postgres
SnapshotInplaceRestore "postgres-sir" created.

Herr erstellt

Die Anwendung und ihr PVC werden im selben Namespace wiederhergestellt.

App wiederhergestellt, Sir

Wiederherstellen aus Snapshot in einem anderen Namespace 
# tp create snapshotrestore postgres-restore --snapshot postgres/hourly-3f1ee-20250214183300 --namespace-mapping postgres:postgres-restore -n postgres-restore
SnapshotRestore "postgres-restore" created.

SnapRestore erstellt

Sie können sehen, dass die Anwendung in einem neuen Namespace wiederhergestellt wurde.

App wiederhergestellt, SnapRestore

Backups erstellen

Erstellen eines On-Demand-Backups

# tp create backup postgres-backup1 --app postgres-app --appvault ontap-s3-appvault -n postgres
Backup "postgres-backup1" created.

Sicherung erstellt

Zeitplan für die Sicherung erstellen

Die täglichen und stündlichen Sicherungen in der obigen Liste werden anhand des zuvor eingerichteten Zeitplans erstellt.

# tp create schedule schedule1 --app postgres-app --appvault ontap-s3-appvault --backup-retention 2 --snapshot-retention 2 --granularity Daily --hour 15 --minute 33 --data-mover Restic -n postgres
Schedule "schedule1" created.

Zuvor erstellter Zeitplan

Wiederherstellen aus einer Sicherung

Löschen Sie die Anwendung und PVCs, um einen Datenverlust zu simulieren.

Zuvor erstellter Zeitplan

Im selben Namespace wiederherstellen #tp create bir postgres-bir --backup postgres/hourly-3f1ee-20250224023300 -n postgres BackupInplaceRestore „postgres-bir“ erstellt.

Wiederherstellung im selben Namespace

Die Anwendung und die PVCs werden im selben Namespace wiederhergestellt.

Anwendung und PVCs werden im selben Namespace wiederhergestellt

In einem anderen Namespace wiederherstellen Erstellen Sie einen neuen Namespace. Stellen Sie aus einer Sicherung im neuen Namespace wieder her.

Wiederherstellung in einem anderen Namespace

Migrieren von Anwendungen

Um eine Anwendung auf einen anderen Cluster zu klonen oder zu migrieren (führen Sie einen clusterübergreifenden Klon durch), erstellen Sie eine Sicherung auf dem Quell-Cluster und stellen Sie die Sicherung anschließend auf einem anderen Cluster wieder her. Stellen Sie sicher, dass Trident Protect auf dem Ziel-Cluster installiert ist.

Führen Sie im Quellcluster die im folgenden Bild gezeigten Schritte aus:

Wiederherstellung in einem anderen Namespace

Wechseln Sie vom Quellcluster zum Zielcluster. Stellen Sie dann sicher, dass vom Zielclusterkontext aus auf den AppVault zugegriffen werden kann, und rufen Sie den AppVault-Inhalt vom Zielcluster ab.

Kontext zum Ziel wechseln

Verwenden Sie den Sicherungspfad aus der Liste und erstellen Sie ein Backuprestore-CR-Objekt, wie im folgenden Befehl gezeigt.

# tp create backuprestore backup-restore-cluster2 --namespace-mapping postgres:postgres --appvault ontap-s3-appvault --path postgres-app_4d798ed5-cfa8-49ff-a5b6-c5e2d89aeb89/backups/postgres-backup-cluster1_ec0ed3f3-5500-4e72-afa8-117a04a0b1c3 -n postgres
BackupRestore "backup-restore-cluster2" created.

Am Ziel wiederherstellen

Sie können jetzt sehen, dass die Anwendungspods und die PVCs im Zielcluster erstellt werden.

App auf dem Zielcluster