Forse il modo più semplice per comprendere gli oggetti, il loro scopo e il modo in cui interagiscono è seguire una singola richiesta di storage da parte di un utente Kubernetes:

Un oggetto Kubernetes PersistentVolumeClaim è una richiesta di storage creata da un utente del cluster Kubernetes.

Oltre alla specifica standard, Trident consente agli utenti di specificare le seguenti annotazioni specifiche del volume se desiderano sovrascrivere i valori predefiniti impostati nella configurazione di backend:

Se il PV creato dispone della Delete policy di recupero, Trident elimina sia il PV che il volume di backup quando il PV viene rilasciato (ovvero quando l'utente elimina il PVC). In caso di errore dell'azione di eliminazione, Trident contrassegna il PV come tale e riprova periodicamente l'operazione fino a quando non viene eseguita correttamente o finché il PV non viene cancellato manualmente. Se il PV utilizza Retain la policy, Trident la ignora e presuppone che l'amministratore lo ripulisca da Kubernetes e dal back-end, consentendo di eseguire il backup o l'ispezione del volume prima della sua rimozione. L'eliminazione del PV non comporta l'eliminazione del volume di backup da parte di Trident. È necessario rimuoverlo utilizzando l'API REST (tridentctl).

Trident supporta la creazione di snapshot dei volumi utilizzando la specifica CSI: È possibile creare un'istantanea del volume e utilizzarla come origine dati per clonare i PVC esistenti. In questo modo, le copie point-in-time di PVS possono essere esposte a Kubernetes sotto forma di snapshot. Le istantanee possono quindi essere utilizzate per creare un nuovo PVS. Date un'occhiata a On-Demand Volume Snapshots per vedere come funzionerebbe.

Trident fornisce anche le cloneFromPVC annotazioni e splitOnClone per la creazione dei cloni. È possibile utilizzare queste annotazioni per clonare un PVC senza dover utilizzare l'implementazione CSI.

Ecco un esempio: Se un utente ha già un PVC chiamato mysql, l'utente può creare un nuovo PVC chiamato mysqlclone utilizzando l'annotazione, come trident.netapp.io/cloneFromPVC: mysql. Con questo set di annotazioni, Trident clona il volume corrispondente al PVC mysql, invece di eseguire il provisioning di un volume da zero.

Considerare i seguenti punti:

La sample-input directory contiene esempi di definizioni PVC da utilizzare con Trident. Fare riferimento alla per una descrizione completa dei parametri e delle impostazioni associati ai volumi Trident.

Un oggetto Kubernetes PersistentVolume rappresenta una parte dello storage resa disponibile per il cluster Kubernetes. Ha un ciclo di vita indipendente dal pod che lo utilizza.

Quando si crea un PVC che fa riferimento a un PVC basato su Trident StorageClass , Trident esegue il provisioning di un nuovo volume utilizzando la classe di archiviazione corrispondente e registra un nuovo PV per quel volume. Nella configurazione del volume sottoposto a provisioning e del PV corrispondente, Trident segue le seguenti regole:

Gli oggetti Kubernetes StorageClass sono specificati per nome in PersistentVolumeClaims per effettuare il provisioning dello storage con un set di proprietà. La stessa classe di storage identifica il provider da utilizzare e definisce il set di proprietà in termini che il provider riconosce.

Si tratta di uno dei due oggetti di base che devono essere creati e gestiti dall'amministratore. L'altro è l'oggetto backend Trident.

Un oggetto Kubernetes StorageClass che utilizza Trident è simile al seguente:

Questi parametri sono specifici di Trident e indicano a Trident come eseguire il provisioning dei volumi per la classe.

I parametri della classe di storage sono:

Gli attributi di storage e i loro possibili valori possono essere classificati in attributi di selezione del pool di storage e attributi Kubernetes.

Gli oggetti Kubernetes VolumeSnapshotClass sono analoghi a StorageClasses. Consentono di definire più classi di storage e vengono utilizzate dagli snapshot dei volumi per associare lo snapshot alla classe di snapshot richiesta. Ogni snapshot di volume è associato a una singola classe di snapshot di volume.

Un VolumeSnapshotClass deve essere definito da un amministratore per creare snapshot. Viene creata una classe di snapshot del volume con la seguente definizione:

Un oggetto Kubernetes VolumeSnapshot è una richiesta per creare una snapshot di un volume. Proprio come un PVC rappresenta una richiesta fatta da un utente per un volume, uno snapshot di volume è una richiesta fatta da un utente per creare uno snapshot di un PVC esistente.

Quando arriva una richiesta di snapshot di un volume, Trident gestisce automaticamente la creazione dello snapshot per il volume sul backend ed espone lo snapshot creando un oggetto univoco
VolumeSnapshotContent. È possibile creare snapshot da PVC esistenti e utilizzarle come DataSource durante la creazione di nuovi PVC.

Un oggetto Kubernetes VolumeSnapshotContent rappresenta una snapshot ricavata da un volume già sottoposto a provisioning. È analogo a e indica una PersistentVolume snapshot sottoposta a provisioning sul cluster di storage. Analogamente agli PersistentVolumeClaim oggetti e PersistentVolume, quando viene creato uno snapshot, l' `VolumeSnapshotContent`oggetto mantiene una mappatura uno a uno all' `VolumeSnapshot`oggetto, che aveva richiesto la creazione dello snapshot.

L' VolumeSnapshotContent`oggetto contiene dettagli che identificano in modo univoco l'istantanea, ad esempio `snapshotHandle . Si tratta di snapshotHandle una combinazione univoca del nome del PV e del nome dell' `VolumeSnapshotContent`oggetto.

Quando arriva una richiesta di snapshot, Trident crea lo snapshot sul back-end. Dopo aver creato la snapshot, Trident configura un VolumeSnapshotContent oggetto ed espone quindi la snapshot nell'API Kubernetes.

Kubernetes Custom Resources sono endpoint dell'API Kubernetes definiti dall'amministratore e utilizzati per raggruppare oggetti simili. Kubernetes supporta la creazione di risorse personalizzate per l'archiviazione di un insieme di oggetti. È possibile ottenere queste definizioni delle risorse eseguendo kubectl get crds.

Le definizioni delle risorse personalizzate (CRD) e i relativi metadati degli oggetti associati vengono memorizzati da Kubernetes nel relativo archivio di metadati. Ciò elimina la necessità di un punto vendita separato per Trident.

Astra Trident utilizza CustomResourceDefinition gli oggetti per preservare l'identità degli oggetti Trident, come i backend Trident, le classi di storage Trident e i volumi Trident. Questi oggetti sono gestiti da Trident. Inoltre, il framework di snapshot dei volumi CSI introduce alcuni CRD necessari per definire le snapshot dei volumi.

I CRD sono un costrutto Kubernetes. Gli oggetti delle risorse sopra definite vengono creati da Trident. Come semplice esempio, quando un backend viene creato utilizzando tridentctl, un oggetto CRD corrispondente tridentbackends viene creato per essere utilizzato da Kubernetes.

Ecco alcuni punti da tenere a mente sui CRD di Trident:

Trident crea classi di storage corrispondenti per gli oggetti Kubernetes StorageClass che specificano csi.trident.netapp.io nel proprio campo di provisioner. Il nome della classe storage corrisponde a quello dell'oggetto Kubernetes StorageClass che rappresenta.

Le classi di storage comprendono un insieme di requisiti per i volumi. Trident abbina questi requisiti agli attributi presenti in ciascun pool di storage; se corrispondono, tale pool di storage è una destinazione valida per il provisioning dei volumi che utilizzano tale classe di storage.

È possibile creare configurazioni delle classi di storage per definire direttamente le classi di storage utilizzando l'API REST. Tuttavia, per le implementazioni Kubernetes, ci aspettiamo che vengano create quando si registrano nuovi oggetti Kubernetes StorageClass.

I backend rappresentano i provider di storage in cima ai quali Trident esegue il provisioning dei volumi; una singola istanza Trident può gestire qualsiasi numero di backend.

Per ulteriori informazioni su come costruire questi oggetti, fare riferimento a "configurazione dei backend".

I pool di storage rappresentano le diverse posizioni disponibili per il provisioning su ciascun backend. Per ONTAP, questi corrispondono agli aggregati nelle SVM. Per NetApp HCI/SolidFire, queste corrispondono alle bande QoS specificate dall'amministratore. Per Cloud Volumes Service, questi corrispondono alle regioni dei provider di cloud. Ogni pool di storage dispone di un insieme di attributi di storage distinti, che definiscono le caratteristiche di performance e di protezione dei dati.

A differenza degli altri oggetti qui presenti, i candidati del pool di storage vengono sempre rilevati e gestiti automaticamente.

I volumi sono l'unità di provisioning di base, che comprende endpoint back-end, come condivisioni NFS e LUN iSCSI. In Kubernetes, questi corrispondono direttamente a PersistentVolumes. Quando si crea un volume, assicurarsi che disponga di una classe di storage, che determini la destinazione del provisioning di quel volume, insieme a una dimensione.

Una configurazione del volume definisce le proprietà che un volume sottoposto a provisioning deve avere.

Trident genera internalName durante la creazione del volume. Si tratta di due fasi. Innanzitutto, il prefisso di archiviazione (predefinito o prefisso nella configurazione backend) viene preceduto trident dal nome del volume, dando come risultato un nome del form <prefix>-<volume-name>. Quindi, procede alla cancellazione del nome, sostituendo i caratteri non consentiti nel backend. Per i backend ONTAP, sostituisce i trattini con i caratteri di sottolineatura (quindi, il nome interno diventa <prefix>_<volume-name>). Per i backend degli elementi, sostituisce i caratteri di sottolineatura con trattini.

È possibile utilizzare configurazioni dei volumi per eseguire il provisioning diretto dei volumi utilizzando le API REST, ma nelle implementazioni Kubernetes ci aspettiamo che la maggior parte degli utenti utilizzi il metodo Kubernetes standard PersistentVolumeClaim. Trident crea automaticamente questo oggetto volume come parte del processo di provisioning.

Gli snapshot sono una copia point-in-time dei volumi, che può essere utilizzata per eseguire il provisioning di nuovi volumi o lo stato di ripristino. In Kubernetes, questi corrispondono direttamente agli VolumeSnapshotContent oggetti. Ogni snapshot è associato a un volume, che è l'origine dei dati per lo snapshot.

Ogni Snapshot oggetto include le proprietà elencate di seguito:

Quando viene creata una richiesta di oggetto Kubernetes VolumeSnapshot, Trident opera creando un oggetto Snapshot sul sistema storage di backup. Il internalName di questo oggetto snapshot viene generato combinando il prefisso snapshot- con il UID dell' VolumeSnapshot`oggetto (ad esempio, `snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660). volumeName e volumeInternalName vengono compilati ottenendo i dettagli del volume di backup.

Il deamonset Trident consuma una system-node-critical classe di priorità, la classe di priorità più elevata disponibile in Kubernetes, per garantire che Astra Trident possa identificare e ripulire i volumi in fase di shutdown anomalo del nodo e consentire ai pod di daemonset Trident di prevenire i carichi di lavoro con una priorità più bassa nei cluster in cui c'è una pressione elevata delle risorse.

A tale scopo, Astra Trident utilizza un ResourceQuota oggetto per garantire che sia soddisfatta una classe di priorità "system-node-critical" sul daemonset Trident. Prima della distribuzione e della creazione di daemonset, Astra Trident cerca l' `ResourceQuota`oggetto e, se non viene rilevato, lo applica.

Se è necessario un maggiore controllo sulla quota di risorse e sulla classe di priorità predefinite, è possibile generare un custom.yaml oggetto o configurarlo ResourceQuota utilizzando il grafico Helm.

Di seguito viene riportato un esempio di oggetto `ResourceQuota`che dà priorità al demonset Trident.

Per ulteriori informazioni sulle quote di risorse, fare riferimento a "Kubernetes: Quote delle risorse".