Forse il modo più semplice per capire gli oggetti, a cosa servono e come interagiscono, è seguire una singola richiesta di storage da parte di un utente Kubernetes:

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

Oltre alle specifiche standard, Trident consente agli utenti di specificare le seguenti annotazioni specifiche per i volumi se desiderano sovrascrivere i valori predefiniti che hai impostato nella configurazione del backend:

Se il PV creato ha la Delete reclaim policy, Trident elimina sia il PV che il backing volume quando il PV viene rilasciato (cioè quando l'utente elimina il PVC). Se l'azione di eliminazione non riesce, Trident contrassegna il PV come tale e ritenta periodicamente l'operazione finché non ha successo o il PV viene eliminato manualmente. Se il PV utilizza la Retain policy, Trident lo ignora e presume che l'amministratore lo rimuova da Kubernetes e dal backend, consentendo il backup o l'ispezione del volume prima della sua rimozione. Si noti che l'eliminazione del PV non causa a Trident di eliminare il backing volume. Dovresti rimuoverlo utilizzando la REST API (tridentctl).

Trident supporta la creazione di Volume Snapshot utilizzando la specifica CSI: è possibile creare una Volume Snapshot e utilizzarla come Data Source per clonare i PVC esistenti. In questo modo, copie point-in-time dei PV possono essere esposte a Kubernetes sotto forma di snapshot. Le snapshot possono quindi essere utilizzate per creare nuovi PV. Dai un'occhiata a On-Demand Volume Snapshots per vedere come funzionerebbe.

Trident fornisce anche le cloneFromPVC e splitOnClone annotazioni per la creazione di cloni. Puoi 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 questa annotazione impostata, Trident clona il volume corrispondente al PVC mysql, invece di eseguire il provisioning di un volume da zero.

Considera i seguenti punti:

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

Un oggetto Kubernetes PersistentVolume rappresenta un pezzo di storage messo a disposizione del cluster Kubernetes. Ha un ciclo di vita indipendente dal pod che lo utilizza.

Quando si crea un PVC che fa riferimento a un sistema basato su Trident StorageClass, Trident esegue il provisioning di un nuovo volume utilizzando la corrispondente storage class e registra un nuovo PV per quel volume. Nel configurare il volume fornito e il PV corrispondente, Trident segue le seguenti regole:

Gli oggetti Kubernetes StorageClass sono specificati per nome in PersistentVolumeClaims per fornire storage con un insieme di proprietà. La storage class stessa identifica il provisioner da utilizzare e definisce quell'insieme di proprietà in termini che il provisioner comprende.

È 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 appare così:

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

I parametri della storage class sono:

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

Gli oggetti di Kubernetes VolumeSnapshotClass sono analoghi a StorageClasses. Aiutano a definire più classi di storage e sono referenziati dalle istantanee di volume per associare l'istantanea alla classe di istantanea richiesta. Ogni istantanea di volume è associata a una singola classe di istantanea di volume.

Un VolumeSnapshotClass dovrebbe essere definito da un amministratore per creare le istantanee. Una classe di istantanee di volume viene creata con la seguente definizione:

Il driver specifica a Kubernetes che le richieste di snapshot di volume della classe csi-snapclass sono gestite da Trident. Il deletionPolicy specifica l'azione da intraprendere quando uno snapshot deve essere eliminato. Quando deletionPolicy è impostato su Delete, gli oggetti snapshot del volume così come lo snapshot sottostante sul cluster di storage vengono rimossi quando uno snapshot viene eliminato. In alternativa, impostandolo su Retain significa che VolumeSnapshotContent e lo snapshot fisico vengono mantenuti.

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

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

Un oggetto Kubernetes VolumeSnapshotContent rappresenta una snapshot presa da un volume già fornito. È analogo a PersistentVolume e indica una snapshot fornita sul cluster di storage. Analogamente a PersistentVolumeClaim e PersistentVolume oggetti, quando viene creata una snapshot, l'oggetto VolumeSnapshotContent mantiene una mappatura uno-a-uno con l'oggetto VolumeSnapshot che ha richiesto la creazione della snapshot.

L' VolumeSnapshotContent`oggetto contiene dettagli che identificano in modo univoco la snapshot, come il `snapshotHandle. Questo 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 backend. Dopo che lo snapshot è stato creato, Trident configura un VolumeSnapshotContent oggetto e quindi espone lo snapshot all'API di Kubernetes.

Gli oggetti di Kubernetes VolumeGroupSnapshotClass sono analoghi a VolumeSnapshotClass. Aiutano a definire più classi di storage e sono referenziati dalle snapshot del gruppo di volumi per associare la snapshot alla classe di snapshot richiesta. Ogni snapshot del gruppo di volumi è associata a una singola classe di snapshot del gruppo di volumi.

A VolumeGroupSnapshotClass deve essere definito da un amministratore per creare un gruppo di snapshot. Una classe di snapshot di gruppo di volumi viene creata con la seguente definizione:

Il driver specifica a Kubernetes che le richieste di snapshot di gruppo di volumi della csi-group-snap-class classe sono gestite da Trident. Il deletionPolicy specifica l'azione da intraprendere quando una snapshot di gruppo deve essere eliminata. Quando deletionPolicy è impostato su Delete, gli oggetti snapshot del gruppo di volumi e lo snapshot sottostante sul cluster di storage vengono rimossi quando uno snapshot viene eliminato. In alternativa, impostandolo su Retain significa che VolumeGroupSnapshotContent e lo snapshot fisico vengono mantenuti.

Un oggetto Kubernetes VolumeGroupSnapshot è una richiesta di creazione di un'istantanea di più volumi. Così come un PVC rappresenta una richiesta fatta da un utente per un volume, un'istantanea di gruppo di volumi è una richiesta fatta da un utente per creare un'istantanea di un PVC esistente.

Quando arriva una richiesta di snapshot di un gruppo di volumi, Trident gestisce automaticamente la creazione dello snapshot di gruppo per i volumi sul backend ed espone lo snapshot creando un oggetto VolumeGroupSnapshotContent unico. Puoi creare snapshot da PVC esistenti e utilizzare gli snapshot come DataSource quando crei nuovi PVC.

Un oggetto Kubernetes VolumeGroupSnapshotContent rappresenta una snapshot di gruppo presa da un volume già fornito. È analogo a PersistentVolume e indica una snapshot fornita sul cluster di storage. Analogamente a PersistentVolumeClaim e PersistentVolume oggetti, quando viene creata una snapshot, l'oggetto VolumeSnapshotContent mantiene una mappatura uno-a-uno con l'oggetto VolumeSnapshot che ha richiesto la creazione della snapshot.

L' VolumeGroupSnapshotContent`oggetto contiene dettagli che identificano il gruppo di snapshot, come il `volumeGroupSnapshotHandle e i singoli volumeSnapshotHandles esistenti sul sistema storage.

Quando arriva una richiesta di snapshot, Trident crea lo snapshot del gruppo di volumi sul backend. Dopo la creazione dello snapshot del gruppo di volumi, Trident configura un VolumeGroupSnapshotContent oggetto e quindi espone lo snapshot all'API di Kubernetes.

Le risorse personalizzate di Kubernetes sono endpoint dell'API di Kubernetes definiti dall'amministratore e utilizzati per raggruppare oggetti simili. Kubernetes supporta la creazione di risorse personalizzate per la memorizzazione di una raccolta di oggetti. Puoi ottenere queste definizioni di risorse eseguendo kubectl get crds.

Le Custom Resource Definitions (CRDs) e i relativi metadati degli oggetti sono memorizzati da Kubernetes nel suo archivio dei metadati. Questo elimina la necessità di uno store separato per Trident.

Trident utilizza CustomResourceDefinition 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 CSI per le snapshot di volume introduce alcune CRD necessarie per definire le snapshot di volume.

I CRD sono un costrutto di Kubernetes. Gli oggetti delle risorse definite sopra sono creati da Trident. Come semplice esempio, quando un backend viene creato usando tridentctl, viene creato un oggetto CRD corrispondente tridentbackends per il consumo da parte di Kubernetes.

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

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

Le classi di archiviazione comprendono una serie di requisiti per i volumi. Trident confronta questi requisiti con gli attributi presenti in ogni pool di storage; se corrispondono, quel pool di storage è un target valido per il provisioning dei volumi che utilizzano quella classe di archiviazione.

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

I backend rappresentano i provider di storage su cui Trident effettua il provisioning dei volumi; una singola istanza di Trident può gestire qualsiasi numero di backend.

Per ulteriori informazioni su come costruire questi oggetti, consultare "configurazione dei backend".

I pool di storage rappresentano le posizioni distinte disponibili per il provisioning su ciascun backend. Per ONTAP, questi corrispondono ad aggregati nelle SVM. Per NetApp HCI/SolidFire, questi corrispondono a bande QoS specificate dall'amministratore. Ogni pool di storage ha una serie di attributi di storage distinti, che definiscono le sue caratteristiche di prestazioni e di protezione dei dati.

A differenza degli altri oggetti qui, i candidati del pool di storage sono sempre scoperti e gestiti automaticamente.

I volumi sono l'unità di base del provisioning, comprendendo endpoint di backend, come condivisioni NFS e LUN iSCSI e FC. In Kubernetes, questi corrispondono direttamente a PersistentVolumes. Quando si crea un volume, assicurarsi che abbia una storage class, che determina dove quel volume può essere fornito, insieme a una dimensione.

Una configurazione di volume definisce le proprietà che un volume provisionato deve avere.

Trident genera internalName quando crea il volume. Questo consiste in due passaggi. Innanzitutto, antepone il prefisso di storage (il prefisso predefinito trident o il prefisso nella configurazione del backend) al nome del volume, ottenendo un nome della forma <prefix>-<volume-name>. Quindi procede a sanificare il nome, sostituendo i caratteri non consentiti nel backend. Per i backend ONTAP, sostituisce i trattini con i trattini bassi (quindi il nome interno diventa <prefix>_<volume-name>). Per i backend Element, sostituisce i trattini bassi con i trattini.

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

Le Snapshot sono una copia point-in-time dei volumi, che può essere utilizzata per il provisioning di nuovi volumi o per il ripristino dello stato. In Kubernetes, queste corrispondono direttamente a VolumeSnapshotContent oggetti. Ogni Snapshot è associata a un volume, che è la fonte dei dati per la Snapshot.

Ogni Snapshot oggetto include le proprietà elencate di seguito:

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

Il deamonset Trident consuma una system-node-critical Priority Class—​la Priority Class più alta disponibile in Kubernetes—​per garantire che Trident possa identificare e ripulire i volumi durante lo spegnimento controllato dei nodi e consentire ai pod del deamonset Trident di prevaricare i carichi di lavoro con una priorità inferiore nei cluster in cui vi è un'elevata pressione sulle risorse.

A tal fine, Trident impiega un ResourceQuota oggetto per garantire che la Priority Class "system-node-critical" sul daemonset Trident sia soddisfatta. Prima della distribuzione e della creazione del daemonset, Trident cerca il ResourceQuota oggetto e, se non viene trovato, lo applica.

Se hai bisogno di un maggiore controllo sulla Resource Quota e sulla Priority Class predefinite, puoi generare un custom.yaml o configurare l'oggetto ResourceQuota utilizzando l'Helm chart.

Quello che segue è un esempio di un oggetto ResourceQuota che dà priorità al daemonset Trident.

Per ulteriori informazioni sulle Resource Quotas, consultare "Kubernetes: Quote di risorse".