La manière la plus simple de comprendre ces objets, leur utilité et leurs interactions consiste peut-être à suivre une simple requête de stockage provenant d'un utilisateur Kubernetes :

Un Kubernetes PersistentVolumeClaim L'objet représente 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 définies dans la configuration du backend :

Si le PV créé a le Delete En vertu de la politique de récupération, Trident supprime à la fois le PV et le volume de sauvegarde lorsque le PV est libéré (c'est-à-dire lorsque l'utilisateur supprime le PVC). En cas d'échec de la suppression, 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 le Retain Trident ignore cette politique et suppose que l'administrateur la supprimera de Kubernetes et du système dorsal, 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 de sauvegarde par Trident . Vous devriez le supprimer à l'aide de l'API REST(tridentctl ).

Trident prend en charge la création d'instantanés de volume à 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. De cette manière, des copies ponctuelles des PV peuvent être exposées à Kubernetes sous forme d'instantanés. Ces instantanés peuvent ensuite être utilisés pour créer de nouveaux volumes persistants. Jetez un oeil à On-Demand Volume Snapshots pour voir comment cela fonctionnerait.

Trident fournit également cloneFromPVC et splitOnClone annotations pour la création de clones. Vous pouvez utiliser ces annotations pour cloner un PVC sans avoir à utiliser 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, par exemple trident.netapp.io/cloneFromPVC: mysql . Avec cet ensemble d'annotations, Trident clone le volume correspondant au PVC mysql, au lieu de provisionner un volume à partir de zéro.

Considérez les points suivants :

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

Un Kubernetes PersistentVolume L'objet représente un élément de stockage mis à la disposition du cluster Kubernetes. Son cycle de vie est indépendant du pod qui l'utilise.

Lorsque vous créez un PVC qui fait référence à un Trident-based 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 :

Kubernetes StorageClass Les objets sont spécifiés par leur nom dans PersistentVolumeClaims provisionner un espace de stockage avec un ensemble de propriétés. La classe de stockage elle-même identifie le fournisseur à utiliser et définit cet ensemble de propriétés en des termes que le fournisseur 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 Kubernetes StorageClass Un objet utilisant Trident ressemble à ceci :

Ces paramètres sont spécifiques à Trident et indiquent à Trident comment provisionner les volumes pour cette 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 du pool de stockage et en attributs Kubernetes.

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

UN VolumeSnapshotClass La création d'instantanés doit être définie par un administrateur. Une classe d'instantané de volume est créée avec la définition suivante :

Le driver indique à Kubernetes que les demandes de snapshots de volume du csi-snapclass Les classes sont gérées par Trident. Le deletionPolicy Spécifie l'action à entreprendre lorsqu'un instantané doit être supprimé. Quand deletionPolicy est réglé sur Delete , les objets de snapshot de volume ainsi que le snapshot sous-jacent sur le cluster de stockage sont supprimés lorsqu'un snapshot est supprimé. Vous pouvez aussi le paramétrer sur Retain signifie que VolumeSnapshotContent et l'instantané physique sont conservés.

Un Kubernetes VolumeSnapshot L'objet est une requête visant à créer 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 serveur et l'expose en créant un identifiant unique.
VolumeSnapshotContent objet. Vous pouvez créer des instantanés à partir de PVC existants et utiliser ces instantanés comme source de données lors de la création de nouveaux PVC.

Un Kubernetes VolumeSnapshotContent Cet objet 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. Similaire à PersistentVolumeClaim et PersistentVolume objets, lors de la création d'un instantané, les VolumeSnapshotContent l'objet maintient une correspondance un-à-un avec le VolumeSnapshot objet, qui avait demandé la création de l'instantané.

Le VolumeSnapshotContent L'objet contient des détails qui identifient de manière unique la capture d'écran, tels que le snapshotHandle . Ce snapshotHandle est une combinaison unique du nom du PV et du nom du VolumeSnapshotContent objet.

Lorsqu'une demande de snapshot arrive, Trident crée le snapshot sur le serveur. Une fois l'instantané créé, Trident configure un VolumeSnapshotContent objet et expose ainsi l'instantané à l'API Kubernetes.

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

UN VolumeGroupSnapshotClass Un administrateur doit définir 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 du csi-group-snap-class Les classes sont gérées par Trident. Le deletionPolicy Spécifie l'action à entreprendre lorsqu'un instantané de groupe doit être supprimé. Quand deletionPolicy est réglé sur Delete , les objets d'instantané du groupe de volumes ainsi que l'instantané sous-jacent sur le cluster de stockage sont supprimés lorsqu'un instantané est supprimé. Vous pouvez aussi le paramétrer sur Retain signifie que VolumeGroupSnapshotContent et l'instantané physique sont conservés.

Un Kubernetes VolumeGroupSnapshot L'objet est une requête visant à créer un instantané de plusieurs volumes. De même qu'un PVC représente une demande faite par un utilisateur pour un volume, un instantané de groupe de volumes est une demande faite par un utilisateur pour 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 serveur et expose le snapshot en créant un identifiant unique. VolumeGroupSnapshotContent objet. Vous pouvez créer des instantanés à partir de PVC existants et utiliser ces instantanés comme source de données lors de la création de nouveaux PVC.

Un Kubernetes VolumeGroupSnapshotContent Cet objet 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. Similaire à PersistentVolumeClaim et PersistentVolume objets, lors de la création d'un instantané, les VolumeSnapshotContent l'objet maintient une correspondance un-à-un avec le VolumeSnapshot objet, qui avait demandé la création de l'instantané.

Le VolumeGroupSnapshotContent L'objet contient des détails qui identifient le groupe d'instantanés, tels que le volumeGroupSnapshotHandle et les descripteurs Snapshot de volume individuels existants sur le système de stockage.

Lorsqu'une demande de snapshot arrive, Trident crée le snapshot du groupe de volumes sur le backend. Une fois l'instantané du groupe de volumes créé, Trident configure un VolumeGroupSnapshotContent objet et expose ainsi l'instantané à l'API Kubernetes.

Les ressources personnalisées Kubernetes sont des points de terminaison de l'API Kubernetes définis par l'administrateur et utilisés 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 magasin de métadonnées. Cela élimine le besoin d'un magasin séparé pour Trident.

Trident utilise CustomResourceDefinition objets permettant de 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 cadre d'instantanés de volume CSI introduit certaines CRD nécessaires à la définition des instantanés de volume.

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

Voici quelques points à retenir concernant les CRD de Trident :

Trident crée des classes de stockage adaptées à Kubernetes StorageClass objets qui spécifient csi.trident.netapp.io dans leur domaine d'approvisionnement. Le nom de la classe de stockage correspond à celui de Kubernetes StorageClass objet qu'il représente.

Les classes de stockage comprennent un ensemble d'exigences relatives aux volumes. Trident compare 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 les classes de stockage à l'aide de l'API REST. Cependant, pour les déploiements Kubernetes, nous nous attendons à ce qu'ils soient créés lors de l'enregistrement de nouveaux Kubernetes. StorageClass objets.

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 construction de ces objets, veuillez consulter"configuration des backends" .

Les pools de stockage représentent les emplacements distincts disponibles pour le provisionnement sur chaque backend. Pour ONTAP, cela correspond à des agrégats dans les SVM. Pour NetApp HCI/ SolidFire, cela correspond à des bandes QoS spécifiées par l'administrateur. Pour Cloud Volumes Service, cela correspond aux régions des fournisseurs de cloud. Chaque pool de stockage possède un ensemble d'attributs de stockage distincts, qui définissent ses caractéristiques de performance et de protection des données.

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

Les volumes constituent l'unité de base du provisionnement, comprenant des points de terminaison backend, tels que les partages NFS, et les LUN iSCSI et FC. Dans Kubernetes, ceux-ci 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 que doit posséder un volume provisionné.

Trident génère internalName lors de la création du volume. Cela se compose de deux étapes. Premièrement, il ajoute le préfixe de stockage (soit le préfixe par défaut). trident ou 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 désinfection du nom, en remplaçant les caractères non autorisés par le système. 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 underscores 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 prévoyons que la plupart des utilisateurs utiliseront la configuration standard de Kubernetes. PersistentVolumeClaim méthode. Trident crée automatiquement cet objet volume dans le cadre du processus de provisionnement.

Les snapshots sont une copie à un instant précis des volumes, qui peuvent être utilisés pour provisionner de nouveaux volumes ou restaurer un état. Dans Kubernetes, ceux-ci correspondent directement à VolumeSnapshotContent objets. Chaque instantané est associé à un volume, qui est la source des données de cet instantané.

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

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

Le démon Trident dévore un system-node-critical Classe de priorité – la classe de priorité 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 pour garantir qu'une classe de priorité « critique pour le nœud système » sur le daemonset Trident est satisfaite. Avant le déploiement et la création du DaemonSet, Trident recherche le ResourceQuota objet et, s'il n'est pas découvert, 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 le ResourceQuota objet utilisant le graphique Helm.

Voici un exemple d'objet ResourceQuota priorisant le daemonset Trident .

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