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

Un Kubernetes PersistentVolumeClaim L'oggetto è una richiesta di archiviazione effettuata da un utente del cluster Kubernetes.

Oltre alle specifiche standard, Trident consente agli utenti di specificare le seguenti annotazioni specifiche del volume se desiderano sovrascrivere le impostazioni predefinite impostate nella configurazione del backend:

Se il PV creato ha il Delete politica di recupero, Trident elimina sia il PV che il volume di supporto quando il PV viene rilasciato (ovvero quando l'utente elimina il PVC). Se l'operazione di eliminazione fallisce, Trident contrassegna il PV come tale e riprova periodicamente finché non riesce o finché il PV non viene eliminato manualmente. Se il PV utilizza il Retain policy, Trident la ignora e presume che l'amministratore la ripulirà 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 comporta l'eliminazione del volume di supporto Trident . Dovresti rimuoverlo usando l'API REST(tridentctl ).

Trident supporta la creazione di snapshot del volume utilizzando la specifica CSI: è possibile creare uno snapshot del volume e utilizzarlo come origine dati per clonare PVC esistenti. In questo modo, le copie point-in-time dei PV possono essere esposte a Kubernetes sotto forma di snapshot. Gli snapshot possono quindi essere utilizzati per creare nuovi PV. Dai un'occhiata a On-Demand Volume Snapshots per vedere come funzionerebbe.

Trident fornisce anche il cloneFromPVC E splitOnClone annotazioni per la creazione di cloni. È possibile utilizzare queste annotazioni per clonare un PVC senza dover ricorrere all'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 ad esempio trident.netapp.io/cloneFromPVC: mysql . Con questo set di annotazioni, Trident clona il volume corrispondente al PVC mysql, anziché effettuare il provisioning di un volume da zero.

Considera i seguenti punti:

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

Un Kubernetes PersistentVolume L'oggetto rappresenta un elemento di storage reso disponibile al cluster Kubernetes. Ha un ciclo di vita indipendente dal pod che lo utilizza.

Quando si crea un PVC che fa riferimento a un Trident-based StorageClass Trident predispone un nuovo volume utilizzando la classe di archiviazione corrispondente e registra un nuovo PV per tale volume. Nella configurazione del volume fornito e del PV corrispondente, Trident segue le seguenti regole:

Kubernetes StorageClass gli oggetti sono specificati per nome in PersistentVolumeClaims per fornire storage con un set di proprietà. La classe di archiviazione stessa identifica il provisioner da utilizzare e definisce il set di proprietà in termini comprensibili al provisioner.

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

Un Kubernetes StorageClass L'oggetto che utilizza Trident si presenta così:

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

I parametri della classe di archiviazione sono:

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

Kubernetes VolumeSnapshotClass gli oggetti sono analoghi a StorageClasses . Consentono di definire più classi di archiviazione e sono referenziati dagli snapshot del volume per associare lo snapshot alla classe di snapshot richiesta. Ogni snapshot del volume è associato a una singola classe di snapshot del volume.

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

IL driver specifica a Kubernetes che le richieste per gli snapshot del volume di csi-snapclass la classe è gestita da Trident. IL deletionPolicy specifica l'azione da intraprendere quando è necessario eliminare uno snapshot. Quando deletionPolicy è impostato su Delete , gli oggetti snapshot del volume e lo snapshot sottostante sul cluster di archiviazione vengono rimossi quando uno snapshot viene eliminato. In alternativa, impostandolo su Retain significa che VolumeSnapshotContent e l'istantanea fisica vengono mantenute.

Un Kubernetes VolumeSnapshot object è una richiesta per creare uno snapshot di un volume. Proprio come un PVC rappresenta una richiesta effettuata da un utente per un volume, uno snapshot del volume è una richiesta effettuata da un utente per creare uno 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'immagine univoca
VolumeSnapshotContent oggetto. È possibile creare snapshot da PVC esistenti e utilizzarli come DataSource durante la creazione di nuovi PVC.

Un Kubernetes VolumeSnapshotContent L'oggetto rappresenta uno snapshot preso da un volume già sottoposto a provisioning. È analogo a un PersistentVolume e indica uno snapshot fornito sul cluster di archiviazione. Simile a PersistentVolumeClaim E PersistentVolume oggetti, quando viene creato uno snapshot, il VolumeSnapshotContent l'oggetto mantiene una mappatura uno a uno con VolumeSnapshot oggetto che aveva richiesto la creazione dello snapshot.

IL VolumeSnapshotContent l'oggetto contiene dettagli che identificano in modo univoco lo snapshot, come ad esempio snapshotHandle . Questo snapshotHandle è una combinazione unica del nome del PV e del nome del VolumeSnapshotContent oggetto.

Quando arriva una richiesta di snapshot, Trident crea lo snapshot nel backend. Dopo aver creato lo snapshot, Trident configura un VolumeSnapshotContent oggetto e quindi espone lo snapshot all'API Kubernetes.

Kubernetes VolumeGroupSnapshotClass gli oggetti sono analoghi a VolumeSnapshotClass . Consentono di definire più classi di archiviazione e sono referenziati dagli snapshot del gruppo di volumi per associare lo snapshot alla classe di snapshot richiesta. Ogni snapshot del gruppo di volumi è associato a una singola classe di snapshot del gruppo di volumi.

UN VolumeGroupSnapshotClass dovrebbe essere definito da un amministratore per creare un gruppo di snapshot. Viene creata una classe snapshot del gruppo di volumi con la seguente definizione:

IL driver specifica a Kubernetes che le richieste per gli snapshot del gruppo di volumi del csi-group-snap-class la classe è gestita da Trident. IL deletionPolicy specifica l'azione da intraprendere quando è necessario eliminare uno snapshot di gruppo. Quando deletionPolicy è impostato su Delete , gli oggetti snapshot del gruppo di volumi e lo snapshot sottostante sul cluster di archiviazione vengono rimossi quando uno snapshot viene eliminato. In alternativa, impostandolo su Retain significa che VolumeGroupSnapshotContent e l'istantanea fisica vengono mantenute.

Un Kubernetes VolumeGroupSnapshot object è una richiesta per creare uno snapshot di più volumi. Proprio come un PVC rappresenta una richiesta effettuata da un utente per un volume, uno snapshot del gruppo di volumi è una richiesta effettuata da un utente per creare uno snapshot di un PVC esistente.

Quando arriva una richiesta di snapshot del gruppo di volumi, Trident gestisce automaticamente la creazione dello snapshot del gruppo per i volumi sul backend ed espone lo snapshot creando un'immagine univoca VolumeGroupSnapshotContent oggetto. È possibile creare snapshot da PVC esistenti e utilizzarli come DataSource durante la creazione di nuovi PVC.

Un Kubernetes VolumeGroupSnapshotContent L'oggetto rappresenta uno snapshot di gruppo preso da un volume già sottoposto a provisioning. È analogo a un PersistentVolume e indica uno snapshot fornito sul cluster di archiviazione. Simile a PersistentVolumeClaim E PersistentVolume oggetti, quando viene creato uno snapshot, il VolumeSnapshotContent l'oggetto mantiene una mappatura uno a uno con VolumeSnapshot oggetto che aveva richiesto la creazione dello snapshot.

IL VolumeGroupSnapshotContent l'oggetto contiene dettagli che identificano il gruppo di snapshot, come ad esempio volumeGroupSnapshotHandle e singoli volumiSnapshotHandles esistenti sul sistema di archiviazione.

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

Le risorse personalizzate di Kubernetes sono endpoint nell'API di Kubernetes definiti dall'amministratore e utilizzati per raggruppare oggetti simili. Kubernetes supporta la creazione di risorse personalizzate per l'archiviazione di una raccolta di oggetti. È possibile ottenere queste definizioni di risorse eseguendo kubectl get crds .

Le definizioni di risorse personalizzate (CRD) e i metadati degli oggetti associati vengono archiviati da Kubernetes nel suo archivio metadati. In questo modo si elimina la necessità di un archivio separato per Trident.

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

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

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

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

Le classi di archiviazione comprendono un insieme di requisiti per i volumi. Trident confronta questi requisiti con gli attributi presenti in ciascun pool di archiviazione; se corrispondono, quel pool di archiviazione è una destinazione valida per il provisioning dei volumi utilizzando quella classe di archiviazione.

È possibile creare configurazioni di classi di archiviazione per definire direttamente le classi di archiviazione utilizzando l'API REST. Tuttavia, per le distribuzioni Kubernetes, ci aspettiamo che vengano create durante la registrazione di nuovi Kubernetes StorageClass oggetti.

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

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

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

A differenza degli altri oggetti qui, i candidati al pool di archiviazione vengono sempre rilevati e gestiti automaticamente.

I volumi sono l'unità di base del provisioning e comprendono endpoint back-end, come condivisioni NFS e LUN iSCSI e FC. In Kubernetes, questi corrispondono direttamente a PersistentVolumes . Quando si crea un volume, assicurarsi che disponga di una classe di archiviazione, che determina dove può essere eseguito il provisioning del volume, insieme a una dimensione.

Una configurazione del volume definisce le proprietà che un volume fornito dovrebbe avere.

Trident genera internalName durante la creazione del volume. Si compone di due fasi. Innanzitutto, antepone il prefisso di archiviazione (predefinito trident o il prefisso nella configurazione del backend) al nome del volume, risultando in un nome del tipo <prefix>-<volume-name> . Procede quindi a ripulire il 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 Element, sostituisce i trattini bassi con i trattini.

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

Gli snapshot sono copie di volumi effettuate in un dato momento, che possono essere utilizzate per predisporre nuovi volumi o ripristinarne lo stato. In Kubernetes, questi corrispondono direttamente a VolumeSnapshotContent oggetti. Ogni snapshot è associato a un volume, che è l'origine dei dati per lo snapshot.

Ogni Snapshot l'oggetto include le proprietà elencate di seguito:

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

Il set di demoni Trident consuma un system-node-critical Classe di priorità: la classe di priorità più elevata disponibile in Kubernetes, per garantire che Trident possa identificare e ripulire i volumi durante l'arresto regolare dei nodi e consentire ai pod daemonset Trident di anticipare i carichi di lavoro con una priorità inferiore nei cluster in cui vi è un'elevata pressione sulle risorse.

Per raggiungere questo obiettivo, Trident impiega un ResourceQuota oggetto per garantire che venga soddisfatta una classe di priorità "system-node-critical" sul daemonset Trident . Prima della distribuzione e della creazione del daemonset, Trident cerca ResourceQuota oggetto e, se non viene scoperto, lo applica.

Se hai bisogno di un maggiore controllo sulla quota di risorse predefinita e sulla classe di priorità, puoi generare un custom.yaml o configurare il ResourceQuota oggetto utilizzando il grafico Helm.

Di seguito è riportato un esempio di un oggetto ResourceQuota che assegna la priorità al daemonset Trident .

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