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.

Créez un TridentBackendConfig et un StorageClass pour chaque protocole. La configuration du backend inclut des informations d'identification stockées dans un Secret Kubernetes.

Directives essentielles pour les options de configuration de base du backend

  1. Les fichiers de configuration du backend font référence à votre ONTAP SVM et à votre LIF de gestion. +

  2. Vous pouvez utiliser un nom d'utilisateur et un mot de passe pour vous authentifier auprès d'ONTAP. Il peut s'agir du nom d'utilisateur et du mot de passe d'administrateur de cluster ou d'administrateur de vserver. +

  3. Vous pouvez également utiliser un certificat client pour l'authentification avec ONTAP. Pour plus de détails sur la génération du certificat client, de la clé privée et du certificat d'autorité de certification, veuillez consulter "Documentation Trident ici".

Directives essentielles pour les options de configuration du backend pour le pilote NAS economy

Les paramètres suivants peuvent être inclus pour la configuration du NAS economy driver :

  1. qtreesPerFlexvol La valeur doit être comprise entre 50 et 300, la valeur par défaut est 200. +

  2. limitVolumePoolSize La valeur correspond à la taille maximale de FlexVol que vous demandez lors de l'utilisation de qtrees dans le backend ontap-nas-economy. Aucune valeur par défaut n'est définie et ce paramètre n'est pas appliqué par défaut. Si vous définissez ce paramètre, l'opérateur Trident crée un nouveau FlexVol lorsque le FlexVol actuel atteint la taille spécifiée. Ce paramètre peut vous aider à contrôler l'utilisation de la capacité de votre cluster en limitant la taille des FlexVols utilisés pour le provisionnement des PV. +

  3. denyNewVolumePools Ce paramètre empêche les backends ontap-nas-economy de créer de nouveaux volumes FlexVol® pour contenir leurs qtrees. Seuls les FlexVol® préexistants sont utilisés pour le provisionnement de nouveaux PV.

Directives essentielles pour les options de configuration du backend pour le pilote SAN

Les paramètres suivants peuvent être inclus pour la configuration du pilote SAN :

  1. limitVolumeSize Cette valeur correspond à la taille maximale de volume que vous demandez lors de l'utilisation d'un backend SAN. Aucune valeur par défaut n'est définie et ce paramètre n'est pas appliqué par défaut. Si vous définissez ce paramètre, l'opérateur Trident échouera lors du provisionnement si la taille de volume demandée dépasse cette valeur. Vous pouvez utiliser ce paramètre pour restreindre la taille maximale des volumes qu'il gère pour les LUN. +

  2. lunsPerFlexvol Nombre maximal de LUN par FlexVol®, doit être compris entre 50 et 200, la valeur par défaut étant 100. Si vous définissez ce paramètre, l’opérateur Trident crée un nouveau FlexVol lorsque le FlexVol actuel atteint le nombre de LUN spécifié. Ce paramètre peut vous aider à contrôler l’utilisation de la capacité de votre cluster en limitant le nombre de LUN par FlexVol utilisé pour le provisionnement des PV.

Recommandations essentielles pour les options de configuration du backend pour le pilote SAN economy

Les paramètres suivants peuvent être inclus pour la configuration du SAN economy driver :

  1. limitVolumePoolSize La valeur correspond à la taille maximale de FlexVol® que vous demandez lors de l'utilisation du backend SAN economy. Aucune valeur par défaut n'est définie et ce paramètre n'est pas appliqué par défaut. Si vous définissez ce paramètre, l'opérateur Trident limite la taille maximale de FlexVol® qui peut être créée pour la création de LUN dans le FlexVol®. Ce paramètre peut vous aider à contrôler l'utilisation de la capacité dans votre cluster en limitant la taille des FlexVol® utilisés pour le provisionnement de PV. +

  2. denyNewVolumePools Ce paramètre empêche les back-ends SAN economy de créer de nouveaux volumes FlexVol® pour contenir leurs LUN. Seuls les FlexVol® préexistants sont utilisés pour le provisionnement de nouveaux PV.

Directives essentielles concernant les options de configuration du backend pour le provisionnement des volumes
Remarque Dans les exemples de fichiers YAML fournis pour chaque protocole, si storagePrefix n'est pas spécifié, le préfixe par défaut « trident » est utilisé. Lorsque vous utilisez ontap-nas-economy et un storagePrefix de 24 caractères ou plus, les qtrees n'incluent pas le préfixe de stockage, bien qu'il figure dans le nom du volume.

Lorsque vous créez un volume dans ONTAP directement depuis le gestionnaire système ou depuis l'interface de ligne de commande (CLI), sans fournir de valeurs pour tous les paramètres optionnels, certaines valeurs par défaut sont définies automatiquement lors de la mise en service d'un volume, comme indiqué ci-dessous.

Créer un volume dans ONTAP

valeurs par défaut pour les paramètres de volume

Voici un exemple de volume créé à l'aide de la configuration du backend Trident. Aucune option n'est explicitement définie dans la section des valeurs par défaut, à l'exception du modèle de nom.

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

Lorsque le volume est créé à l'aide de cette configuration backend, les options qui ne sont pas définies dans le fichier de configuration backend sont définies sur les valeurs par défaut, comme indiqué ci-dessous.

Volume créé à l'aide de la configuration du backend Trident

Cependant, lorsque vous définissez des valeurs dans la section par défaut de la configuration du backend Trident, vous pouvez créer des volumes qui peuvent avoir des valeurs spécifiques pour ces paramètres. Dans l'exemple suivant, snapshotPolicy est définie sur la stratégie par défaut (elle est « none » si vous ne définissez rien explicitement) et snapshotDir est définie sur « true » dans la section par défaut du fichier de configuration yaml du backend. Avec ces paramètres, vous pouvez constater que le volume du backend reçoit ces valeurs. (snapdir-access est « true » et snapshot-policy est « default »)

section par défaut avec des valeurs explicites

définissez explicitement les valeurs snapshotDir et snapshotPolicy dans la configuration du backend

définissez explicitement les valeurs snapshotDir et snapshotPolicy dans le volume

Pour tous les autres paramètres supplémentaires, veuillez consulter la documentation Trident :

  1. "Options de configuration du backend NAS Trident" +

  2. "Options de configuration du backend SAN Trident"

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.

Exemple de secret backend et de fichier de configuration backend utilisant la méthode d'authentification par nom d'utilisateur et mot de passe (enregistrez 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

Exemple de secret backend et de fichier de configuration backend utilisant la méthode d'authentification par certificat client (enregistrez sous 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 (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
NAS économique

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

Exemple de secret backend et de fichier de configuration backend utilisant la méthode d'authentification par nom d'utilisateur et mot de passe (enregistrez sous 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 (enregistrer sous 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
Remarque Veuillez consulter la section « Directives essentielles pour les options de configuration du backend du pilote NAS economy » ci-dessus pour plus de détails sur les paramètres supplémentaires pouvant être inclus dans le fichier de configuration du pilote ontap-nas-economy.
SAN iSCSI

Créez un TridentBackendConfig et un StorageClass pour ONTAP SAN avec iSCSI afin d'activer le provisionnement de 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. Le paramètre sanType utilise par défaut le protocole iSCSI s'il est omis.

Secret backend et fichier de configuration backend utilisant la méthode d'authentification par nom d'utilisateur et mot de passe (enregistrez 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

Secret backend et fichier de configuration backend utilisant la méthode d'authentification par certificat client (enregistrez sous 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 (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
SAN 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 utilisant la méthode d'authentification par nom d'utilisateur et mot de passe (enregistrez 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

Secret backend et fichier de configuration backend utilisant la méthode d'authentification par certificat client (enregistrez sous 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 (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
Remarque Si vous prévoyez d'utiliser des volumes ReadWriteMany (RWX) avec le protocole NVMe, un seul volume NVMe RWX ne peut pas être monté par plus de 64 nœuds dans un cluster Kubernetes. Pour plus d'informations sur cette limitation et sur le modèle de super-sous-système introduit dans Trident 26.02 ainsi que sur le modèle de sous-système par volume antérieur à Trident 26.02, consultez la documentation Trident : https://docs.netapp.com/us-en/trident/trident-use/ontap-san-prep.html#nvme-tcp-considerations.
FC SAN

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.

Utilisez la méthode d'authentification par nom d'utilisateur/mot de passe ou la méthode d'authentification par certificat client pour vous authentifier auprès d'ONTAP. Pour plus d'informations sur la génération du certificat client, de la clé privée et du certificat d'autorité de certification, veuillez consulter "Documentation Trident ici". Des exemples pour les deux méthodes sont fournis ci-dessous.

Afficher un exemple

Secret backend et fichier de configuration backend utilisant la méthode d'authentification par nom d'utilisateur et mot de passe ONTAP (enregistrez 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

Secret backend et fichier de configuration backend utilisant la méthode d'authentification par certificat client (enregistrez sous 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
économie SAN iSCSI

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

Secret backend et fichier de configuration backend utilisant la méthode d'authentification par certificat client (enregistrez sous 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"

Consultez la documentation Trident pour obtenir des exemples supplémentaires de fichiers yaml, ainsi que des informations sur les modes d'accès et les modes de volume pris en charge par les pilotes SAN et NAS.

  1. "Exemples utilisant des pilotes NAS"

  2. "Exemples utilisant des pilotes SAN"

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

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