Peut-être que la façon la plus simple de comprendre les objets, leur utilité et la façon dont ils interagissent, est de suivre une seule demande de stockage d'un utilisateur Kubernetes :

Un objet `PersistentVolumeClaim`Kubernetes est une demande de stockage effectuée par un utilisateur d'un cluster Kubernetes.

En plus de la spécification standard, Trident permet aux utilisateurs de spécifier les annotations spécifiques au volume suivantes s'ils souhaitent remplacer les valeurs par défaut que vous avez définies dans la configuration du backend :

Si le PV créé a la Delete stratégie de récupération, Trident supprime à la fois le PV et le volume sous-jacent lorsque le PV est libéré (c'est-à-dire lorsque l'utilisateur supprime le PVC). Si l'action de suppression échoue, Trident marque le PV comme tel et réessaie périodiquement l'opération jusqu'à ce qu'elle réussisse ou que le PV soit supprimé manuellement. Si le PV utilise la Retain stratégie, Trident l'ignore et suppose que l'administrateur le supprimera de Kubernetes et du backend, permettant ainsi de sauvegarder ou d'inspecter le volume avant sa suppression. Notez que la suppression du PV n'entraîne pas la suppression du volume sous-jacent par Trident. Vous devez le supprimer à l'aide de l'API REST (tridentctl.

Trident prend en charge la création d'instantanés de volumes à l'aide de la spécification CSI : vous pouvez créer un instantané de volume et l'utiliser comme source de données pour cloner des PVC existants. Ainsi, des copies à un instant donné des PV peuvent être exposées à Kubernetes sous forme d'instantanés. Les instantanés peuvent ensuite être utilisés pour créer de nouveaux PV. Consultez On-Demand Volume Snapshots pour voir comment cela fonctionne.

Trident fournit également les cloneFromPVC et splitOnClone annotations pour la création de clones. Vous pouvez utiliser ces annotations pour cloner un PVC sans avoir recours à l’implémentation CSI.

Voici un exemple : si un utilisateur possède déjà un PVC appelé mysql, l'utilisateur peut créer un nouveau PVC appelé mysqlclone en utilisant l’annotation, telle que trident.netapp.io/cloneFromPVC: mysql. Avec cette annotation définie, Trident clone le volume correspondant au PVC mysql, au lieu de provisionner un volume de zéro.

Considérez les points suivants :

Le `sample-input`répertoire contient des exemples de définitions de PVC à utiliser avec Trident. Reportez-vous à pour une description complète des paramètres et des réglages associés aux volumes Trident.

Un objet `PersistentVolume`Kubernetes représente un espace de stockage mis à la disposition du cluster Kubernetes. Il a un cycle de vie indépendant du pod qui l'utilise.

Lorsque vous créez un PVC faisant référence à un volume basé sur Trident StorageClass, Trident provisionne un nouveau volume en utilisant la classe de stockage correspondante et enregistre un nouveau PV pour ce volume. Lors de la configuration du volume provisionné et du PV correspondant, Trident suit les règles suivantes :

Les objets Kubernetes StorageClass sont spécifiés par leur nom dans PersistentVolumeClaims afin de provisionner le stockage avec un ensemble de propriétés. La classe de stockage elle-même identifie le provisionneur à utiliser et définit cet ensemble de propriétés dans des termes que le provisionneur comprend.

Il s'agit de l'un des deux objets de base que l'administrateur doit créer et gérer. L'autre est l'objet backend Trident.

Un objet Kubernetes StorageClass utilisant Trident ressemble à ceci :

Ces paramètres sont spécifiques à Trident et indiquent à Trident comment provisionner les volumes pour la classe.

Les paramètres de la classe de stockage sont :

Les attributs de stockage et leurs valeurs possibles peuvent être classés en attributs de sélection de pool de stockage et en attributs Kubernetes.

Les objets Kubernetes VolumeSnapshotClass sont analogues à StorageClasses. Ils permettent de définir plusieurs classes de stockage et sont référencés par les snapshots de volume pour associer le snapshot à la classe de snapshot requise. Chaque snapshot de volume est associé à une seule classe de snapshot de volume.

A VolumeSnapshotClass doit être défini par un administrateur afin de créer des snapshots. Une classe de snapshot de volume est créée avec la définition suivante :

Le driver indique à Kubernetes que les demandes de snapshots de volume de la classe csi-snapclass sont gérées par Trident. Le deletionPolicy spécifie l'action à entreprendre lorsqu'un snapshot doit être supprimé. Lorsque deletionPolicy est défini sur Delete, les objets snapshot de volume ainsi que le snapshot sous-jacent sur le cluster de stockage sont supprimés lorsqu'un snapshot est supprimé. Sinon, le définir sur Retain signifie que VolumeSnapshotContent et le snapshot physique sont conservés.

Un objet Kubernetes VolumeSnapshot est une demande de création d'un instantané d'un volume. De même qu'un PVC représente une demande faite par un utilisateur pour un volume, un instantané de volume est une demande faite par un utilisateur pour créer un instantané d'un PVC existant.

Lorsqu'une demande de snapshot de volume est reçue, Trident gère automatiquement la création du snapshot pour le volume sur le backend et l'expose en créant un objet
VolumeSnapshotContent unique. Vous pouvez créer des snapshots à partir de PVC existants et utiliser les snapshots comme DataSource lors de la création de nouveaux PVC.

Un objet Kubernetes VolumeSnapshotContent représente un instantané pris à partir d'un volume déjà provisionné. Il est analogue à un PersistentVolume et désigne un instantané provisionné sur le cluster de stockage. À l'instar de PersistentVolumeClaim et de PersistentVolume objets, lorsqu'un instantané est créé, l'objet VolumeSnapshotContent maintient une correspondance un-à-un avec l'objet VolumeSnapshot qui a demandé la création de l'instantané.

L' VolumeSnapshotContent`objet contient des détails qui identifient de manière unique l'instantané, tels que le `snapshotHandle. Cet `snapshotHandle`ensemble est une combinaison unique du nom du PV et du nom de l' `VolumeSnapshotContent`objet.

Lorsqu'une requête de snapshot est reçue, Trident crée le snapshot sur le backend. Une fois le snapshot créé, Trident configure un VolumeSnapshotContent objet et expose ainsi le snapshot à l'API Kubernetes.

Les objets Kubernetes VolumeGroupSnapshotClass sont analogues à VolumeSnapshotClass. Ils permettent de définir plusieurs classes de stockage et sont référencés par les snapshots de groupes de volumes afin d'associer le snapshot à la classe de snapshot requise. Chaque snapshot de groupe de volumes est associé à une seule classe de snapshot de groupe de volumes.

A VolumeGroupSnapshotClass doit être défini par un administrateur afin de créer un groupe d'instantanés. Une classe d'instantané de groupe de volumes est créée avec la définition suivante :

Le driver indique à Kubernetes que les demandes de snapshots de groupes de volumes de la classe csi-group-snap-class sont gérées par Trident. Le deletionPolicy spécifie l'action à entreprendre lorsqu'un snapshot de groupe doit être supprimé. Lorsque deletionPolicy est défini sur Delete, les objets snapshot de groupe de volumes ainsi que le snapshot sous-jacent sur le cluster de stockage sont supprimés lors de la suppression d'un snapshot. Sinon, le définir sur Retain signifie que VolumeGroupSnapshotContent et le snapshot physique sont conservés.

Un objet Kubernetes VolumeGroupSnapshot correspond à une requête de création d'un instantané de plusieurs volumes. De même qu'un PVC représente une requête d'un utilisateur pour un volume, un instantané de groupe de volumes correspond à une requête d'un utilisateur visant à créer un instantané d'un PVC existant.

Lorsqu'une demande de snapshot de groupe de volumes est reçue, Trident gère automatiquement la création du snapshot de groupe pour les volumes sur le backend et expose le snapshot en créant un objet VolumeGroupSnapshotContent unique. Vous pouvez créer des snapshots à partir de PVC existants et utiliser les snapshots comme DataSource lors de la création de nouveaux PVC.

Un objet Kubernetes VolumeGroupSnapshotContent représente un instantané de groupe pris à partir d'un volume déjà provisionné. Il est analogue à un PersistentVolume et désigne un instantané provisionné sur le cluster de stockage. À l'instar de PersistentVolumeClaim et de PersistentVolume objets, lorsqu'un instantané est créé, l'objet VolumeSnapshotContent maintient une correspondance un-à-un avec l'objet VolumeSnapshot qui a demandé la création de l'instantané.

L VolumeGroupSnapshotContent`objet contient des détails qui identifient le groupe d’instantanés, tels que le `volumeGroupSnapshotHandle et les volumeSnapshotHandles individuels existant sur le système de stockage.

Lorsqu'une requête de snapshot est reçue, Trident crée le snapshot du groupe de volumes sur le backend. Après la création du snapshot du groupe de volumes, Trident configure un VolumeGroupSnapshotContent objet et expose ainsi le snapshot à l'API Kubernetes.

Les ressources personnalisées Kubernetes sont des points de terminaison de l'API Kubernetes définis par l'administrateur et utilisées pour regrouper des objets similaires. Kubernetes prend en charge la création de ressources personnalisées pour stocker une collection d'objets. Vous pouvez obtenir ces définitions de ressources en exécutant kubectl get crds.

Les définitions de ressources personnalisées (CRD) et leurs métadonnées d'objet associées sont stockées par Kubernetes dans son système de métadonnées. Cela élimine le besoin d'un système de stockage séparé pour Trident.

Trident utilise CustomResourceDefinition des objets pour préserver l'identité des objets Trident, tels que les backends Trident, les classes de stockage Trident et les volumes Trident. Ces objets sont gérés par Trident. De plus, le framework de snapshots de volumes CSI introduit certains CRD nécessaires pour définir les snapshots de volumes.

Les CRD sont un concept Kubernetes. Les objets des ressources définies ci-dessus sont créés par Trident. À titre d'exemple simple, lorsqu'un backend est créé à l'aide de tridentctl, un objet CRD correspondant tridentbackends est créé pour être utilisé par Kubernetes.

Voici quelques points à retenir concernant les CRD de Trident :

Trident crée des classes de stockage correspondantes pour les objets Kubernetes StorageClass qui spécifient csi.trident.netapp.io dans leur champ provisioner. Le nom de la classe de stockage correspond à celui de l'objet Kubernetes StorageClass qu'elle représente.

Les classes de stockage définissent un ensemble d'exigences pour les volumes. Trident associe ces exigences aux attributs présents dans chaque pool de stockage ; s'ils correspondent, ce pool de stockage est une cible valide pour le provisionnement de volumes utilisant cette classe de stockage.

Vous pouvez créer des configurations de classes de stockage pour définir directement des classes de stockage en utilisant l'API REST. Cependant, pour les déploiements Kubernetes, nous nous attendons à ce qu'elles soient créées lors de l'enregistrement de nouveaux objets StorageClass Kubernetes.

Les backends représentent les fournisseurs de stockage sur lesquels Trident provisionne les volumes ; une seule instance de Trident peut gérer un nombre quelconque de backends.

Pour plus d'informations sur la manière de construire ces objets, reportez-vous à "configuration des backends".

Les pools de stockage représentent les emplacements distincts disponibles pour le provisionnement sur chaque backend. Pour ONTAP, ils correspondent à des agrégats dans les SVM. Pour NetApp HCI/SolidFire, ils correspondent à des niveaux de QoS définis par l'administrateur. Chaque pool de stockage possède un ensemble d'attributs de stockage spécifiques, qui définissent ses caractéristiques de performance et de protection des données.

Contrairement aux autres objets ici, les candidats au pool de stockage sont toujours découverts et gérés automatiquement.

Les volumes constituent l'unité de base du provisionnement et comprennent les points de terminaison backend, tels que les partages NFS, ainsi que les LUN iSCSI et FC. Dans Kubernetes, ils correspondent directement à PersistentVolumes. Lorsque vous créez un volume, assurez-vous qu'il possède une classe de stockage, qui détermine où ce volume peut être provisionné, ainsi qu'une taille.

Une configuration de volume définit les propriétés qu'un volume provisionné doit avoir.

Trident génère internalName lors de la création du volume. Cela consiste en deux étapes. Tout d'abord, il ajoute le préfixe de stockage (soit le préfixe par défaut trident soit le préfixe dans la configuration du backend) au nom du volume, ce qui donne un nom de la forme <prefix>-<volume-name>. Il procède ensuite à la normalisation du nom, en remplaçant les caractères non autorisés dans le backend. Pour les backends ONTAP, il remplace les tirets par des traits de soulignement (ainsi, le nom interne devient <prefix>_<volume-name>). Pour les backends Element, il remplace les traits de soulignement par des tirets.

Vous pouvez utiliser des configurations de volume pour provisionner directement des volumes via l'API REST, mais dans les déploiements Kubernetes, nous nous attendons à ce que la plupart des utilisateurs utilisent la méthode standard Kubernetes PersistentVolumeClaim. Trident crée cet objet volume automatiquement dans le cadre du processus de provisionnement.

Les snapshots sont des copies de volumes à un instant précis, permettant de provisionner de nouveaux volumes ou de restaurer un état. Dans Kubernetes, ils correspondent directement à VolumeSnapshotContent objets. Chaque snapshot est associé à un volume, qui constitue la source des données du snapshot.

Chaque Snapshot objet comprend les propriétés énumérées ci-dessous :

Lorsqu'une requête d'objet VolumeSnapshot Kubernetes est créée, Trident fonctionne en créant un objet snapshot sur le système de stockage sous-jacent. L' internalName`identifiant de cet objet snapshot est généré en combinant le préfixe `snapshot- avec l' UID`identifiant de l' `VolumeSnapshot objet (par exemple, snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660). volumeName et volumeInternalName sont renseignés en obtenant les détails du volume sous-jacent.

Le daemonset Trident consomme une `system-node-critical`Priority Class — la Priority Class la plus élevée disponible dans Kubernetes — pour garantir que Trident puisse identifier et nettoyer les volumes lors de l'arrêt progressif des nœuds et permettre aux pods du daemonset Trident de préempter les charges de travail de priorité inférieure dans les clusters où la pression sur les ressources est élevée.

Pour ce faire, Trident utilise un ResourceQuota objet afin de garantir que la classe de priorité « system-node-critical » sur le daemonset Trident soit respectée. Avant le déploiement et la création du daemonset, Trident recherche l' ResourceQuota objet et, s'il n'est pas trouvé, l'applique.

Si vous avez besoin de plus de contrôle sur le quota de ressources par défaut et la classe de priorité, vous pouvez générer un custom.yaml ou configurer l'objet ResourceQuota à l'aide du Helm chart.

L'exemple suivant montre un objet ResourceQuota qui donne la priorité au daemonset Trident.

Pour plus d'informations sur les quotas de ressources, veuillez consulter "Kubernetes : Quotas de ressources".