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

Installieren Sie Trident auf einem Red Hat OpenShift Cluster und erstellen Sie Speicherobjekte

07/14/2026 Beitragende

PDFs

Installieren Sie Trident mit dem Red Hat Certified Trident Operator und erstellen Sie Speicherobjekte für ONTAP und Amazon FSx für NetApp ONTAP, um die dynamische Volumenbereitstellung für Container und VMs zu aktivieren. Bereiten Sie Worker-Knoten bei Bedarf für den Blockzugriff vor.

Bevor Sie beginnen

Führen Sie die Schritte auf dieser Seite durch, bevor Sie OpenShift Virtualization installieren. OpenShift Virtualization erfordert eine standardmäßige, von Trident unterstützte StorageClass und VolumeSnapshotClass, um Golden Images für VM-Vorlagen zu erstellen.
Wenn Sie OpenShift Virtualization bereits vor der Konfiguration von Trident installiert haben, löschen Sie alle Golden Images, die mit einer anderen Speicherklasse erstellt wurden. Nachdem Sie Trident als Standard festgelegt haben, erstellt OpenShift Virtualization die Golden Images mit Trident-Speicher neu.
```
oc delete dv,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron
```

Schritt 1: Trident installieren

Der Red Hat Certified Trident Operator wird von NetApp für OpenShift On-Premises, in öffentlichen Clouds und in Managed Services wie ROSA unterstützt. Ab Trident 25.02 kann der Operator auch Worker-Knoten für iSCSI vorbereiten, wenn Sie Amazon FSx for NetApp ONTAP verwenden und planen, OpenShift Virtualization VM-Workloads auszuführen.

Weitere Installationsoptionen finden Sie unter "die Trident Dokumentation".

Schritte

In OperatorHub wählen Sie Certified NetApp Trident.

Beispiel anzeigen
Auf der Seite Install die neueste Version beibehalten und Install auswählen.

Beispiel anzeigen
Nach der Installation des Operators wählen Sie View operator und erstellen eine Instanz des Trident Orchestrator.

Wenn Sie Worker-Knoten für iSCSI vorbereiten möchten, wechseln Sie zur YAML-Ansicht und fügen Sie iscsi zu nodePrep hinzu.

Beispiel anzeigen
Vergewissern Sie sich, dass alle Trident Pods im Cluster ausgeführt werden.

Beispiel anzeigen
Wenn Sie die iSCSI-Knotenvorbereitung aktiviert haben, melden Sie sich an den Worker-Knoten an und überprüfen Sie, ob iscsid und multipathd aktiv sind und dass multipath.conf Einträge enthält.

Beispiel anzeigen

Beispiel anzeigen

Beispiel anzeigen

Videodemonstration

Das folgende Video zeigt eine Demonstration der Installation von Trident mit dem Red Hat Certified Trident Operator.

Installieren von Trident 25.02.1 mit dem zertifizierten Trident Operator in OpenShift

Schritt 2: Bereiten Sie das Speicher-Backend und StorageClass Konfigurationsdateien für Ihre Umgebung vor

Erstellen Sie TridentBackendConfig und StorageClass Definitionen für Ihre Umgebung. Sie können mehrere Speicherprotokolle innerhalb Ihrer Umgebung konfigurieren. Erstellen Sie YAML-Dateien für jedes Protokoll, das Sie verwenden möchten, und ersetzen Sie die Platzhalterwerte durch Ihre spezifischen Konfigurationsdetails.

Füllen Sie je nach Ihrer Umgebung entweder den Abschnitt „On-Premises“ oder „ROSA“ unten aus und fahren Sie dann mit Schritt 3 fort.

Lokale OpenShift Cluster

Erstellen Sie YAML-Dateien für jedes Protokoll, das Sie konfigurieren möchten. Sie können eines oder mehrere der folgenden Protokolle konfigurieren: NAS für NFS-basierte Dateispeicherung, iSCSI für iSCSI-Blockspeicherung, NVMe/TCP für leistungsstarke NVMe über TCP-Blockspeicherung oder FC für Fibre Channel-Blockspeicherung.

Erstellen Sie eine TridentBackendConfig und eine StorageClass für jedes Protokoll. Die Backend-Konfiguration umfasst Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind.

Wesentliche Richtlinien für grundlegende Optionen der Backend-Konfiguration

Die Backend-Konfigurationsdateien verweisen auf Ihre ONTAP SVM und Management LIF. +
Sie können sich mit Benutzername und Passwort bei ONTAP authentifizieren. Es kann sich um den Benutzernamen und das Passwort des Cluster-Administrators oder des vServer-Administrators handeln. +
Sie können auch ein Clientzertifikat zur Authentifizierung mit ONTAP verwenden. Einzelheiten dazu, wie das Clientzertifikat, der private Schlüssel und das CA-Zertifikat generiert werden, finden sich unter "Trident Dokumentation hier".

Wesentliche Richtlinien für Backend-Konfigurationsoptionen für den NAS Economy-Treiber

Für die Konfiguration des NAS economy driver können die folgenden Parameter einbezogen werden:

qtreesPerFlexvol Der Wert muss im Bereich von 50 bis 300 liegen, der Standardwert ist 200. +
limitVolumePoolSize Der Wert ist die maximale FlexVol-Größe, die bei der Verwendung von Qtrees im ontap-nas-economy Backend angefordert wird. Es ist kein Standardwert festgelegt, und dieser Parameter wird standardmäßig nicht erzwungen. Wenn dieser Parameter gesetzt ist, erstellt der Trident Operator einen neuen FlexVol, sobald der aktuelle FlexVol die angegebene Größe erreicht. Dieser Parameter kann dabei helfen, die Kapazitätsauslastung im Cluster zu steuern, indem die Größe der für die Bereitstellung von PVs verwendeten FlexVols beschränkt wird. +
denyNewVolumePools Dieser Parameter verhindert, dass ontap-nas-economy Backends neue FlexVol Volumes zur Aufnahme ihrer Qtrees erstellen. Für die Bereitstellung neuer PVs werden ausschließlich bereits vorhandene FlexVols verwendet.

Wesentliche Richtlinien für Backend-Konfigurationsoptionen für den SAN Treiber

Die folgenden Parameter können für die SAN Treiber-Konfiguration einbezogen werden:

limitVolumeSize Der Wert ist die maximale Volume-Größe, die bei Verwendung eines SAN-Backends angefordert wird. Es ist kein Standardwert festgelegt, und dieser Parameter wird standardmäßig nicht erzwungen. Wenn dieser Parameter festgelegt ist, schlägt die Bereitstellung durch den Trident Operator fehl, wenn die angeforderte Volume-Größe diesen Wert überschreitet. Mit diesem Parameter lässt sich die maximale Größe der von ihm für LUNs verwalteten Volumes beschränken. +
lunsPerFlexvol Maximale Anzahl an LUNs pro FlexVol, muss im Bereich [50, 200] liegen, der Standardwert ist 100. Wenn Sie diesen Parameter festlegen, erstellt der Trident Operator ein neues FlexVol, wenn das aktuelle FlexVol die angegebene Anzahl an LUNs erreicht. Dieser Parameter kann Ihnen dabei helfen, die Kapazitätsauslastung in Ihrem Cluster zu steuern, indem die Anzahl der LUNs pro FlexVol, die für die Bereitstellung von PVs verwendet werden, begrenzt wird.

Wesentliche Richtlinien für Backend-Konfigurationsoptionen für den SAN Economy-Treiber

Die folgenden Parameter können für die Konfiguration des SAN economy driver einbezogen werden:

limitVolumePoolSize Der Wert ist die maximale FlexVol-Größe, die bei Verwendung des SAN economy Backends angefordert wird. Es ist kein Standardwert festgelegt, und dieser Parameter wird standardmäßig nicht erzwungen. Wenn dieser Parameter festgelegt ist, begrenzt der Trident Operator die maximale FlexVol-Größe, die für die Erstellung von LUNs im FlexVol erstellt werden kann. Dieser Parameter kann dazu beitragen, die Kapazitätsauslastung im Cluster zu steuern, indem die Größe der für die Bereitstellung von PVs verwendeten FlexVols eingeschränkt wird. +
denyNewVolumePools Dieser Parameter verhindert, dass SAN Economy Backends neue FlexVol Volumes zur Aufnahme ihrer LUNs erstellen. Für die Bereitstellung neuer PVs werden ausschließlich bereits vorhandene FlexVols verwendet.

Wesentliche Richtlinien für Backend-Konfigurationsoptionen zur Bereitstellung von Volumes

In den für jedes Protokoll bereitgestellten YAML-Beispieldateien wird, falls storagePrefix nicht angegeben ist, das Standardpräfix „trident“ verwendet. Bei Verwendung von ontap-nas-economy und einem storagePrefix von 24 oder mehr Zeichen wird das Speicherpräfix nicht in die Qtrees eingebettet, ist aber im Volume-Namen enthalten.

Wenn in ONTAP direkt über den System Manager oder über die CLI ein Volume erstellt wird, ohne Werte für alle optionalen Parameter anzugeben, werden während der Bereitstellung eines Volumes automatisch einige Standardwerte festgelegt, wie unten dargestellt.

Volume in ONTAP erstellen

Standardwerte für Volumenparameter

Hier ist ein Beispiel für ein Volume, das mit der Trident Backend-Konfiguration erstellt wurde. Im Abschnitt „Standardeinstellungen“ sind außer der Namensvorlage keine Optionen explizit festgelegt.

oc describe tbc -n trident tbc-nas
### output truncated for brevity
Spec:
  Backend Name:  tbc-nas
  Credentials:
    Name:  tbc-nas-secret
  Defaults: # There are no defaults set except for the volume name template.
    Name Template:      {{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}
  Management LIF:       10.192.102.50
  Storage Driver Name:  ontap-nas
  Storage Prefix:       testautomation
  Svm:                  oc-test-automation

Wenn das Volume mit dieser Backend-Konfiguration erstellt wird, werden die Optionen, die nicht in der Backend-Konfigurationsdatei festgelegt sind, auf die unten dargestellten Standardwerte gesetzt.

Volume erstellt mit Trident Backend Konfiguration

Wenn Sie jedoch im Standardabschnitt der Trident-Backend-Konfiguration Werte festlegen, können Volumes erstellt werden, die spezifische Werte für diese Parameter aufweisen. Im folgenden Beispiel ist snapshotPolicy auf die Standardrichtlinie gesetzt (sie ist none, wenn nichts explizit festgelegt wird), und snapshotDir ist im Standardabschnitt der Backend-Konfigurations-YAML auf true gesetzt. Mit diesen Einstellungen erhält das Backend-Volume diese Werte. (snapdir-access ist true und snapshot-policy ist default)

Standardabschnitt mit expliziten Werten

explizit festgelegte snapshotDir und snapshotPolicy Werte in der Backend-Konfiguration

explizit snapshotDir- und snapshotPolicy-Werte im Volume festlegen

Alle weiteren Parameter sind in der Trident Dokumentation aufgeführt:

NAS

Erstellen Sie eine TridentBackendConfig und StorageClass für ONTAP NAS, um die Bereitstellung von persistentem Speicher auf NFS-Basis zu ermöglichen. Die Backend-Konfiguration enthält Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind, und verweist auf Ihre ONTAP SVM und Management-LIF.

Beispiel für ein Backend-Geheimnis und eine Backend Konfigurationsdatei mit Authentifizierung über Benutzername und Passwort (speichern als tbc-nas.yaml):

# 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: <ONTAP management LIF>
  backendName: tbc-nas
  svm: zoneb #<replace with your SVM name>
  storagePrefix: testzoneb #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-nas-secret

Beispiel für ein Backend-Geheimnis und eine Backend Konfigurationsdatei mit Clientzertifikat-Authentifizierung (speichern unter tbc-nas.yaml):

# tbc-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: ontap-nas-secret
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas
  svm: zoneb #<replace with your SVM name>
  storagePrefix: testzoneb #<replace with your prefix>
  credentials:
    name: ontap-nas-secret
  clientCertificate: <client certificate>

StorageClass definition (speichern als sc-nas.yaml):

# 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

NAS Economy

Erstellung einer TridentBackendConfig und StorageClass für den ONTAP NAS economy Treiber, um die NFS-basierte Bereitstellung von persistentem Speicher mithilfe von Qtrees zu ermöglichen. Die Backend-Konfiguration enthält Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind, und verweist auf Ihre ONTAP SVM und Management-LIF.

Beispiel für ein Backend-Geheimnis und eine Backend Konfigurationsdatei mit Authentifizierung über Benutzername und Passwort (speichern als tbc-nas-economy.yaml):

# tbc-nas-economy.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-nas-economy-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas-economy
spec:
  version: 1
  storageDriverName: ontap-nas-economy
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas-eco
  svm: <replace with your SVM name>
  storagePrefix: <replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-nas-economy-secret

StorageClass-Definition (speichern als sc-nas-economy.yaml):

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

Einzelheiten zu zusätzlichen Parametern, die in die Backend Konfigurationsdatei für den ontap-nas-economy Treiber aufgenommen werden können, sind im obigen Abschnitt „Wichtige Richtlinien für Backend Konfigurationsoptionen für den NAS economy Treiber“ zu finden.

iSCSI SAN

Eine TridentBackendConfig und StorageClass für ONTAP SAN mit iSCSI ermöglichen die Bereitstellung von iSCSI-basiertem Blockspeicher. Die Backend-Konfiguration verwendet den ontap-san Treiber und enthält Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind. Der sanType Parameter verwendet standardmäßig das iSCSI-Protokoll, wenn er weggelassen wird.

Backend-Geheimnis und Backend Konfigurationsdatei mit Benutzername-Passwort-Authentifizierung (speichern als tbc-iscsi.yaml):

# 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

Backend-Geheimnis und Backend Konfigurationsdatei mit Clientzertifikats-Authentifizierung (speichern als tbc-iscsi.yaml):

# tbc-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-iscsi-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
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
  clientCertificate: <client certificate>

StorageClass-Definition (speichern als sc-iscsi.yaml):

# 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

NVMe/TCP SAN

Erstellen Sie eine TridentBackendConfig und StorageClass für ONTAP SAN mit NVMe über TCP, um die Bereitstellung von Blockspeicher mit hoher Leistung zu ermöglichen. Die Backend-Konfiguration verwendet den für NVMe/TCP-Transport optimierten ontap-san-Treiber und enthält Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind.

Backend-Geheimnis und Backend Konfigurationsdatei mit Benutzername-Passwort-Authentifizierung (speichern als tbc-nvme.yaml):

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

Backend-Geheimnis und Backend Konfigurationsdatei mit Clientzertifikats-Authentifizierung (speichern als tbc-nvme.yaml):

# tbc-nvme.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-nvme-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nvme
spec:
  version: 1
  storageDriverName: ontap-san
  sanType: nvme
  managementLIF: <ONTAP management LIF>
  backendName: backend-tbc-ontap-nvme
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-nvme-secret
  clientCertificate: <client certificate>

StorageClass-Definition (speichern als sc-nvme.yaml):

# 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

Wenn Sie planen, ReadWriteMany (RWX)-Volumes mit dem NVMe-Protokoll zu verwenden, kann ein einzelnes RWX-NVMe-Volume von nicht mehr als 64 Knoten in einem Kubernetes-Cluster eingebunden werden. Weitere Informationen zu dieser Einschränkung sowie Informationen zum in Trident 26.02 eingeführten Super-Subsystem-Modell und zum Per-Volume-Subsystem-Modell vor Trident 26.02 enthält die Trident Dokumentation: https://docs.netapp.com/us-en/trident/trident-use/ontap-san-prep.html#nvme-tcp-considerations.

FC SAN

Erstellen Sie eine TridentBackendConfig und StorageClass für ONTAP SAN mit Fibre Channel, um die FC-basierte Blockspeicherbereitstellung zu ermöglichen. Die Backend-Konfiguration verwendet den ontap-san-Treiber mit dem angegebenen FCP-Protokoll und enthält Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind.

Das Authentifizierungsverfahren mit Benutzername/Passwort oder das Authentifizierungsverfahren mit Clientzertifikat kann zur Authentifizierung bei ONTAP verwendet werden. Einzelheiten zur Generierung des Clientzertifikats, des privaten Schlüssels und des CA-Zertifikats finden sich unter "Trident Dokumentation hier". Beispiele für beide Verfahren sind unten aufgeführt.

Beispiel anzeigen

Backend-Geheimnis und Backend Konfigurationsdatei mit ONTAP Benutzernamen- und Passwortauthentifizierung (speichern unter tbc-fc.yaml):

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

Backend-Geheimnis und Backend Konfigurationsdatei mit Clientzertifikats-Authentifizierung (speichern als tbc-fc.yaml):

# tbc-fc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-fc-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-fc
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <ONTAP management LIF>
  backendName: tbc-fc
  svm: openshift-fc #<replace with your SVM name>
  sanType: fcp
  storagePrefix: demofc #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-fc-secret
  clientCertificate: <client certificate>

# 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

iSCSI SAN Ökonomie

Eine TridentBackendConfig und StorageClass für ONTAP SAN Economy mit iSCSI ermöglichen die Bereitstellung von iSCSI-basiertem Blockspeicher. Die Backend-Konfiguration verwendet den ontap-san-economy Treiber mit dem iSCSI-Protokoll und enthält Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind.

Backend-Geheimnis und Backend Konfigurationsdatei mit Clientzertifikats-Authentifizierung (speichern als tbc-san-eco.yaml):

# tbc-san-eco.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: ontap-san-cert-auth
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-san-eco-cert
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san-economy
  managementLIF: "<ONTAP management LIF>"
  backendName: tbc_san_eco
  svm: <replace with your SVM name>
  storagePrefix: <replace with your prefix>
  credentials:
    name: ontap-san-cert-auth
  clientCertificate: <client certificate>

# sc-san-eco.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-san-eco
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san-economy"
  provisioningType: "thin"
  snapshots: "true"

In der Trident-Dokumentation finden sich weitere Beispiele für YAML-Dateien sowie Informationen zu den von SAN-Treibern und NAS-Treibern unterstützten Zugriffsmodi und Volumenmodi.

ROSA clusters mit Amazon FSx for NetApp ONTAP

Erstellen Sie YAML-Dateien für jedes Protokoll, das Sie konfigurieren möchten. Sie können eines oder beide der folgenden Protokolle konfigurieren: NAS für NFS-basierte Dateispeicherung oder iSCSI für Blockspeicherung.

NAS

Erstellen Sie eine TridentBackendConfig und StorageClass für Amazon FSx for NetApp ONTAP mit ONTAP NAS, um die Bereitstellung von NFS-basiertem persistentem Speicher auf ROSA-Clustern zu ermöglichen. Die Backend-Konfiguration verwendet Amazon FSx for NetApp ONTAP DNS-Namen für Management- und Daten-LIFs und enthält Anmeldeinformationen, die in einem Kubernetes Secret im trident Namespace gespeichert sind.

Backend-Geheimnis und Backend-Konfigurationsdatei (speichern als tbc-fsx-nas.yaml):

# tbc-fsx-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-fsx-ontap-nas-secret
type: Opaque
stringData:
  username: <FSx for ONTAP, for example fsxadmin>
  password: <FSx for ONTAP password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-fsx-ontap-nas
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

StorageClass-Definition (speichern als sc-fsx-nas.yaml):

# sc-fsx-nas.yaml (storage class name is trident-csi)
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

iSCSI

Erstellen Sie eine TridentBackendConfig und StorageClass für Amazon FSx for NetApp ONTAP mit ONTAP SAN, um die iSCSI-basierte Blockspeicher-Bereitstellung auf ROSA-Clustern zu ermöglichen. Die Backend-Konfiguration verwendet den ontap-san-Treiber und enthält Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind. Stellen Sie sicher, dass die Worker-Knoten für iSCSI-Zugriff vorbereitet sind.

Backend-Geheimnis und Backend-Konfigurationsdatei (speichern als tbc-fsx-iscsi.yaml):

# tbc-fsx-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-fsx-iscsi-secret
type: Opaque
stringData:
  username: <FSx for ONTAP, for example fsxadmin>
  password: <FSx for ONTAP password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: fsx-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <Management DNS name>
  backendName: fsx-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-fsx-iscsi-secret

StorageClass-Definition (speichern als sc-fsx-iscsi.yaml):

# 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

Schritt 3: Erstellen Sie eine VolumeSnapshotClass Konfigurationsdatei

Erstellen Sie eine VolumeSnapshotClass-Definition für lokale und ROSA-Bereitstellungen. Diese Konfiguration ermöglicht Snapshot-basierte Operationen für persistente Volumes.

VolumeSnapshotClass-Definition (speichern als snapshot-class.yaml):

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

Schritt 4: Wenden Sie die Konfigurationsdateien auf Ihren Cluster an

Wenden Sie die in den vorherigen Schritten erstellten Konfigurationsdateien auf Ihren OpenShift-Cluster an.

Schritte

Wenden Sie die TridentBackendConfig und StorageClass Dateien für jedes von Ihnen konfigurierte Protokoll an.

Für lokale Cluster:

oc create -f tbc-nas.yaml -n trident
oc create -f sc-nas.yaml

oc create -f tbc-nas-economy.yaml -n trident
oc create -f sc-nas-economy.yaml

oc create -f tbc-iscsi.yaml -n trident
oc create -f sc-iscsi.yaml

oc create -f tbc-nvme.yaml -n trident
oc create -f sc-nvme.yaml

oc create -f tbc-fc.yaml -n trident
oc create -f sc-fc.yaml

Für ROSA-Cluster:

oc create -f tbc-fsx-nas.yaml -n trident
oc create -f sc-fsx-nas.yaml

oc create -f tbc-fsx-iscsi.yaml -n trident
oc create -f sc-fsx-iscsi.yaml

Wenden Sie die VolumeSnapshotClass-Konfiguration an.
```
oc create -f snapshot-class.yaml
```
Überprüfen Sie, ob die Ressourcen erfolgreich erstellt wurden.

Prüfen Sie TridentBackendConfig-Objekte:
```
oc get tbc -n trident
```
Prüfen Sie StorageClass-Objekte:
```
oc get storageclass
```
Überprüfen Sie VolumeSnapshotClass:
```
oc get volumesnapshotclass
```

Schritt 5: Legen Sie die standardmäßigen Trident Storage- und Snapshot-Klassen fest

Legen Sie die Trident StorageClass und VolumeSnapshotClass als Standardwerte im OpenShift-Cluster fest. Dies ist erforderlich, damit OpenShift Virtualization Golden-Image-Quellen für VM-Vorlagen erstellen kann.

Schritte

Legen Sie die Standard-Trident-StorageClass fest.

Legen Sie eine von Trident unterstützte StorageClass als Standard für den Cluster fest, damit PersistentVolumeClaims diese automatisch verwenden, wenn keine Speicherklasse angegeben ist. Sie müssen zwei Annotationen konfigurieren: eine für den clusterweiten Standard und eine speziell für die OpenShift Virtualisierung.
1. Legen Sie die clusterweite Standard-StorageClass-Annotation fest.
  
  Stellen Sie sicher, dass nur eine StorageClass als Standard festgelegt ist. Wenn eine andere StorageClass bereits als Standard festgelegt ist, setzen Sie deren Annotation auf false.
  
  Bearbeiten Sie die Annotation in der Konsole:
  storageclass.kubernetes.io/is-default-class: "true"
  Über die CLI:
  kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
2. Legen Sie die OpenShift-Virtualisierung-spezifische Standardannotation fest.
  
  OpenShift Virtualisierung verwendet eine spezifische Annotation, die Vorrang vor der allgemeinen is-default-class Annotation des Clusters hat. Wenn eine andere StorageClass bereits als Standard festgelegt ist, setzen Sie deren Annotation auf false.
  
  Bearbeiten Sie die Annotation in der Konsole:
  storageclass.kubevirt.io/is-default-virt-class: "true"
  Über die CLI:
```
kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'
```
Legen Sie die Standard-Trident-VolumeSnapshotClass fest.

Legen Sie eine von Trident unterstützte VolumeSnapshotClass als Standard für den Cluster fest, um Snapshot-basierte Operationen für persistente Volumes zu ermöglichen. Dadurch wird sichergestellt, dass VolumeSnapshots automatisch den Trident CSI-Treiber verwenden, wenn keine Snapshot-Klasse angegeben ist, und OpenShift Virtualization Snapshots von Golden Images erstellen kann.

Stellen Sie sicher, dass nur eine VolumeSnapshotClass als Standard festgelegt ist. Wenn eine andere VolumeSnapshotClass bereits als Standard festgelegt ist, setzen Sie deren Annotation auf false.

Bearbeiten Sie die Annotation in der Konsole:
```
snapshot.storage.kubernetes.io/is-default-class: "true"
```
Über die CLI:
```
oc patch volumesnapshotclass <snapshot class name> --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'
```

Installieren Sie Trident auf einem Red Hat OpenShift Cluster und erstellen Sie Speicherobjekte

Creating your file...

Schritt 1: Trident installieren

Schritt 2: Bereiten Sie das Speicher-Backend und StorageClass Konfigurationsdateien für Ihre Umgebung vor

Lokale OpenShift Cluster

ROSA clusters mit Amazon FSx for NetApp ONTAP

Schritt 3: Erstellen Sie eine VolumeSnapshotClass Konfigurationsdatei

Schritt 4: Wenden Sie die Konfigurationsdateien auf Ihren Cluster an

Schritt 5: Legen Sie die standardmäßigen Trident Storage- und Snapshot-Klassen fest