La manière la plus simple de comprendre les objets, leur rôle et leur interaction consiste à suivre une seule demande de stockage auprès d'un utilisateur Kubernetes :

Un objet Kubernetes PersistentVolumeClaim est une demande de stockage émise par un utilisateur de cluster Kubernetes.

Outre la spécification standard, Trident permet aux utilisateurs de spécifier les annotations spécifiques au volume suivantes s'ils veulent remplacer les valeurs par défaut que vous définissez dans la configuration back-end :

Si le volume persistant créé est associé à la Delete règle de récupération, Trident supprime le volume persistant et le volume de sauvegarde lorsque le volume persistant est libéré (c'est-à-dire lorsque l'utilisateur supprime la demande de volume persistant). En cas d'échec de l'action de suppression, Trident marque le volume persistant comme tel et tente régulièrement l'opération jusqu'à ce qu'il réussisse ou que le volume persistant soit supprimé manuellement. Si le volume persistant utilise Retain la règle, Trident l'ignore et suppose que l'administrateur le nettoie depuis Kubernetes et le back-end, ce qui permet de sauvegarder ou d'inspecter le volume avant sa suppression. Notez que la suppression du volume persistant n'entraîne pas la suppression du volume de sauvegarde par Trident. Vous devez le supprimer à l'aide de l'API REST (tridentctl).

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

Trident propose également les cloneFromPVC annotations et splitOnClone pour la création de clones. Vous pouvez utiliser ces annotations pour cloner une demande de volume persistant sans avoir à utiliser l'implémentation CSI.

Voici un exemple : si un utilisateur a déjà un PVC appelé mysql, l'utilisateur peut créer un nouveau PVC appelé à mysqlclone l'aide de l'annotation, telle que trident.netapp.io/cloneFromPVC: mysql. Avec ce jeu d'annotations, Trident clone le volume correspondant à la demande de volume mysql au lieu de provisionner un volume entièrement.

Prenez en compte les points suivants :

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

Un objet Kubernetes PersistentVolume représente un élément de stockage mis à disposition du cluster Kubernetes. Il dispose d'un cycle de vie indépendant du pod qui l'utilise.

Lorsque vous créez une demande de volume virtuel qui fait 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 volume persistant pour ce volume. Lors de la configuration du volume provisionné et du volume persistant correspondant, Trident respecte les règles suivantes :

Les objets Kubernetes StorageClass sont spécifiés par leur nom dans PersistentVolumeClaims pour provisionner le stockage avec un ensemble de propriétés. La classe de stockage elle-même identifie le mécanisme de provisionnement à utiliser et définit cet ensemble de propriétés, comme le mécanisme de provisionnement le comprend.

Il s'agit de l'un des deux objets de base qui doivent être créés et gérés par l'administrateur. L'autre est l'objet back-end Trident.

Voici à quoi ressemble un objet Kubernetes StorageClass utilisant Trident :

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

Les paramètres de classe de stockage sont les suivants :

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

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

Un VolumeSnapshotClass doit être défini par un administrateur pour créer des instantanés. Une classe de snapshots de volume est créée avec la définition suivante :

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

Un objet Kubernetes VolumeSnapshot est une demande de création d'une copie Snapshot d'un volume. Tout comme un volume persistant représente une demande de copie Snapshot d'un volume effectuée par un utilisateur, une copie Snapshot de volume est une demande de création d'un snapshot d'une demande de volume persistant existante.

Lorsqu'une demande de Snapshot de volume est émise, Trident gère automatiquement la création de la copie Snapshot du volume sur le back-end et expose la copie Snapshot en créant un objet unique
VolumeSnapshotContent. Vous pouvez créer des instantanés à partir de ESV existantes et les utiliser comme source de données lors de la création de nouveaux ESV.

Un objet Kubernetes VolumeSnapshotContent représente un snapshot d'un volume déjà provisionné. Elle est similaire à un PersistentVolume et signifie un snapshot provisionné sur le cluster de stockage. Comme PersistentVolumeClaim pour les objets et PersistentVolume, lors de la création d'un Snapshot, l' `VolumeSnapshotContent`objet conserve un mappage un-à-un sur l' `VolumeSnapshot`objet qui avait demandé la création du Snapshot.

L' VolumeSnapshotContent`objet contient des détails qui identifient de manière unique le snapshot, tels que `snapshotHandle . Il snapshotHandle s'agit d'une combinaison unique du nom du PV et du nom de l' `VolumeSnapshotContent`objet.

Lorsqu'une requête de snapshot est fournie, Trident crée le snapshot sur le back-end. Une fois le snapshot créé, Trident configure un VolumeSnapshotContent objet et expose ce dernier à l'API Kubernetes.

Les ressources personnalisées Kubernetes sont des terminaux 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 le stockage d'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 les métadonnées d'objet associées sont stockées sur le magasin de métadonnées Kubernetes. Ce qui évite d'avoir recours à un magasin séparé pour Trident.

ASTRA Trident utilise CustomResourceDefinition des objets pour préserver l'identité des objets Trident, tels que les systèmes back-end Trident, les classes de stockage Trident et les volumes Trident. Ces objets sont gérés par Trident. En outre, la structure d'instantané de volume CSI introduit quelques CRD nécessaires pour définir des instantanés de volume.

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

Voici quelques points à garder à l'esprit sur 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 de provisionnement. Le nom de classe de stockage correspond à celui de l'objet Kubernetes StorageClass qu'il représente.

Les classes de stockage comprennent un ensemble d'exigences pour les volumes. Trident mappe ces exigences avec les attributs présents dans chaque pool de stockage. S'ils correspondent, ce pool de stockage est une cible valide pour le provisionnement des volumes qui utilisent cette classe de stockage.

Vous pouvez créer des configurations de classes de stockage afin de définir directement des classes de stockage à l'aide de l'API REST. Toutefois, pour les déploiements Kubernetes, nous prévoyons qu'ils seront créés lors de l'enregistrement de nouveaux objets Kubernetes StorageClass.

Les systèmes back-end représentent les fournisseurs de stockage au-dessus desquels Trident provisionne des volumes. Une instance Trident unique peut gérer un nombre illimité de systèmes back-end.

Pour plus d'informations sur la construction de ces objets, reportez-vous à la section "configuration des systèmes back-end".

Les pools de stockage représentent les emplacements distincts disponibles pour le provisionnement sur chaque système back-end. Pour ONTAP, ces derniers correspondent à des agrégats dans des SVM. Pour NetApp HCI/SolidFire, ils correspondent aux bandes QoS spécifiées par l'administrateur. Pour Cloud Volumes Service, ces régions correspondent à des régions du fournisseur cloud. Chaque pool de stockage dispose d'un ensemble d'attributs de stockage distincts, qui définissent ses caractéristiques de performances et ses caractéristiques 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 sont l'unité de provisionnement de base, comprenant les terminaux back-end, tels que les partages NFS et les LUN iSCSI. Dans Kubernetes, ces valeurs correspondent directement à PersistentVolumes. Lorsque vous créez un volume, assurez-vous qu'il possède une classe de stockage, qui détermine l'emplacement de provisionnement de ce volume, ainsi que sa 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. Il s'agit de deux étapes. Tout d'abord, il ajoute le préfixe de stockage (le préfixe par défaut trident ou le préfixe dans la configuration back-end) au nom du volume, ce qui entraîne un nom de formulaire <prefix>-<volume-name>. Il procède ensuite à la désinfection du nom en remplaçant les caractères non autorisés dans le back-end. Pour les systèmes ONTAP back-end, il remplace les tirets par des traits de soulignement (le nom interne devient ainsi <prefix>_<volume-name> ). Pour les systèmes back-end Element, il remplace les tirets de traits de soulignement.

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

Les snapshots sont une copie de volumes à un point dans le temps, qui peut être utilisée pour provisionner de nouveaux volumes ou restaurer l'état de ces volumes. Dans Kubernetes, ces données correspondent directement aux VolumeSnapshotContent objets. Chaque snapshot est associé à un volume, qui est la source des données du snapshot.

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

Lors de la création d'une demande d'objet Kubernetes VolumeSnapshot, Trident crée un objet de snapshot sur le système de stockage qui soutient. Le internalName de cet objet de snapshot est généré en combinant le préfixe snapshot- et le UID 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 de sauvegarde.

La déamonset Trident consomme une system-node-critical classe de priorité, la classe de priorité la plus élevée disponible dans Kubernetes, pour s'assurer qu'Astra Trident peut identifier et nettoyer les volumes lors de l'arrêt gracieux des nœuds et permettre aux pods de diabodéfinis Trident d'anticiper les charges de travail avec une priorité inférieure dans les clusters où la pression des ressources est élevée.

Pour ce faire, Astra Trident utilise un ResourceQuota objet afin de s'assurer qu'une classe de priorité « système-nœud-critique » sur le démonset Trident est satisfaite. Avant le déploiement et la création d'un jeu de données, Astra Trident recherche ResourceQuota l'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 l' `ResourceQuota`objet à l'aide du graphique Helm.

Voici un exemple de `Resourcequota"objet hiérarchisant le demonset Trident.

Pour plus d'informations sur les quotas de ressources, reportez-vous "Kubernetes : quotas de ressources"à la section .