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

Trident-Installation und Erstellung von Trident-Objekten

05/12/2025 Beitragende

PDFs

In diesem Abschnitt wird beschrieben, wie Sie Trident mithilfe des Red hat Certified Trident Operators auf dem OpenShift-Cluster installieren und die Workerknoten (zum Zeitpunkt der Trident-Installation) auf den Blockzugriff vorbereiten. Das Verfahren ist für OpenShift-Cluster vor Ort, in der Cloud sowie für Managed Red OpenShift Cluster in AWS (ROSA), die FSX for NetApp ONTAP (FSxN)-Storage nutzen, gleich. Dieser Abschnitt enthält auch Schritt-für-Schritt-Anleitungen zum Erstellen von Objekten des Trident-Back-End und der Storage-Klasse, wenn ONTAP oder FSxN als Backing-Store für Container und VMs in den OpenShift-Clustern verwendet wird. Das Back-End-Objekt Trident enthält alle Details, die erforderlich sind, um eine Verbindung zum Back-End-ONTAP- oder FSxN-Storage-System herzustellen und Volumes über das angegebene Protokoll dynamisch bereitzustellen. Mithilfe des Storage-Klassen-Objekts können die Container-Applikationen und VMs den Storage nur unter Verwendung des Typs und der Kapazität anfordern. Konnektivität und andere Backend-Details sind nicht erforderlich.

Wenn Sie VMs in OpenShift Virtualization erstellen müssen, muss Trident installiert sein und die Backend-Objekte und die Storage-Klasse-Objekte müssen im OpenShift Cluster erstellt werden, bevor OpenShift Virtualization auf dem Cluster installiert wird (On-Premises und ROSA). Die Standard-Speicherklasse und die Standard-Snapshot-Klasse des Volumes müssen auf den Trident-Speicher und die Snapshot-Klasse im Cluster eingestellt werden. Nur bei entsprechender Konfiguration kann OpenShift Virtualization die Golden Images lokal für die VM-Erstellung mithilfe von Vorlagen zur Verfügung stellen.

Wenn der OpenShift Virtualization Operator vor der Installation von Trident installiert wird, können Sie mit dem folgenden Befehl die Golden Images löschen, die mit einer anderen Storage-Klasse erstellt wurden, und dann OpenShift Virtualization die Golden Images unter Verwendung der Trident-Storage-Klasse erstellen lassen, indem sichergestellt wird, dass die Standardwerte für Trident-Speicher und Volume-Snapshots festgelegt sind.

oc delete dv,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron

Um yaml-Beispieldateien zu erhalten, um Trident-Objekte für FSxN-Speicher für ROSA-Cluster zu erstellen, und um eine yaml-Beispieldatei für die VolumeSnapshotClass zu erhalten, blättern Sie auf dieser Seite nach unten.

Trident installieren

Installation von Trident mit dem Red hat Certified Operator

In diesem Abschnitt werden Einzelheiten zur Installation von Trident mit dem Red hat Certified Trident Operator für andere Möglichkeiten zur Installation von Trident zur Verfügung gestellt"Weitere Informationen finden Sie in der Trident-Dokumentation". Mit der Veröffentlichung von Trident 25.02 können Benutzer von Trident in Red hat OpenShift vor Ort und in der Cloud sowie Managed Services wie Red hat OpenShift Service auf AWS jetzt Trident über den Trident Certified Operator vom Operator Hub aus installieren. Dies ist für die OpenShift-Benutzer-Community von Bedeutung, da Trident bisher nur als Community-Betreiber verfügbar war.

Der Vorteil des Red hat Certified Trident Betreibers ist, dass die Grundlage für den Betreiber und seine Container vollständig von NetApp unterstützt wird, wenn sie mit OpenShift (ob vor Ort, in der Cloud oder als Managed Service mit ROSA) verwendet werden. Darüber hinaus ist NetApp Trident kostenlos für den Kunden erhältlich. Sie müssen es also nur über den zertifizierten Betreiber installieren, der verifiziert wurde, dass er nahtlos mit Red hat OpenShift arbeitet und für ein einfaches Lifecycle-Management verpackt ist.

Darüber hinaus bietet der Trident 25.02 Operator (und zukünftige Versionen) den optionalen Vorteil, die Workerknoten auf iSCSI vorzubereiten. Dies ist insbesondere dann von Vorteil, wenn Sie Ihre Workloads auf ROSA-Clustern bereitstellen und das iSCSI-Protokoll mit FSxN verwenden möchten, insbesondere für VM-Workloads mit OpenShift Virtualization. Die Herausforderung bei der Vorbereitung von Workerknoten auf iSCSI auf ROSA-Clustern mit FSxN wurde durch diese Funktion bei der Installation von Trident auf dem Cluster gemindert.

Die Installationsschritte, die den Operator verwenden, sind gleich, unabhängig davon, ob Sie ihn auf einem On-Premises-Cluster oder auf ROSA installieren. Um Trident über den Bediener zu installieren, klicken Sie auf den Bedienerhub und wählen Sie Certified NetApp Trident aus. Auf der Seite Installieren ist standardmäßig die neueste Version ausgewählt. Klicken Sie auf Installieren. Nabe des Bedieners

Installieren

Klicken Sie nach der Installation des Bedieners auf View Operator und erstellen Sie dann eine Instanz des Trident Orchestrator. Wenn Sie die Worker-Knoten für den iSCSI-Speicherzugriff vorbereiten möchten, wechseln Sie zur yaml-Ansicht, und ändern Sie den nodePrep-Parameter, indem Sie iscsi hinzufügen.

Fügen Sie iscsi für die Node-Vorbereitung hinzu

Sollten nun alle Trident-Pods in Ihrem Cluster ausgeführt werden. Trident installiert

Um zu überprüfen, ob iSCSI-Tools auf den Worker-Nodes des OpenShift-Clusters aktiviert wurden, melden Sie sich bei den Worker-Nodes an und überprüfen Sie, ob die Einträge iscsid, multipathd Active und Multipath.conf in der Datei wie gezeigt angezeigt werden.

Iscsid wird ausgeführt

Multipath wird ausgeführt

Multipathconf-Datei wird ausgeführt

Videovorführung

Das folgende Video zeigt eine Demonstration der Installation von Trident unter Verwendung von Red hat Certified Trident Operator

Installation von Trident 25.02.1 mit dem zertifizierten Trident-Operator in OpenShift

Trident-Konfiguration für lokales OpenShift-Cluster

Trident Back-End und Storage-Klasse für NAS

cat tbc-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-nas-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: <cluster management lif>
  backendName: tbc-nas
  svm: zoneb
  storagePrefix: testzoneb
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-nas-secret

cat sc-nas.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nas
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"
allowVolumeExpansion: true

Trident Back-End und Storage Class für iSCSI

# cat tbc-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-iscsi-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <management LIF>
  backendName: ontap-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-iscsi-secret

# cat sc-iscsi.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-iscsi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

Trident-Back-End und Storage-Klasse für NVMe/TCP

# cat tbc-nvme.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-nvme-secret
type: Opaque
stringData:
  username: <cluster admin password>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nvme
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <cluster management LIF>
  backendName: backend-tbc-ontap-nvme
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-nvme-secret

# cat sc-nvme.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nvme
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

Trident Back-End und Storage-Klasse für FC

# cat tbc-fc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-fc-secret
type: Opaque
stringData:
  username: <cluster admin password>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-fc
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <cluster mgmt lif>
  backendName: tbc-fc
  svm: openshift-fc
  sanType: fcp
  storagePrefix: demofc
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-fc-secret

# cat sc-fc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-fc
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

Trident-Konfiguration für ROSA-Cluster mit FSxN-Speicher

Back-End- und Storage-Klasse von Trident für FSxN NAS

#cat tbc-fsx-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-fsx-ontap-nas-secret
  namespace: trident
type: Opaque
stringData:
  username: <cluster admin lif>
  password: <cluster admin passwd>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-fsx-ontap-nas
  namespace: trident
spec:
  version: 1
  backendName: fsx-ontap
  storageDriverName: ontap-nas
  managementLIF: <Management DNS name>
  dataLIF: <NFS DNS name>
  svm: <SVM NAME>
  credentials:
    name: backend-fsx-ontap-nas-secret

# cat sc-fsx-nas.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: trident-csi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  fsType: "ext4"
allowVolumeExpansion: True
reclaimPolicy: Retain

Trident-Back-End und Storage-Klasse für FSxN iSCSI

# cat tbc-fsx-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-fsx-iscsi-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: fsx-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <management LIF>
  backendName: fsx-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-iscsi-secret

# cat sc-fsx-iscsi.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-fsx-iscsi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

Snapshot Klasse des Trident-Volumes wird erstellt

Snapshot Klasse für das Trident Volume

# cat snapshot-class.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: trident-snapshotclass
driver: csi.trident.netapp.io
deletionPolicy: Retain

Sobald Sie die erforderlichen yaml-Dateien für die Backend-Konfiguration und die Konfiguration der Storage-Klasse sowie die Snapshot-Konfigurationen eingerichtet haben, können Sie mit dem folgenden Befehl das Trident-Backend, die Storage-Klasse und die Snapshot-Klasse-Objekte erstellen

oc create -f <backend-filename.yaml> -n trident
oc create -f < storageclass-filename.yaml>
oc create -f <snapshotclass-filename.yaml>

Festlegen der Standardwerte mit Trident-Speicher und Snapshot-Klasse

Sie können jetzt die erforderliche Trident-Storage-Klasse und die Volume-Snapshot-Klasse als Standard im OpenShift-Cluster festlegen. Wie bereits erwähnt, ist die Einstellung der Standard-Storage-Klasse und der Volume-Snapshot-Klasse erforderlich, damit OpenShift Virtualization die Golden-Image-Quelle zur Erstellung von vms aus Standardvorlagen zur Verfügung stellt.

Sie können die Trident-Storage-Klasse und die Snapshot-Klasse als Standard festlegen, indem Sie die Anmerkung von der Konsole aus bearbeiten oder das Patchen von der Befehlszeile mit den folgenden Methoden ausführen:

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

storageclass.kubevirt.io/is-default-virt-class: true
or
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'

Sobald diese Einstellung festgelegt ist, können Sie alle bereits vorhandenen dv- und VolumeSnapShot-Objekte mit dem folgenden Befehl löschen:

oc delete dv,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron