Skip to main content
NetApp virtualization solutions
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Installez Trident sur un cluster OpenShift Red Hat et créez des objets de stockage

Contributeurs banum-netapp netapp-jsnyder kevin-hoke
PDF

Installez Trident avec l'opérateur Trident certifié Red Hat et créez des objets de stockage pour ONTAP et Amazon FSx for NetApp ONTAP afin d'activer le provisionnement dynamique de volumes pour les conteneurs et les machines virtuelles. Préparez les nœuds de travail pour l'accès bloc si nécessaire.

Avant de commencer

  • Effectuez les procédures de cette page avant d’installer OpenShift Virtualization. OpenShift Virtualization nécessite un StorageClass et un VolumeSnapshotClass par défaut pris en charge par Trident pour créer des images de référence pour les modèles de machines virtuelles.

  • Si vous avez déjà installé OpenShift Virtualization avant de configurer Trident, supprimez toutes les images de référence créées avec une autre classe de stockage. Après avoir défini Trident comme stockage par défaut, OpenShift Virtualization recrée les images de référence en utilisant le stockage Trident.

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

Étape 1 : Installer Trident

L'opérateur Trident certifié Red Hat est pris en charge par NetApp pour OpenShift sur site, dans les clouds publics et dans les services gérés tels que ROSA. À partir de Trident 25.02, l'opérateur peut également préparer les nœuds de travail pour iSCSI lorsque vous utilisez Amazon FSx for NetApp ONTAP et prévoyez d'exécuter des charges de travail de machines virtuelles OpenShift Virtualization.

Pour d'autres options d'installation, voir "la documentation Trident".

Étapes

  1. Dans OperatorHub, sélectionnez Certified NetApp Trident.

    Afficher un exemple

    centre d'opérateurs

  2. Sur la page Install, conservez la dernière version et sélectionnez Install.

    Afficher un exemple

    installer

  3. Après l'installation de l'opérateur, sélectionnez View operator et créez une instance de Trident Orchestrator.

    Si vous souhaitez préparer les nœuds de travail pour iSCSI, passez à la vue YAML et ajoutez iscsi à nodePrep.

    Afficher un exemple

    ajouter iscsi pour la préparation des nœuds

  4. Confirmez que tous les pods Trident sont en cours d'exécution dans le cluster.

    Afficher un exemple

    Trident installé

  5. Si vous avez activé la préparation des nœuds iSCSI, connectez-vous aux nœuds de travail et vérifiez que iscsid et multipathd sont actifs et que multipath.conf contient des entrées.

    Afficher un exemple

    iscsid en cours d'exécution

    Afficher un exemple

    multipathd en cours d'exécution

    Afficher un exemple

    fichier multipath.conf en cours d'exécution

Démonstration vidéo

La vidéo suivante présente une démonstration de l'installation de Trident à l'aide de l'opérateur Trident certifié Red Hat.

Installation de Trident 25.02.1 à l'aide de l'opérateur Trident certifié dans OpenShift

Étape 2 : Préparez le système de stockage et les fichiers de configuration StorageClass pour votre environnement

Créez des définitions TridentBackendConfig et StorageClass pour votre environnement. Vous pouvez configurer plusieurs protocoles de stockage dans votre environnement. Créez des fichiers YAML pour chaque protocole que vous souhaitez utiliser et remplacez les valeurs de remplacement par les détails spécifiques de votre configuration.

Remarque Remplissez soit la section sur site, soit la section ROSA ci-dessous en fonction de votre environnement, puis passez à l'étape 3.

Clusters OpenShift sur site

Créez des fichiers YAML pour chaque protocole que vous souhaitez configurer. Vous pouvez configurer un ou plusieurs des protocoles suivants : NAS pour le stockage de fichiers basé sur NFS, iSCSI pour le stockage bloc iSCSI, NVMe/TCP pour le stockage bloc NVMe over TCP haute performance, ou FC pour le stockage bloc Fibre Channel.

NAS

Créez un TridentBackendConfig et un StorageClass pour ONTAP NAS afin d'activer le provisionnement de stockage persistant basé sur NFS. La configuration du backend inclut des informations d'identification stockées dans un secret Kubernetes et fait référence à votre ONTAP SVM et à votre LIF de gestion.

Secret backend et fichier de configuration backend (à enregistrer sous 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 (enregistrer sous 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

Créez un TridentBackendConfig et un StorageClass pour ONTAP SAN afin d'activer le provisionnement du stockage bloc basé sur iSCSI. La configuration du backend utilise le pilote ontap-san et inclut des informations d'identification stockées dans un Secret Kubernetes.

Secret backend et fichier de configuration backend (à enregistrer sous 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 (enregistrer sous 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

Créez un TridentBackendConfig et un StorageClass pour ONTAP SAN avec NVMe sur TCP afin d'activer le provisionnement de stockage bloc haute performance. La configuration du backend utilise le pilote ontap-san optimisé pour le transport NVMe/TCP et inclut des informations d'identification stockées dans un Secret Kubernetes.

Secret backend et fichier de configuration backend (à enregistrer sous 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 (enregistrer sous 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

Créez un TridentBackendConfig et un StorageClass pour ONTAP SAN avec Fibre Channel afin d'activer le provisionnement du stockage bloc basé sur FC. La configuration du backend utilise le pilote ontap-san avec le protocole FCP spécifié et inclut des informations d'identification stockées dans un Secret Kubernetes.

Secret backend et fichier de configuration backend (à enregistrer sous 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 (enregistrer sous 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

Clusters ROSA avec Amazon FSx for NetApp ONTAP

Créez des fichiers YAML pour chaque protocole que vous souhaitez configurer. Vous pouvez configurer un ou les deux protocoles suivants : NAS pour le stockage de fichiers basé sur NFS ou iSCSI pour le stockage bloc.

NAS

Créez une TridentBackendConfig et une StorageClass pour Amazon FSx for NetApp ONTAP avec ONTAP NAS afin d'activer le provisionnement de stockage persistant basé sur NFS sur les clusters ROSA. La configuration backend utilise les noms DNS d'Amazon FSx for NetApp ONTAP pour les LIF de gestion et de données, et inclut des informations d'identification stockées dans un Secret Kubernetes dans l'espace de noms trident.

Secret backend et fichier de configuration backend (à enregistrer sous 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 (enregistrer sous 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

Créez un TridentBackendConfig et un StorageClass pour Amazon FSx for NetApp ONTAP avec ONTAP SAN afin d'activer le provisionnement de stockage bloc basé sur iSCSI sur les clusters ROSA. La configuration du backend utilise le pilote ontap-san et inclut des informations d'identification stockées dans un Secret Kubernetes. Assurez-vous que les nœuds de travail sont préparés pour l'accès iSCSI.

Secret backend et fichier de configuration backend (à enregistrer sous 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 (enregistrer sous 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

Étape 3 : Créez un fichier de configuration VolumeSnapshotClass

Créez une définition VolumeSnapshotClass pour les déploiements sur site et ROSA. Cette configuration active les opérations basées sur les instantanés pour les volumes persistants.

VolumeSnapshotClass definition (enregistrer sous 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

Étape 4 : Appliquez les fichiers de configuration à votre cluster

Appliquez les fichiers de configuration que vous avez créés lors des étapes précédentes à votre OpenShift cluster.

Étapes

  1. Appliquez les fichiers TridentBackendConfig et StorageClass pour chaque protocole que vous avez configuré.

    Pour les clusters sur site :

    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

    Pour les clusters ROSA :

    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. Appliquez la configuration VolumeSnapshotClass.

    oc create -f snapshot-class.yaml

  3. Vérifiez que les ressources ont été créées avec succès.

    Vérifiez les objets TridentBackendConfig :

    oc get tbc -n trident

    Vérifiez les objets StorageClass :

    oc get storageclass

    Vérifiez VolumeSnapshotClass :

    oc get volumesnapshotclass

Étape 5 : Définir les classes de stockage et d’instantanés Trident par défaut

Définissez la StorageClass Trident et la VolumeSnapshotClass Trident comme valeurs par défaut dans le cluster OpenShift. Ceci est nécessaire pour que la virtualisation OpenShift puisse créer des sources d’images de référence pour les modèles de machines virtuelles.

Étapes

  1. Définissez le Trident StorageClass par défaut.

    Définissez un StorageClass pris en charge par Trident comme valeur par défaut du cluster afin que les PersistentVolumeClaims l'utilisent automatiquement lorsqu'aucune classe de stockage n'est spécifiée. Vous devez configurer deux annotations : une pour la valeur par défaut du cluster et une spécifique à la virtualisation OpenShift.

    1. Définissez l'annotation StorageClass par défaut à l'échelle du cluster.

      Assurez-vous qu'une seule StorageClass est définie par défaut. Si une autre StorageClass est déjà définie par défaut, définissez son annotation sur false.

      Dans la console, modifiez l'annotation :

      storageclass.kubernetes.io/is-default-class: "true"

      Depuis l'interface de ligne de commande :

      kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

    2. Définissez l’annotation par défaut spécifique à la virtualisation OpenShift.

      OpenShift Virtualization utilise une annotation spécifique qui prime sur l' `is-default-class`annotation générale du cluster. Si une autre StorageClass est déjà définie par défaut, définissez son annotation sur false.

      Dans la console, modifiez l'annotation :

      storageclass.kubevirt.io/is-default-virt-class: "true"

      Depuis l'interface de ligne de commande :

    kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'

  2. Définissez la VolumeSnapshotClass Trident par défaut.

    Définissez un VolumeSnapshotClass pris en charge par Trident comme valeur par défaut du cluster pour activer les opérations basées sur les instantanés pour les volumes persistants. Cela garantit que les VolumeSnapshots utilisent automatiquement le pilote CSI Trident lorsqu'aucune classe d'instantané n'est spécifiée et permet à la virtualisation OpenShift de créer des instantanés d'images de référence.

    Assurez-vous qu'une seule VolumeSnapshotClass est définie par défaut. Si une autre VolumeSnapshotClass est déjà définie par défaut, définissez son annotation sur false.

    Dans la console, modifiez l'annotation :

    snapshot.storage.kubernetes.io/is-default-class: "true"

    Depuis l'interface de ligne de commande :

    oc patch volumesnapshotclass <snapshot class name> --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'