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 objeto de Kubernetes PersistentVolumeClaim es una solicitud de almacenamiento que realiza un usuario del 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 la Delete política de reclamaciones, 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 usa la Retain política, Trident la ignora y asume que el administrador la limpiará de Kubernetes y del back-end para permitir que se haga un backup del volumen o se inspeccione antes de su eliminación. Tenga en cuenta que al eliminar el VP, Trident no eliminará el volumen de backup. Se debe quitar mediante 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. Echa un vistazo On-Demand Volume Snapshots para ver cómo funcionaría esto.

Trident también proporciona cloneFromPVC las anotaciones y splitOnClone para crear clones. Puede utilizar estas anotaciones para clonar una RVP sin tener que utilizar la implementación de CSI.

Aquí hay un ejemplo: Si un usuario ya tiene un PVC llamado mysql, el usuario puede crear un nuevo PVC llamado mysqlclone mediante la anotación, como 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:

Un objeto de Kubernetes PersistentVolume representa una pieza 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 crea una RVP que hace referencia a una Trident StorageClass , Trident aprovisiona un nuevo volumen con 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:

Los objetos de Kubernetes StorageClass se especifican por nombre en PersistentVolumeClaims para aprovisionar el almacenamiento con un conjunto 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 objeto de Kubernetes StorageClass 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.

Los objetos de Kubernetes VolumeSnapshotClass son análogos a 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.

Un administrador debe definir a VolumeSnapshotClass para crear instantáneas. Una clase de snapshot de volumen se crea con la siguiente definición:

El driver especifica a Kubernetes que Trident gestiona las solicitudes de instantáneas de volumen de csi-snapclass la clase. El deletionPolicy especifica la acción que se debe realizar cuando se debe eliminar una instantánea. deletionPolicy`Cuando se establece en `Delete, los objetos Snapshot del volumen, así como la snapshot subyacente en el clúster de almacenamiento, se eliminan cuando se elimina una snapshot. Como alternativa, si se configura en Retain, VolumeSnapshotContent se conservan la instantánea física y la física.

Un objeto de Kubernetes VolumeSnapshot es una solicitud para crear una 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 se recibe una solicitud de copia de Snapshot de volumen, Trident gestiona automáticamente la creación de la copia de Snapshot para el volumen en el back-end y expone la copia de Snapshot mediante la creación de un objeto único
VolumeSnapshotContent. Puede crear instantáneas a partir de EVs existentes y utilizar las instantáneas como DataSource al crear nuevas CVP.

Un objeto de Kubernetes VolumeSnapshotContent representa una snapshot tomada de un volumen ya aprovisionado. Es análogo a A PersistentVolume y significa una snapshot aprovisionada en el clúster de almacenamiento. Al igual que PersistentVolumeClaim y PersistentVolume objetos, cuando se crea una snapshot, VolumeSnapshotContent el objeto mantiene una asignación uno a uno con el VolumeSnapshot objeto, que había solicitado la creación de la snapshot.

El VolumeSnapshotContent objeto contiene detalles que identifican de forma exclusiva la instantánea, como el snapshotHandle. Esta snapshotHandle es una combinación única del nombre del VP y el nombre del VolumeSnapshotContent objeto.

Cuando llega una solicitud de Snapshot, Trident crea la snapshot en el back-end. Después de crear la copia Snapshot, Trident configura un VolumeSnapshotContent objeto y, por lo tanto, la copia Snapshot se expone 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.

Astra Trident usa CustomResourceDefinition objetos para conservar la identidad de los 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 sencillo, cuando se crea un backend con tridentctl, se crea un objeto CRD correspondiente tridentbackends para su consumo por 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 los objetos de Kubernetes StorageClass que se especifican csi.trident.netapp.io en su campo aprovisionador. El nombre de la clase de almacenamiento coincide con el del objeto de Kubernetes StorageClass 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, para implementaciones de Kubernetes, esperamos que se creen al registrar nuevos objetos de Kubernetes StorageClass.

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 sobre 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, estos corresponden directamente a 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.

Trident genera internalName al crear el volumen. Esto consta de dos pasos. En primer lugar, antepone el prefijo de almacenamiento (ya sea el predeterminado trident o el prefijo en la configuración de backend) al nombre del volumen, lo que da como resultado un 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 el caso de los back-ends de ONTAP, reemplaza guiones con guiones bajos (por lo tanto, el nombre interno se convierte `<prefix>_<volume-name>`en ). En los back-ends de Element, reemplaza guiones bajos por guiones.

Puedes utilizar las configuraciones de volúmenes para aprovisionar volúmenes directamente mediante la API de REST, pero en las implementaciones de Kubernetes esperamos que la mayoría de los usuarios usen el método Kubernetes estándar PersistentVolumeClaim. 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, estos corresponden directamente VolumeSnapshotContent a objetos. Cada copia de Snapshot se asocia con un volumen, que es el origen de los datos de la copia de Snapshot.

Cada Snapshot objeto incluye las propiedades enumeradas a continuación:

Cuando se crea una solicitud de objetos de Kubernetes VolumeSnapshot, Trident funciona creando un objeto Snapshot en el sistema de almacenamiento de respaldo. Para internalName este objeto Snapshot se genera combinando el prefijo snapshot- con el UID VolumeSnapshot objeto (por ejemplo, snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660). volumeName y volumeInternalName se completan mediante la obtención de los detalles del volumen de respaldo.

El desamonset de Trident consume una 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 el apagado de nodo correcto y permitir que los pods de inicio de datos de Trident se adelanten a las cargas de trabajo con una prioridad más baja en los clústeres donde hay una alta presión de recursos.

Para lograrlo, Astra Trident emplea un ResourceQuota objeto para garantizar que se satisfaga una clase de prioridad «crítica sistema-nodo» en el inicio de datos de Trident. Antes de la implementación y la creación de desastres, Astra Trident busca ResourceQuota el objeto 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 custom.yaml o configurar 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 sobre las cuotas de recursos, consulte "Kubernetes: Cuotas de recursos".