Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Exigences de Trident

PDF

Avant d'installer Trident, vous devez examiner ces exigences générales du système. Certains backends peuvent avoir des exigences supplémentaires.

Informations essentielles sur Trident

Vous devez lire les informations essentielles suivantes concernant Trident.

<strong>Informations essentielles sur Trident</strong>

  • Kubernetes 1.37 est désormais pris en charge par Trident. Veuillez mettre à niveau Trident avant de mettre à niveau Kubernetes.

  • Trident impose strictement l'utilisation de la configuration multipath dans les environnements SAN, avec une valeur recommandée de find_multipaths: no dans le fichier multipath.conf.

    L'utilisation d'une configuration sans multipath ou l'utilisation de find_multipaths: yes ou find_multipaths: smart dans le fichier multipath.conf entraînera des échecs de montage. Trident a recommandé l'utilisation de find_multipaths: no depuis la version 21.07.

Interfaces prises en charge (orchestrators)

Trident prend en charge plusieurs moteurs de conteneurs et orchestrateurs, notamment les suivants :

  • Anthos On-Prem (VMware) et Anthos on bare metal 1.16

  • Kubernetes 1.27 - 1.37

  • OpenShift 4.12, 4.14 - 4.22 (Si vous prévoyez d'utiliser la préparation de nœud iSCSI avec OpenShift 4.19, la version minimale de Trident prise en charge est 25.06.1.)

    Remarque Trident continue de prendre en charge les anciennes versions de OpenShift en accord avec le "Cycle de vie des versions Red Hat Extended Update Support (EUS)", même si elles reposent sur des versions de Kubernetes qui ne sont plus officiellement prises en charge en amont. Lors de l'installation de Trident dans de tels cas, vous pouvez ignorer sans risque les messages d'avertissement concernant la version de Kubernetes.

  • Rancher Kubernetes Engine 2 (RKE2) v1.28.x - 1.37.x

Trident fonctionne également avec de nombreuses autres offres Kubernetes entièrement gérées et autogérées, y compris Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Services (EKS), Azure Kubernetes Service (AKS), Mirantis Kubernetes Engine (MKE) et VMWare Tanzu Portfolio.

Trident et ONTAP peuvent être utilisés comme fournisseur de stockage pour "KubeVirt".

Avertissement Avant de mettre à niveau un cluster Kubernetes de la version 1.25 à la version 1.26 ou ultérieure sur lequel Trident est installé, reportez-vous à "Mettre à niveau une installation Helm".

Backends pris en charge (stockage)

Pour utiliser Trident, vous avez besoin d'un ou plusieurs des backends pris en charge suivants :

  • Amazon FSx for NetApp ONTAP

  • Azure NetApp Files

  • Cloud Volumes ONTAP

  • Google Cloud NetApp Volumes

  • NetApp All SAN Array (ASA)

  • FAS, AFF ou ASA r2 sur site (iSCSI, NVMe/TCP et FC) exécutant des versions d'ONTAP bénéficiant d'une prise en charge complète ou limitée par NetApp. Voir "Prise en charge des versions logicielles".

  • NetApp HCI/Element logiciel 11 ou supérieur

Prise en charge de Trident pour KubeVirt et la virtualisation OpenShift

Pilotes de stockage pris en charge :

Trident prend en charge les pilotes ONTAP suivants pour KubeVirt et OpenShift Virtualization :

  • ontap-nas

  • ontap-san (iSCSI, FCP, NVMe over TCP)

  • ontap-san-economy (iSCSI uniquement)

Points à prendre en considération :

  • Mettez à jour la classe de stockage pour avoir le fsType paramètre (par exemple : fsType: "ext4") dans l'environnement OpenShift Virtualization. Si nécessaire, définissez explicitement le mode de volume sur bloc à l'aide du volumeMode=Block paramètre dans le dataVolumeTemplates pour notifier à CDI de créer des volumes de données de type Block.

  • Mode d'accès RWX pour les pilotes de stockage bloc : les pilotes ontap-san (iSCSI, NVMe/TCP, FC) et ontap-san-economy (iSCSI) ne sont pris en charge qu'avec « volumeMode: Block » (périphérique brut). Pour ces pilotes, le fstype paramètre ne peut pas être utilisé car les volumes sont fournis en mode périphérique brut.

  • Pour les flux de travail de migration à chaud où le mode d'accès RWX est requis, ces combinaisons sont prises en charge :

    • NFS + volumeMode=Filesystem

    • iSCSI + volumeMode=Block (périphérique brut)

    • NVMe/TCP volumeMode=Block (périphérique brut)

    • FC + volumeMode=Block (périphérique brut)

Prise en charge de Trident pour Kubernetes sur Kubernetes et les plans de contrôle hébergés OpenShift

À partir de la version 26.06, Trident prend pleinement en charge la topologie Kubernetes sur Kubernetes. Les clusters Kubernetes dont les nœuds s’exécutent en tant que machines virtuelles KubeVirt sur un cluster d’infrastructure (hôte). Cette topologie sous-tend les offres de plan de contrôle hébergé telles que les plans de contrôle hébergés (HCP) OpenShift sur OpenShift Virtualization.

Remarque Cette configuration fonctionnait dans les versions précédentes, mais la qualification complète commence avec 26.06.

Le cluster invité (locataire) utilise le pilote CSI KubeVirt (kubevirt-csi comme fournisseur de stockage. Lorsqu'une charge de travail dans le cluster invité requiert un PersistentVolumeClaim volume, le pilote CSI KubeVirt crée un volume correspondant dans le cluster d'infrastructure. Trident provisionne le volume à partir d'ONTAP, et le volume est connecté à chaud à la machine virtuelle du nœud invité. Trident s'exécute uniquement dans le cluster d'infrastructure. Le cluster invité consomme le stockage ONTAP indirectement via le pilote CSI KubeVirt.

Exigences :

  • Trident est installé sur le cluster d'infrastructure avec un backend ONTAP pris en charge.

  • Une classe de stockage Trident existe dans le cluster d'infrastructure pour que le pilote CSI KubeVirt puisse mapper les volumes du cluster invité.

  • KubeVirt ou OpenShift Virtualization est déployé sur le cluster d'infrastructure, et le pilote CSI KubeVirt est installé dans chaque cluster invité.

Composant Version

Trident

26,06

Kubernetes (infrastructure et cluster invité)

1,36

KubeVirt

1.9.0-beta.0

Importateur de données conteneurisé (CDI)

1,65
Points à prendre en considération :

  • Dans le cluster invité, les volumes apparaissent comme des périphériques de stockage par blocs connectés à chaud sur les machines virtuelles des nœuds invités.

  • Le flux de travail du pilote CSI KubeVirt ne nécessite pas Trident dans le cluster invité. Vous configurez le backend ONTAP et la classe de stockage dans le cluster d'infrastructure.

Installez Trident directement dans le cluster invité :

Vous pouvez également installer Trident directement dans le cluster invité (tenant). Installez Trident dans le cluster invité lorsque vous avez besoin de l'ensemble des fonctionnalités de Trident, telles que les instantanés, les clones, le redimensionnement de volumes et l'importation, que kubevirt-csi ne fournit pas à lui seul.

Dans le cluster invité, utilisez les protocoles IP suivants : NFS, iSCSI et NVMe/TCP. Le cluster invité ne prend pas en charge Fibre Channel (FC) car les nœuds invités sont des machines virtuelles sans connectivité FC directe.

Exigences fonctionnelles

Le tableau ci-dessous récapitule les fonctionnalités disponibles avec cette version de Trident et les versions de Kubernetes qu'elle prend en charge.

Fonctionnalité Version Kubernetes Portails fonctionnels requis ?

Trident

1,27 - 1,37

Non

Instantanés de volume

1,27 - 1,37

Non

PVC à partir de Volume Snapshots

1,27 - 1,37

Non

Redimensionnement iSCSI PV

1,27 - 1,37

Non

ONTAP CHAP bidirectionnel

1,27 - 1,37

Non

Politiques d'exportation dynamiques

1,27 - 1,37

Non

Opérateur Trident

1,27 - 1,37

Non

Topologie CSI

1,27 - 1,37

Non

Systèmes d'exploitation hôtes testés

Bien que Trident ne prenne pas officiellement en charge des systèmes d'exploitation spécifiques, les suivants sont connus pour fonctionner :

  • Versions de Red Hat Enterprise Linux CoreOS (RHCOS) prises en charge par OpenShift Container Platform sur AMD64 et ARM64

  • Red Hat Enterprise Linux (RHEL) 8 ou version ultérieure sur AMD64 et ARM64

    Remarque NVMe/TCP nécessite RHEL 9 ou version ultérieure.

  • Ubuntu 22.04 LTS ou version ultérieure sur AMD64 et ARM64

  • Windows Server 2022

  • SUSE Linux Enterprise Server (SLES) 15 ou version ultérieure

Par défaut, Trident s'exécute dans un conteneur et s'exécutera donc sur n'importe quel worker Linux. Cependant, ces workers doivent pouvoir monter les volumes que Trident fournit à l'aide du client NFS standard ou de l'initiateur iSCSI, selon les backends que vous utilisez.

L' `tridentctl`utilitaire fonctionne également sur toutes ces distributions de Linux.

Configuration de l'hôte

Tous les nœuds de travail du cluster Kubernetes doivent pouvoir monter les volumes que vous avez provisionnés pour vos pods. Pour préparer les nœuds de travail, vous devez installer les outils NFS, iSCSI ou NVMe en fonction de votre sélection de pilote.

"Préparez le nœud de travail"

Configuration du système de stockage

Trident peut nécessiter des modifications d'un système de stockage avant qu'une configuration backend puisse l'utiliser.

"Configurer les backends"

Ports Trident

Trident nécessite l'accès à des ports spécifiques pour communiquer.

"Ports Trident"

Images de conteneur et versions Kubernetes correspondantes

Pour les installations isolées du réseau, la liste suivante répertorie les images de conteneurs nécessaires à l'installation de Trident. Utilisez la tridentctl images commande pour vérifier la liste des images de conteneurs nécessaires.

La prise en charge de Kubernetes 1.37 est disponible à partir de Trident 26.06. La liste d'images 26.06.2 ci-dessous inclut les images pour Kubernetes 1.37.

Images de conteneurs requises pour Trident 26.06.0

Versions de Kubernetes Image de conteneur

v1.27.0, v1.28.0, v1.29.0, v1.30.0, v1.31.0, v1.32.0, v1.33.0, v1.34.0, v1.35.0, v1.36.0

  • docker.io/netapp/trident:26.06.0

  • docker.io/netapp/trident-autosupport:26.06

  • docker.io/netapp/trident-operator:26.06.0 (facultatif)

  • registry.k8s.io/sig-storage/csi-attacher:v4.11.0

  • registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.17.0

  • registry.k8s.io/sig-storage/csi-provisioner:v6.3.0

  • registry.k8s.io/sig-storage/csi-resizer:v2.1.0

  • registry.k8s.io/sig-storage/csi-snapshotter:v8.6.0

Images de conteneurs requises pour Trident 26.06.2

Versions de Kubernetes Image de conteneur

v1.27.0, v1.28.0, v1.29.0, v1.30.0, v1.31.0, v1.32.0, v1.33.0, v1.34.0, v1.35.0, v1.36.0, v1.37.0

  • docker.io/netapp/trident:26.06.2

  • docker.io/netapp/trident-autosupport:26.06

  • docker.io/netapp/trident-operator:26.06.2 (facultatif)

  • registry.k8s.io/sig-storage/csi-attacher:v4.11.0

  • registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.18.0

  • registry.k8s.io/sig-storage/csi-provisioner:v6.3.0

  • registry.k8s.io/sig-storage/csi-resizer:v2.1.0

  • registry.k8s.io/sig-storage/csi-snapshotter:v8.6.0