Skip to main content
NetApp virtualization solutions
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

Beitragende banum-netapp netapp-jsnyder kevin-hoke
Änderungen vorschlagen
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

  1. In OperatorHub wählen Sie Certified NetApp Trident.

    Beispiel anzeigen

    Betreiber-Hub

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

    Beispiel anzeigen

    installieren

  3. 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

    iscsi für die Knotenvorbereitung hinzufügen

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

    Beispiel anzeigen

    Trident installiert

  5. 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

    iscsid läuft

    Beispiel anzeigen

    Multipathd läuft

    Beispiel anzeigen

    multipath.conf file wird ausgeführt

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.

Hinweis 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.

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.

Backend-Geheimnis und Backend-Konfigurationsdatei (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

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
iSCSI

Erstellen Sie eine TridentBackendConfig und StorageClass für ONTAP SAN, um die Bereitstellung von iSCSI-basiertem Blockspeicher zu ermöglichen. Die Backend-Konfiguration verwendet den ontap-san-Treiber und enthält Anmeldeinformationen, die in einem Kubernetes Secret gespeichert sind.

Backend-Geheimnis und Backend-Konfigurationsdatei (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

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

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 (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

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
FC

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.

Backend-Geheimnis und Backend-Konfigurationsdatei (speichern als 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

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

# 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

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

  1. 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-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

  2. Wenden Sie die VolumeSnapshotClass-Konfiguration an.

    oc create -f snapshot-class.yaml

  3. Ü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

  1. 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"}}}'

  2. 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"}}}'