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

Un objeto de Kubernetes PersistentVolumeClaim es una solicitud de almacenamiento hecha por un usuario de un clúster de Kubernetes.

Además de la especificación estándar, Trident permite a los usuarios especificar las siguientes anotaciones específicas de volumen si quieren anular los valores predeterminados que tú configuraste en el backend:

Si el PV creado tiene la Delete política de recuperación, Trident elimina tanto el PV como el volumen de respaldo cuando el PV se libera (o sea, cuando el usuario elimina el PVC). Si la acción de eliminación falla, Trident marca el PV como tal y reintenta la operación periódicamente hasta que tenga éxito o el PV se elimine manualmente. Si el PV usa la Retain política, Trident lo ignora y asume que el administrador lo limpiará de Kubernetes y del backend, permitiendo que el volumen se respalde o se inspeccione antes de eliminarlo. Ten en cuenta que eliminar el PV no hace que Trident elimine el volumen de respaldo. Deberías eliminarlo usando la API de REST (tridentctl).

Trident admite la creación de instantáneas de volumen usando la especificación CSI: puedes crear una instantánea de volumen y usarla como fuente de datos para clonar los PVC existentes. De esta manera, las copias de un momento específico de los PV se pueden exponer a Kubernetes en forma de instantáneas. Luego, las instantáneas se pueden usar para crear nuevos PV. Echa un vistazo a On-Demand Volume Snapshots para ver cómo funcionaría esto.

Trident también proporciona las cloneFromPVC y splitOnClone anotaciones para crear clones. Puedes usar estas anotaciones para clonar un PVC sin tener que usar la implementación de CSI.

Aquí tienes un ejemplo: si un usuario ya tiene un PVC llamado mysql, el usuario puede crear un nuevo PVC llamado mysqlclone usando la anotación, como trident.netapp.io/cloneFromPVC: mysql. Con esta anotación establecida, Trident clona el volumen correspondiente al PVC mysql, en vez de aprovisionar un volumen desde cero.

Ten en cuenta los siguientes puntos:

El sample-input directorio contiene ejemplos de definiciones de PVC para usar con Trident. Consulta para una descripción completa de los parámetros y configuraciones asociadas con los volúmenes de Trident.

Un objeto de Kubernetes PersistentVolume representa una parte de almacenamiento que está disponible para el clúster de Kubernetes. Tiene un ciclo de vida independiente del pod que lo usa.

Cuando creas un PVC que hace referencia a un recurso basado en Trident StorageClass, Trident aprovisiona un volumen nuevo usando la clase de almacenamiento correspondiente y registra un PV nuevo para ese volumen. Al configurar el volumen aprovisionado y el PV correspondiente, Trident sigue las siguientes reglas:

Los objetos de Kubernetes StorageClass se especifican por nombre en PersistentVolumeClaims para aprovisionar almacenamiento con un conjunto de propiedades. La propia clase de almacenamiento identifica el aprovisionador que se va a usar y define ese conjunto de propiedades en términos que el aprovisionador entiende.

Es uno de los dos objetos básicos que necesita crear y gestionar el administrador. El otro es el objeto backend de Trident.

Un objeto de Kubernetes StorageClass que utiliza Trident se ve así:

Estos parámetros son específicos de Trident y le 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 pool de almacenamiento y atributos de Kubernetes.

Los objetos de Kubernetes VolumeSnapshotClass son análogos a StorageClasses. Ayudan a definir múltiples clases de almacenamiento y son referenciados por instantáneas de volumen para asociar la instantánea con la clase de instantánea requerida. Cada instantánea de volumen está asociada a una sola clase de instantánea de volumen.

A VolumeSnapshotClass debe ser definido por un administrador para crear instantáneas. Una clase de instantánea de volumen se crea con la siguiente definición:

El driver especifica a Kubernetes que las solicitudes de instantáneas de volumen de la clase csi-snapclass son gestionadas por Trident. El deletionPolicy especifica la acción que se debe tomar cuando se debe eliminar una instantánea. Cuando deletionPolicy se establece en Delete, los objetos de instantánea de volumen, así como la instantánea subyacente en el clúster de almacenamiento, se eliminan al borrar una instantánea. De forma alternativa, si se establece en Retain, VolumeSnapshotContent y la instantánea física se conservan.

Un objeto de Kubernetes VolumeSnapshot es una solicitud para crear una instantánea de un volumen. Así como una PVC representa una solicitud hecha por un usuario para un volumen, una instantánea de volumen es una solicitud hecha por un usuario para crear una instantánea de una PVC existente.

Cuando llega una solicitud de instantánea de volumen, Trident gestiona automáticamente la creación de la instantánea para el volumen en el backend y la expone creando un objeto único
VolumeSnapshotContent. Puedes crear instantáneas a partir de PVC existentes y usar las instantáneas como DataSource al crear nuevas PVC.

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

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

Cuando se recibe una solicitud de instantánea, Trident crea la instantánea en el backend. Después de que se crea la instantánea, Trident configura un VolumeSnapshotContent objeto y así expone la instantánea a la API de Kubernetes.

Los objetos de Kubernetes VolumeGroupSnapshotClass son análogos a VolumeSnapshotClass. Ayudan a definir múltiples clases de almacenamiento y las instantáneas de grupo de volúmenes los referencian para asociar la instantánea con la clase de instantánea requerida. Cada instantánea de grupo de volúmenes está asociada a una sola clase de instantánea de grupo de volúmenes.

A VolumeGroupSnapshotClass debe ser definido por un administrador para crear un grupo de instantáneas. Una clase de instantánea de grupo de volúmenes se crea con la siguiente definición:

El driver especifica a Kubernetes que las solicitudes para instantáneas de grupo de volúmenes de la clase csi-group-snap-class son gestionadas por Trident. El deletionPolicy especifica la acción que se debe tomar cuando se debe eliminar una instantánea de grupo. Cuando deletionPolicy se establece en Delete, los objetos de la instantánea del grupo de volúmenes, así como la instantánea subyacente en el clúster de almacenamiento, se eliminan al borrar una instantánea. De manera alternativa, si se establece en Retain, significa que VolumeGroupSnapshotContent y la instantánea física se conservan.

Un objeto de Kubernetes VolumeGroupSnapshot es una solicitud para crear una snapshot de varios volúmenes. Así como un PVC representa una solicitud hecha por un usuario para un volumen, una snapshot de grupo de volúmenes es una solicitud hecha por un usuario para crear una snapshot de un PVC existente.

Cuando llega una solicitud de instantánea de grupo de volúmenes, Trident gestiona automáticamente la creación de la instantánea de grupo para los volúmenes en el backend y expone la instantánea mediante la creación de un VolumeGroupSnapshotContent objeto único. Puedes crear instantáneas a partir de PVC existentes y usar las instantáneas como DataSource al crear nuevos PVC.

Un objeto de Kubernetes VolumeGroupSnapshotContent representa una instantánea de grupo tomada de un volumen ya aprovisionado. Es análogo a PersistentVolume y significa una instantánea aprovisionada en el clúster de almacenamiento. De forma similar a PersistentVolumeClaim y PersistentVolume objetos, cuando se crea una instantánea, el objeto VolumeSnapshotContent mantiene una correspondencia uno a uno con el objeto VolumeSnapshot que había solicitado la creación de la instantánea.

El VolumeGroupSnapshotContent objeto contiene detalles que identifican al grupo de instantáneas, como el volumeGroupSnapshotHandle y volumeSnapshotHandles individuales existentes en el sistema de almacenamiento.

Cuando llega una solicitud de instantánea, Trident crea la instantánea del grupo de volúmenes en el backend. Después de que se crea la instantánea del grupo de volúmenes, Trident configura un VolumeGroupSnapshotContent objeto y así expone la instantánea a la API de Kubernetes.

Los recursos personalizados de Kubernetes son puntos finales 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 una colección de objetos. Puedes obtener estas definiciones de recursos ejecutando kubectl get crds.

Las definiciones de recursos personalizadas (CRDs) y sus metadatos de objetos asociados son almacenados por Kubernetes en su almacén de metadatos. Esto elimina la necesidad de un almacén independiente para Trident.

Trident utiliza CustomResourceDefinition objetos para preservar la identidad de los objetos de Trident, como los backends de Trident, las clases de almacenamiento de Trident y los volúmenes de Trident. Estos objetos son gestionados por Trident. Además, el marco de instantáneas de volumen de CSI introduce algunos CRD que son necesarios para definir instantáneas de volumen.

Los CRD son una construcción de Kubernetes. Los objetos de los recursos definidos arriba son creados por Trident. Como ejemplo sencillo, cuando se crea un backend usando tridentctl, se crea un objeto CRD correspondiente tridentbackends para que lo consuma Kubernetes.

Aquí tienes algunos puntos que debes tener en cuenta sobre los CRD de Trident:

Trident crea clases de almacenamiento coincidentes para objetos de Kubernetes StorageClass que especifican csi.trident.netapp.io en su campo de provisioner. 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 compara estos requisitos con los atributos presentes en cada storage pool; si coinciden, ese storage pool es un objetivo válido para aprovisionar volúmenes usando esa storage class.

Puedes crear configuraciones de clases de almacenamiento para definir directamente las clases de almacenamiento usando la API de REST. Sin embargo, para las implementaciones de Kubernetes, esperamos que se creen al registrar nuevos objetos de Kubernetes StorageClass.

Los backends representan los proveedores de almacenamiento sobre los que Trident aprovisiona volúmenes; una sola instancia de Trident puede gestionar cualquier número de backends.

Para más información sobre cómo construir estos objetos, consulta "configuración de backends".

Los pools de almacenamiento representan las distintas ubicaciones disponibles para el aprovisionamiento en cada backend. Para ONTAP, estas corresponden a agregados en SVMs. Para NetApp HCI/SolidFire, estas corresponden a bandas de QoS especificadas por el administrador. Cada pool de almacenamiento tiene un conjunto de atributos de almacenamiento distintos, que definen sus características de rendimiento y de protección de datos.

A diferencia de los demás objetos aquí, los candidatos a pool de almacenamiento siempre se descubren y gestionan automáticamente.

Los volúmenes son la unidad básica de aprovisionamiento, y comprenden puntos finales de backend, como recursos compartidos NFS y LUN iSCSI y FC. En Kubernetes, estos corresponden directamente a PersistentVolumes. Cuando crees un volumen, asegúrate de que tenga 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 consiste en dos pasos. Primero, antepone el prefijo de almacenamiento (ya sea el predeterminado trident o el prefijo en la configuración del backend) al nombre del volumen, lo que da como resultado un nombre con la forma <prefix>-<volume-name>. Luego procede a sanear el nombre, reemplazando los caracteres no permitidos en el backend. Para los backends ONTAP, reemplaza los guiones por guiones bajos (así, el nombre interno se convierte en <prefix>_<volume-name>). Para los backends Element, reemplaza los guiones bajos por guiones.

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

Las instantáneas son una copia de un momento específico de volúmenes, que pueden usarse para aprovisionar nuevos volúmenes o restaurar el estado. En Kubernetes, estas corresponden directamente a objetos VolumeSnapshotContent. Cada instantánea está asociada a un volumen, que es la fuente de los datos para la instantánea.

Cada Snapshot objeto incluye las propiedades que se indican a continuación:

Cuando se crea una solicitud de objeto de Kubernetes VolumeSnapshot, Trident funciona creando un objeto de snapshot en el sistema de almacenamiento de respaldo. El internalName de este objeto de snapshot se genera combinando el prefijo snapshot- con el UID del objeto VolumeSnapshot (por ejemplo, snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660). volumeName y volumeInternalName se rellenan obteniendo los detalles del volumen de respaldo.

El daemonset de Trident consume una system-node-critical Priority Class, la Priority Class más alta disponible en Kubernetes, para asegurarse de que Trident pueda identificar y limpiar volúmenes durante el apagado correcto de nodos y permitir que los pods del daemonset de Trident se adelanten a cargas de trabajo con una prioridad más baja en clústeres donde hay mucha presión de recursos.

Para lograr esto, Trident emplea un ResourceQuota objeto para asegurar que se satisface una Clase de Prioridad "system-node-critical" en el daemonset de Trident. Antes del despliegue y la creación del daemonset, Trident busca el ResourceQuota objeto y, si no lo descubre, lo aplica.

Si necesitas más control sobre la Cuota de Recursos y la Clase de Prioridad por defecto, puedes generar un custom.yaml o configurar el objeto ResourceQuota usando el Helm chart.

El siguiente es un ejemplo de un objeto ResourceQuota que prioriza el daemonset Trident.

Para más información sobre las cuotas de recursos, consulta "Kubernetes: cuotas de recursos".