Trident est commercialisé tous les quatre mois à partir de la version 24.02 : février, juin et octobre.

Trident ne prend généralement pas en charge les fonctionnalités alpha dans Kubernetes. Trident peut prendre en charge les fonctionnalités bêta dans les deux versions de Trident, qui suivent la version bêta de Kubernetes.

Trident ne dépend d'aucun autre produit logiciel NetApp et fonctionne comme une application autonome. Toutefois, vous devez disposer d'un système de stockage back-end NetApp.

Utilisez tridentctl get la commande pour obtenir plus d'informations sur votre configuration Trident.

Oui. Les terminaux Prometheus peuvent être utilisés pour rassembler des informations sur les opérations Trident, telles que le nombre de systèmes back-end gérés, le nombre de volumes provisionnés, d'octets consommés, etc. Vous pouvez également l'utiliser "Cloud Insights" pour la surveillance et l'analyse.

Non. Il n'y a pas de changement en ce qui concerne l'expérience utilisateur et les fonctionnalités. Le nom de provisionneur utilisé est csi.trident.netapp.io. Cette méthode d'installation de Trident est recommandée si vous souhaitez utiliser toutes les nouvelles fonctionnalités fournies par les versions actuelles et futures.

Oui, Trident peut être installé hors ligne. Reportez-vous à la "En savoir plus sur l'installation de Trident".

Oui. Trident 18.10 et les versions ultérieures prennent en charge la fonctionnalité d'installation à distance à partir de n'importe quelle machine ayant kubectl accès au cluster. Une fois l' kubectl`accès vérifié (par exemple, lancez une `kubectl get nodes commande à partir de l'ordinateur distant pour vérifier), suivez les instructions d'installation.

Trident est installé en tant que déploiement Kubernetes (ReplicaSet) avec une instance. Sa haute disponibilité est donc intégrée. Vous ne devez pas augmenter le nombre de répliques dans le déploiement. Si le nœud sur lequel Trident est installé est perdu ou si le pod est inaccessible, Kubernetes redéploie automatiquement le pod vers un nœud sain dans le cluster. Trident est un plan de contrôle uniquement. Les pods actuellement montés ne sont donc pas affectés si Trident est redéployé.

Trident lit depuis le serveur d'API Kubernetes pour déterminer quand les applications demandent de nouvelles ESV et doit donc accéder à kube-system.

Le programme d'installation Trident crée un cluster Kubernetes ClusterRole, qui dispose d'un accès spécifique aux ressources PersistentVolume, PersistentVolumeClaim, StorageClass et Secret du cluster Kubernetes. Reportez-vous à la section "Personnalisez l'installation tridentctl".

Vous pouvez, si nécessaire, générer et modifier localement les fichiers de manifeste exacts que Trident utilise pour l'installation. Reportez-vous à la "Personnalisez l'installation tridentctl".

Bien qu'il ne soit pas conseillé, vous pouvez utiliser la même SVM back-end pour deux instances Trident. Spécifiez un nom de volume unique pour chaque instance lors de l'installation et/ou spécifiez un paramètre unique StoragePrefix dans setup/backend.json le fichier. Ceci permet de s'assurer que le même FlexVol n'est pas utilisé pour les deux instances.

Trident est un pod Kubernetes qui peut être installé quel que soit l'emplacement d'exécution de Kubernetes.

Oui, Trident est pris en charge sur AWS, Google Cloud et Azure.

Oui, Trident prend en charge le service Azure NetApp Files dans Azure ainsi que Cloud Volumes Service dans GCP.

Bien que Trident soit open source et gratuit, NetApp le prend entièrement en charge, à condition que votre back-end NetApp soit pris en charge.

Pour soulever un dossier de support, effectuez l'une des opérations suivantes :

Vous pouvez créer un bundle de support en exécutant tridentctl logs -a. Outre les journaux capturés dans le pack, capture le journal kubelet pour diagnostiquer les problèmes de montage côté Kubernetes. Les instructions d'obtention du journal kubelet varient en fonction de l'installation de Kubernetes.

Créez un problème "Trident Github" et mentionnez RFE dans l'objet et la description du problème.

Créez un problème sur "Trident Github". Veillez à inclure toutes les informations et tous les journaux nécessaires concernant le problème.

Pour toute question, problème ou demande, contactez-nous par le biais de notre Trident "Déroulez le canal"ou GitHub.

Mettez à jour le mot de passe du back-end avec tridentctl update backend myBackend -f </path/to_new_backend.json> -n trident. Remplacement myBackend dans l'exemple avec votre nom de back-end, et `/path/to_new_backend.json avec le chemin d'accès correct backend.json fichier.

Trident ne trouve pas de nœud Kubernetes dans deux scénarios possibles. Elle peut être due à un problème de mise en réseau dans Kubernetes ou DNS. Le demonset de nœuds Trident qui s'exécute sur chaque nœud Kubernetes doit pouvoir communiquer avec le contrôleur Trident pour enregistrer le nœud avec Trident. Si des modifications de mise en réseau se sont produites après l'installation de Trident, ce problème survient uniquement avec les nouveaux nœuds Kubernetes ajoutés au cluster.

Les données ne seront pas perdues si le pod Trident est détruit. Les métadonnées Trident sont stockées dans des objets CRD. Tous les volumes persistants provisionnés par Trident fonctionneront normalement.

NetApp prend en charge la mise à niveau de Trident d'une version majeure vers la prochaine version majeure immédiate. Vous pouvez effectuer la mise à niveau de la version 18.xx vers la version 19.xx, 19.xx vers la version 20.xx, etc. Il est conseillé de tester la mise à niveau dans un laboratoire avant le déploiement en production.

Si vous avez besoin d'un correctif pour les bogues observés après une mise à niveau, des problèmes de dépendance ou une mise à niveau non réussie ou incomplète, vous devez "Désinstallez Trident"réinstaller la version précédente en suivant les instructions spécifiques à cette version. Il s'agit de la seule méthode recommandée pour revenir à une version antérieure.

Le LIF de gestion est obligatoire. Data LIF varie :

Oui. Trident prend en charge le protocole CHAP bidirectionnel pour les systèmes back-end ONTAP. Ceci nécessite la useCHAP=true configuration de votre back-end.

Trident peut créer et gérer de manière dynamique des règles d'exportation à partir de la version 20.04. Cela permet à l'administrateur de stockage de fournir un ou plusieurs blocs CIDR dans leur configuration backend et de laisser Trident ajouter des adresses IP de nœud comprise dans ces plages à une export policy créée. De cette manière, Trident gère automatiquement l'ajout et la suppression de règles pour les nœuds avec des adresses IP dans les délais de modification donnés.

Trident prend en charge la définition des adresses IPv6 pour :

Trident doit être installé à l'aide de l'indicateur --use-ipv6 (pour l' tridentctl`installation), `IPv6 (pour l'opérateur Trident) ou tridentTPv6 (pour l'installation Helm) pour qu'il fonctionne sur IPv6.

Oui, il est possible de mettre à jour la LIF de management back-end à l'aide de tridentctl update backend commande.

Vous pouvez mettre à jour la LIF de données sur ontap-nas et ontap-nas-economy uniquement.

Trident peut prendre en charge plusieurs systèmes back-end simultanément, avec le même pilote ou des pilotes différents.

Trident stocke les informations d'identification du back-end en tant que secrets Kubernetes.

Si les attributs back-end ne peuvent pas être utilisés pour sélectionner automatiquement les pools appropriés pour une classe, l' storagePools et additionalStoragePools les paramètres sont utilisés pour sélectionner un ensemble spécifique de pools.

Le excludeStoragePools paramètre est utilisé pour filtrer l'ensemble de pools que Trident utilise pour le provisionnement et supprime tous les pools correspondant.

S'il existe plusieurs systèmes back-end configurés du même type, Trident sélectionne le back-end approprié en fonction des paramètres présents dans StorageClass et PersistentVolumeClaim. Par exemple, s'il existe plusieurs systèmes back-end de pilotes ONTAP-nas, Trident tente de faire correspondre les paramètres dans le StorageClass et le combiné et PersistentVolumeClaim un back-end qui peut répondre aux exigences répertoriées dans StorageClass le et `PersistentVolumeClaim`le . Si plusieurs systèmes back-end correspondent à la demande, Trident les sélectionne de manière aléatoire.

Oui.

Le ontap-nas-economy Le pilote crée jusqu'à 200 qtrees dans le même FlexVol (configurables entre 50 et 300), 100,000 qtrees par nœud de cluster et 2,4 millions par cluster. Lorsque vous saisissez un nouveau PersistentVolumeClaim Le pilote cherche à voir si un FlexVol existe déjà pour le service du nouveau qtree. Si la FlexVol n'existe pas qui peut traiter le qtree, un nouveau FlexVol est créé.

Vous pouvez définir des autorisations Unix sur le volume provisionné par Trident en définissant un paramètre dans le fichier de définition back-end.

Par défaut, Trident ne définit aucune valeur des options de montage sur Kubernetes. Pour spécifier les options de montage dans la classe de stockage Kubernetes, suivez l'exemple donné "ici".

Pour permettre aux hôtes appropriés d'accéder à un volume, utilisez le exportPolicy paramètre configuré dans le fichier de définition backend.

Vous pouvez définir le chiffrement sur le volume provisionné par Trident à l'aide du paramètre de chiffrement dans le fichier de définition back-end. Pour plus d'informations, reportez-vous à : "Fonctionnement de Trident avec NVE et NAE"

Utiliser StorageClasses Afin d'implémenter la QoS pour ONTAP.

Les pilotes ONTAP prennent en charge le provisionnement fin ou non fin. Le provisionnement fin est par défaut pour les pilotes ONTAP. Si un provisionnement lourd est souhaité, vous devez configurer le fichier de définition backend ou le StorageClass. Si les deux sont configurés, StorageClass a priorité. Configurez les éléments suivants pour ONTAP :

La protection contre la demande de volume persistant est automatiquement activée sur Kubernetes à partir de la version 1.10.

Oui. Vous pouvez développer une demande de volume persistant créée par Trident. Notez que la croissance automatique de volume est une fonctionnalité ONTAP qui n'est pas applicable à Trident.

L'importation du volume échoue si le volume externe est en mode DP ou est hors ligne. Vous recevez le message d'erreur suivant :

Le quota de ressources de stockage Kubernetes doit fonctionner tant que le stockage NetApp possède de la capacité. Lorsque le stockage NetApp ne peut pas respecter les paramètres des quotas Kubernetes en raison d'un manque de capacité, Trident tente de se provisionner, mais des erreurs se produisent.

Oui. La création de snapshots de volumes à la demande et de volumes persistants à partir de snapshots sont prises en charge par Trident. Pour créer des volumes persistants à partir de snapshots, assurez-vous que la VolumeSnapshotDataSource porte de fonctionnalité a été activée.

Depuis, nous proposons aujourd'hui la prise en charge de snapshots à la demande ontap-nas, ontap-nas-flexgroup, ontap-san, ontap-san-economy, solidfire-san, gcp-cvs, et azure-netapp-files pilotes backend.

Cette option est disponible sur ontap-nas, ontap-san, et ontap-nas-flexgroup pilotes. Vous pouvez également spécifier un snapshotPolicy pour le ontap-san-economy Pilote au niveau FlexVol.

Cela est également disponible sur les ontap-nas-economy pilotes, mais au niveau de la granularité FlexVol, et non au niveau qtree. Pour activer la fonction de snapshot des volumes provisionnés par Trident, définissez l'option du paramètre back-end snapshotPolicy sur la règle de snapshot souhaitée, comme défini sur le back-end ONTAP. Les snapshots pris par le contrôleur de stockage ne sont pas connus par Trident.

Oui, vous pouvez réserver un pourcentage spécifique d'espace disque pour stocker les copies Snapshot via Trident en définissant l' snapshotReserve`attribut dans le fichier de définition back-end. Si vous avez configuré `snapshotPolicy et snapshotReserve dans le fichier de définition back-end, le pourcentage de réserve de snapshots est défini en fonction du snapshotReserve pourcentage mentionné dans le fichier back-end. Si le snapshotReserve pourcentage n'est pas mentionné, ONTAP utilise par défaut le pourcentage de réserve d'instantanés à 5. Si l' `snapshotPolicy`option est définie sur aucun, le pourcentage de réserve d'instantanés est défini sur 0.

Oui, vous pouvez accéder au répertoire de snapshots sur le volume provisionné par Trident en paramétrant le snapshotDir paramètre dans le fichier de définition backend.

Actuellement, SnapMirror doit être défini en externe via l'interface de ligne de commande ONTAP ou OnCommand System Manager.

Pour restaurer un volume sur un snapshot ONTAP, effectuez les opérations suivantes :

Des miroirs de partage de charge peuvent être créés pour les volumes root des SVM qui fournissent des données sur NFS. ONTAP met automatiquement à jour les miroirs de partage de charge pour les volumes qui ont été créés par Trident. Cela peut entraîner des retards dans le montage des volumes. Lorsque plusieurs volumes sont créés via Trident, le provisionnement d'un volume dépend de la mise à jour par ONTAP du miroir de partage de charge.

Kubernetes n'autorise pas les classes de stockage dans les espaces de noms. Toutefois, vous pouvez utiliser Kubernetes pour limiter l'utilisation d'une classe de stockage spécifique par espace de noms à l'aide de quotas de ressources de stockage, qui sont par espace de noms. Pour refuser un accès d'espace de noms spécifique à un stockage spécifique, définissez le quota de ressources sur 0 pour cette classe de stockage.