Quizás la forma más sencilla de comprender los objetos, qué hacen y cómo interactúan sea, es seguir una única solicitud de almacenamiento a un usuario de Kubernetes:

Un Kubernetes PersistentVolumeClaim El objeto es una solicitud de almacenamiento que realiza un usuario de clúster de Kubernetes.

Además de la especificación estándar, Trident permite a los usuarios especificar las siguientes anotaciones específicas del volumen si desean anular los valores predeterminados que se establecen en la configuración de back-end:

Si el VP creado tiene el Delete Reclamar política, Trident elimina el VP y el volumen de respaldo cuando se libera el VP (es decir, cuando el usuario elimina la RVP). Si la acción de eliminación falla, Trident Marca el VP como tal y reintenta periódicamente la operación hasta que esta se complete o se elimine manualmente el VP. Si el VP utiliza Retain Política, Trident ignora la operación y asume que el administrador la limpiará desde Kubernetes y el back-end, lo que permitirá realizar un backup o la inspección del volumen antes de su eliminación. Tenga en cuenta que al eliminar el VP, Trident no eliminará el volumen de backup. Debe quitarlo usando la API DE REST (tridentctl).

Trident admite la creación de instantáneas de volumen utilizando la especificación CSI: Puede crear una instantánea de volumen y utilizarla como origen de datos para clonar las RVP existentes. De este modo, las copias puntuales de VP pueden exponerse a Kubernetes en forma de snapshots. Las instantáneas pueden utilizarse para crear nuevos VP. Eche un vistazo On-Demand Volume Snapshots para ver cómo funcionaría.

Trident también proporciona la cloneFromPVC y.. splitOnClone anotaciones para crear clones. Puede utilizar estas anotaciones para clonar un PVC sin tener que utilizar la implementación de CSI (en Kubernetes 1.13 y versiones anteriores) o si su versión de Kubernetes no es compatible con las copias Snapshot de volumen beta (Kubernetes 1.16 y versiones anteriores). Tenga en cuenta que Trident 19.10 admite el flujo de trabajo CSI para clonar desde un PVC.

A continuación se muestra un ejemplo: Si un usuario ya tiene una RVP llamada mysql, El usuario puede crear un nuevo PVC llamado mysqlclone mediante la anotación, por ejemplo trident.netapp.io/cloneFromPVC: mysql. Con este conjunto de anotaciones, Trident clona el volumen correspondiente a la RVP de mysql, en lugar de aprovisionar un volumen desde cero.

Considere los siguientes puntos:

La sample-input el directorio contiene ejemplos de definiciones de PVC para utilizarlas con Trident. Consulte los objetos de Trident Volume para obtener una descripción completa de los parámetros y la configuración asociados con Trident Volumes.

Un Kubernetes PersistentVolume Object representa un fragmento de almacenamiento que se pone a disposición del clúster de Kubernetes. Tiene un ciclo de vida independiente del pod que lo utiliza.

Cuando se crea una RVP que hace referencia a un sistema basado en Trident StorageClass, Trident aprovisiona un nuevo volumen utilizando la clase de almacenamiento correspondiente y registra un nuevo VP para ese volumen. Al configurar el volumen aprovisionado y el VP correspondiente, Trident sigue las siguientes reglas:

Kubernetes StorageClass los objetos se especifican por nombre en PersistentVolumeClaims para aprovisionar el almacenamiento con una serie de propiedades. La clase de almacenamiento identifica el aprovisionador que se usará y define ese conjunto de propiedades en términos que entiende el aprovisionador.

Es uno de los dos objetos básicos que el administrador debe crear y gestionar. El otro es el objeto back-end de Trident.

Un Kubernetes StorageClass Objeto que usa Trident tiene el siguiente aspecto:

Estos parámetros son específicos de Trident y dicen a Trident cómo aprovisionar volúmenes para la clase.

Los parámetros de la clase de almacenamiento son:

Los atributos de almacenamiento y sus posibles valores se pueden clasificar en atributos de selección de pools de almacenamiento y atributos de Kubernetes.

Kubernetes VolumeSnapshotClass los objetos son similares StorageClasses. Ayudan a definir varias clases de almacenamiento y las instantáneas de volumen hacen referencia a ellas para asociar la snapshot a la clase de snapshot necesaria. Cada copia de Snapshot de volumen se asocia con una sola clase de copia de Snapshot de volumen.

La driver Especifica a Kubernetes que solicitudes de snapshots de volumen del csi-snapclass Trident gestiona la clase. La deletionPolicy especifica la acción que se debe realizar cuando se debe eliminar una instantánea. Cuando deletionPolicy se establece en Delete, los objetos de instantánea del volumen, así como la instantánea subyacente en el clúster de almacenamiento, se eliminan cuando se elimina una instantánea. Como alternativa, establecerlo en Retain significa eso VolumeSnapshotContent y se conserva la snapshot física.

Un Kubernetes VolumeSnapshot objeto es una solicitud para crear una copia de snapshot de un volumen. Del mismo modo que la RVP representa una solicitud al usuario para un volumen, un snapshot de volumen es una solicitud al que hace un usuario para crear una copia Snapshot de una RVP existente.

Cuando llega una solicitud Snapshot de volumen, Trident gestiona automáticamente la creación de la snapshot para el volumen en el back-end y expone la snapshot creando un único
VolumeSnapshotContent objeto. Puede crear instantáneas a partir de EVs existentes y utilizar las instantáneas como DataSource al crear nuevas CVP.

Un Kubernetes VolumeSnapshotContent object representa una snapshot tomada de un volumen ya aprovisionado. Es similar a un PersistentVolume y significa una instantánea aprovisionada en el clúster de almacenamiento. Similar a. PersistentVolumeClaim y.. PersistentVolume los objetos, cuando se crea una snapshot, el VolumeSnapshotContent object mantiene una asignación de uno a uno VolumeSnapshot objeto, que solicitó la creación de la snapshot.

La VolumeSnapshotContent el objeto contiene detalles que identifican de manera única la instantánea, como la snapshotHandle. Este snapshotHandle Es una combinación única del nombre del PV y el nombre del VolumeSnapshotContent objeto.

Cuando llega una solicitud de Snapshot, Trident crea la snapshot en el back-end. Una vez creada la copia de Snapshot, Trident configura un VolumeSnapshotContent Objeto y, por lo tanto, expone la snapshot a la API de Kubernetes.

Los recursos personalizados de Kubernetes son extremos en la API de Kubernetes que define el administrador y que se usan para agrupar objetos similares. Kubernetes admite la creación de recursos personalizados para almacenar un conjunto de objetos. Puede obtener estas definiciones de recursos ejecutando kubectl get crds.

Kubernetes almacena en su almacén de metadatos las definiciones de recursos personalizadas (CRD) y los metadatos de objetos asociados. De este modo, no es necesario disponer de un almacén aparte para Trident.

A partir del lanzamiento de la versión 19.07, Trident utiliza una serie de CustomResourceDefinition Objetos que conservan la identidad de objetos de Trident, como los back-ends de Trident, las clases de almacenamiento de Trident y los volúmenes de Trident. Trident gestiona estos objetos. Además, el marco de instantáneas de volumen CSI introduce algunos CRD necesarios para definir instantáneas de volumen.

Los multos son una estructura de Kubernetes. Trident crea los objetos de los recursos definidos anteriormente. Como ejemplo simple, cuando se crea un back-end usando tridentctl, a correspondiente tridentbackends El objeto CRD se crea para el consumo por parte de Kubernetes.

A continuación se indican algunos puntos que hay que tener en cuenta sobre los CRD de Trident:

Trident crea clases de almacenamiento coincidentes para Kubernetes StorageClass objetos que especifican csi.trident.netapp.io/netapp.io/trident en su campo de aprovisionamiento. El nombre de la clase de almacenamiento coincide con el de Kubernetes StorageClass objeto que representa.

Las clases de almacenamiento comprenden un conjunto de requisitos para los volúmenes. Trident enlaza estos requisitos con los atributos presentes en cada pool de almacenamiento; si coinciden, ese pool de almacenamiento es un objetivo válido para aprovisionar volúmenes que utilizan esa clase de almacenamiento.

Puede crear configuraciones de clase de almacenamiento para definir clases de almacenamiento directamente mediante la API DE REST. Sin embargo, en el caso de las puestas en marcha de Kubernetes, esperamos que se creen al registrar el nuevo Kubernetes StorageClass objetos.

Los back-ends representan a los proveedores de almacenamiento, además de los cuales Trident aprovisiona volúmenes; una única instancia de Trident puede gestionar cualquier número de back-ends.

Para obtener más información acerca de cómo construir estos objetos, consulte "configuración de los back-ends".

Los pools de almacenamiento representan las distintas ubicaciones disponibles para aprovisionar en cada back-end. Para ONTAP, corresponden a los agregados en las SVM. Para HCI/SolidFire de NetApp, corresponden a las bandas de calidad de servicio especificadas por el administrador. Para Cloud Volumes Service, se corresponden con las regiones de proveedores de cloud. Cada pool de almacenamiento tiene un conjunto de atributos de almacenamiento distintos que definen sus características de rendimiento y sus características de protección de datos.

Al contrario de lo que ocurre con otros objetos aquí, los candidatos de pools de almacenamiento siempre se detectan y gestionan automáticamente.

Los volúmenes son la unidad básica de aprovisionamiento y constan de extremos back-end, como recursos compartidos de NFS y LUN iSCSI. En Kubernetes, se corresponden directamente con PersistentVolumes. Cuando crea un volumen, asegúrese de que tiene una clase de almacenamiento, que determina dónde se puede aprovisionar ese volumen junto con un tamaño.

Una configuración de volumen define las propiedades que debe tener un volumen aprovisionado.

Genera Trident internalName al crear el volumen. Esto consta de dos pasos. En primer lugar, prepens el prefijo de almacenamiento (ya sea el predeterminado) trident o el prefijo de la configuración del back-end) al nombre del volumen, lo que genera el nombre del formulario <prefix>-<volume-name>. A continuación, procede a desinfectar el nombre y a reemplazar los caracteres no permitidos en el backend. En los back-ends de ONTAP, reemplaza guiones con guiones bajos (de esta forma, el nombre interno se convierte en <prefix>_<volume-name>). En los back-ends de Element, reemplaza guiones bajos por guiones.

Puede utilizar configuraciones de volumen para aprovisionar directamente los volúmenes mediante la API REST, pero en las puestas en marcha de Kubernetes esperamos que la mayoría de los usuarios usen el Kubernetes estándar PersistentVolumeClaim método. Trident crea este objeto de volumen automáticamente como parte del proceso de aprovisionamiento.

Las Snapshot son una copia de un momento específico de los volúmenes, que se pueden usar para aprovisionar nuevos volúmenes o restaurar el estado. En Kubernetes, se corresponden directamente con VolumeSnapshotContent objetos. Cada copia de Snapshot se asocia con un volumen, que es el origen de los datos de la copia de Snapshot.

Cada uno Snapshot object incluye las propiedades que se enumeran a continuación:

Cuando un Kubernetes VolumeSnapshot Se crea la solicitud del objeto, Trident funciona mediante la creación de un objeto Snapshot en el sistema de almacenamiento que realiza backups. La internalName de este objeto snapshot se genera combinando el prefijo snapshot- con la UID de la VolumeSnapshot objeto (por ejemplo, snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660). volumeName y.. volumeInternalName para rellenar, obtendrá los detalles del volumen de backup.

El inicio de Trident consume un system-node-critical Clase de prioridad, la clase de prioridad más alta disponible en Kubernetes, para garantizar que Astra Trident pueda identificar y limpiar volúmenes durante un apagado correcto de nodos y permitir que Trident demonset pods prevea las cargas de trabajo con una prioridad menor en clústeres donde hay una alta presión en los recursos.

Para conseguirlo, Astra Trident utiliza una ResourceQuota Objeto garantizar que se cumple una clase prioritaria "system-node-Critical" en el demonset de Trident. Antes de la puesta en marcha y la creación de demonset, Astra Trident busca la ResourceQuota object y, si no se detecta, lo aplica.

Si necesita más control sobre la cuota de recursos predeterminada y la clase de prioridad, puede generar una custom.yaml o configure el ResourceQuota Objeto mediante el gráfico Helm.

A continuación se muestra un ejemplo de un objeto "ResourceQuota'object que da prioridad al demonset de Trident.

Para obtener más información acerca de las cuotas de recursos, consulte "Kubernetes: Cuotas de recursos".