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

Kubernetes-Cluster-Anforderungen für NetApp Disaster Recovery

09/25/2026 Beitragende

PDFs

Vor der Konfiguration von NetApp Disaster Recovery for Kubernetes sollte jeder Kubernetes-Cluster so vorbereitet werden, dass die Bereitschaft für Replikation und Failover sichergestellt ist. Der Schutz gilt üblicherweise für einen Quell-Cluster und einen separaten Ziel-Cluster; diese Verfahren sind auf jedem Cluster des Paares durchzuführen.

Voraussetzungen

Bevor Sie die Anforderungen für den Kubernetes-Cluster konfigurieren, stellen Sie sicher, dass Sie Ihren Kubernetes-Cluster und Ihre ONTAP-Cluster konfiguriert haben.
Stellen Sie sicher, dass Sie eine unterstützte Version von Kubernetes verwenden. Disaster Recovery unterstützt "jede derzeit von Trident Protect unterstützte Kubernetes-Version".
Die entsprechenden Einstellungen "Berechtigungen für Trident Protect" konfigurieren.

Kubernetes-Cluster

Stellen Sie für jeden Kubernetes-Cluster Folgendes sicher:

Sie haben Administrator `kubectl`zugriff auf jeden Kubernetes-Cluster.
Helm 3 ist dort verfügbar, wo Installationsbefehle ausgeführt werden.

ONTAP-Anforderungen

Stellen Sie für jeden ONTAP Cluster sicher, dass Sie die folgenden Ressourcen konfiguriert haben:

Management LIF: Wird von Trident für den Zugriff auf die Management-API verwendet.
Data (NFS) LIF: Wird für den NFS-Datenverkehr für Volumes verwendet.
SVM name: Die Storage-VM, die die Volumes hostet.
Zugangsdaten: Das Konto, das Trident verwendet, in der Regel admin oder ein SVM-bezogenes Konto.
Die Worker-Knoten müssen in der Lage sein, ONTAP-Management- und Daten-LIFs zu erreichen.
Wenn Sie autoExportPolicy mit CIDR-Beschränkungen verwenden, schließen Sie Ihre Knotensubnetze ein.

Installieren Sie NetApp Trident CSI

"Installieren Sie den Trident Operator auf jedem Cluster^."

Wenn Sie Trident bereits installiert haben, überprüfen Sie die Installation mit dem Befehl
kubectl get pods -n trident. Wenn die Installation erfolgreich ist, sehen Sie den Trident-Controller, die Node-Pods (DaemonSet) und der Status des Operators ist nach einigen Minuten Running.

Erstelle ein Kubernetes-Secret

Erstellen Sie ein Kubernetes-Secret im Namespace:

kubectl create secret generic trident-ontap-secret -n <namespace> \
  --from-literal=username=<adminOrOtherUsername> \
  --from-literal=password='<YOUR_ONTAP_PASSWORD>'

Weitere Informationen finden Sie unter "Erstelle ein Kubernetes-Secret im Namespace".

Erstelle die TridentBackendConfig

Einen Link anwenden:https://docs.netapp.com/us-en/trident/trident-use/backend-kubectl.html#step-2-create-the-tridentbackendconfig-cr[TridentBackendConfig, der auf Ihre SVM verweist. Beispielsweise:

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: <name>
  namespace: <trident>
spec:
  version: 1
  backendName: <name>
  storageDriverName: <driverName>
  managementLIF: <MANAGEMENT_LIF_IP>
  dataLIF: <DATA_LIF_IP>
  svm: <SVM_NAME>
  autoExportPolicy: true
  autoExportCIDRs:
    - 0.0.0.0/0
  credentials:
    name: trident-ontap-secret

Sie können die Konfiguration mit dem Befehl kubectl get TridentBackendConfig -n trident überprüfen. Wenn die Konfiguration erfolgreich war, sollte die phase Ausgabe als Gebunden und der status Status als Erfolg angezeigt werden. Wenn der Status Fehlgeschlagen ist, überprüfen Sie die Schritte zu "Weitere Details" und beheben Sie etwaige Probleme wie falsche Anmeldeinformationen oder fehlende Netzwerkverbindung.

Konfigurieren Sie die Speicherklasse

"Erstellen Sie das Speicherklassenobjekt". Verwenden Sie den Provisioner csi.trident.netapp.io. Zum Beispiel:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <name>
provisioner: csi.trident.netapp.io
parameters:
  backendType: "<type>"
  storagePools: "<pool>:.*"
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

Sie können optional eine Speicherklasse als Standard für den Cluster festlegen. Sie können nur eine Standard-Speicherklasse pro Cluster festlegen.

kubectl patch storageclass ontap-backend \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Die von Trident Protect replizierten Anwendungs-PVCs müssen Speicher verwenden, der über Trident bereitgestellt wurde (diesen StorageClass oder einen anderen, den Sie mit den richtigen storagePools Selektoren definieren).

Damit Trident Protect Ihre Anwendungsdaten replizieren kann, müssen die Anwendungen Speicher nutzen, der von Trident verwalteten ONTAP Volumes bereitgestellt wird. Sie können diese Speicherklasse oder eine andere verwenden, aber sie muss so konfiguriert sein, dass sie das ONTAP Backend über Trident nutzt.

Konfigurieren von benutzerdefinierten Ressourcendefinitionen (CRD) für Snapshots von Volume-Gruppen

Installieren Sie das "Snapshot CRD und Snapshot Controller". Diese Installationen sind für Volume-Snapshots in Trident Protect erforderlich.

Überprüfen Sie die benutzerdefinierten Ressourcendefinitionen mit dem Befehl:

kubectl get crd volumesnapshots.snapshot.storage.k8s.io
kubectl get crd volumesnapshotcontents.snapshot.storage.k8s.io
kubectl get crd volumesnapshotclasses.snapshot.storage.k8s.io

Konfigurieren von Snapshots von Volumengruppen

"Konfigurieren Sie die VolumeSnapshotClass für Trident."

kubectl patch volumesnapshotclasses.snapshot.storage.k8s.io trident-snapshotclass \
  -p '{"metadata": {"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}' \
  --type=merge

Optional können Sie die Volume-Snapshot-Klasse als Standardklasse festlegen. Verwenden Sie deletionPolicy: Retain, wenn verwaiste Kubernetes-Snapshot-Objekte Snapshots auf ONTAP hinterlassen sollen.

Verifizierungszusammenfassung

Überprüfen Befehl Erwartete Ausgabe

Überprüfen	Befehl	Erwartete Ausgabe
Trident läuft	`kubectl get pods -n trident`	Trident läuft erfolgreich
Das Backend ist gesund	`kubectl get TridentBackendConfig -n trident`	Gebunden/Erfolg
Der Speicher ist offen	`kubectl get storageclass`	Die Ausgabe umfasst Ihre Trident class
Snapshot-APIs	`kubectl get volumesnapshotclass`	CRDs existieren; listet Trident Treiber auf

Trident läuft

kubectl get pods -n trident

Trident läuft erfolgreich

Das Backend ist gesund

kubectl get TridentBackendConfig -n trident

Gebunden/Erfolg

Der Speicher ist offen

kubectl get storageclass

Die Ausgabe umfasst Ihre Trident class

Snapshot-APIs

kubectl get volumesnapshotclass

CRDs existieren; listet Trident Treiber auf

Nachdem Sie den Status aller Ressourcen überprüft haben, stellen Sie Ihre Workloads bereit oder "migrieren" mithilfe Ihrer Trident StorageClass bereit. Wenn Sie "Kubernetes-Cluster zu einer Website hinzufügen" , stellt Disaster Recovery Anweisungen zur Installation von Trident Protect auf einem Cluster und zur Registrierung in Ihrer Disaster Recovery-Umgebung bereit.

Lesen Sie die Installationsanleitung für Trident Protect.

Erstellen Sie einen Trident Protect-Namespace:

kubectl create namespace trident-protect
Erstellen Sie ein Kubernetes-Secret mithilfe der Client-ID und des Client-Secrets, um die OCCM-Authentifizierungsdaten zu erstellen.

kubectl create secret generic occmauthcreds --namespace=trident-protect --from-literal=client_id=<clientID> --from-literal=client_secret=<clientSecret>
Füge das Helm-Repository hinzu oder aktualisiere es:

helm repo add --force-update netapp-trident-protect https://netapp.github.io/trident-protect-helm-chart
Installieren oder aktualisieren Sie Trident Protect und Trident Protect Connector:
helm upgrade --install trident-protect netapp-trident-protect/trident-protect-console \ --version 100.2605.0-console --namespace trident-protect --set clusterName=<clusterName> --set trident-protect.cbs.accountID=<accountID> --set trident-protect.cbs.agentID=<agentID> --set trident-protect.cbs.proxySecretName=occmauthcreds --set trident-protect.cbs.proxyHostIP=<IPaddress>

NetApp Console-Rollen

Nach der Durchführung Ihrer Trident Protect und Kubernetes Konfigurationen,"Es sollte sichergestellt sein, dass die richtigen NetApp Console Rollen für NetApp Disaster Recovery vorhanden sind, damit Erkennung, Failover und andere Aufgaben ausgeführt werden können."