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

Kubernetes PersistentVolumeClaim El objeto es una solicitud de almacenamiento realizada 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 del volumen si desean anular los valores predeterminados que se establecen en la configuración del backend:

Si el PV creado tiene el Delete Según la política de recuperación, Trident elimina tanto el PV como el volumen de respaldo cuando se libera el PV (es decir, cuando el usuario elimina el PVC). Si la acción de eliminación falla, Trident marca el PV como tal y reintenta periódicamente la operación hasta que tenga éxito o el PV se elimine manualmente. Si el PV utiliza el Retain Según la política de Trident , esto se ignora y se asume que el administrador lo eliminará de Kubernetes y del backend, lo que permite realizar una copia de seguridad o inspeccionar el volumen antes de su eliminación. Tenga en cuenta que eliminar el PV no provoca que Trident elimine el volumen de respaldo. Debes eliminarlo usando la API REST.(tridentctl ).

Trident admite la creación de instantáneas de volumen mediante la especificación CSI: puede crear una instantánea de volumen y usarla como fuente de datos para clonar PVC existentes. De esta forma, se pueden exponer a Kubernetes copias puntuales de los PV en forma de instantáneas. Las instantáneas se pueden utilizar posteriormente para crear nuevos PV. Echa un vistazo a On-Demand Volume Snapshots para ver cómo funcionaría esto.

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

Aquí hay un ejemplo: Si un usuario ya tiene un PVC llamado mysql , el usuario puede crear un nuevo PVC llamado mysqlclone mediante el uso de la anotación, como por ejemplo trident.netapp.io/cloneFromPVC: mysql . Con este conjunto de anotaciones, Trident clona el volumen correspondiente al PVC de MySQL, en lugar de aprovisionar un volumen desde cero.

Considere los siguientes puntos:

El sample-input El directorio contiene ejemplos de definiciones de PVC para usar con Trident. Referirse a Para obtener una descripción completa de los parámetros y la configuración asociados con los volúmenes de Trident .

Kubernetes PersistentVolume El objeto representa una porción 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 creas un PVC que hace referencia a un Trident basado en StorageClass Trident aprovisiona un nuevo volumen utilizando la clase de almacenamiento correspondiente y registra un nuevo PV para ese volumen. Al configurar el volumen aprovisionado y el PV correspondiente, Trident sigue las siguientes reglas:

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

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

Kubernetes StorageClass Un objeto que utiliza Trident tiene este aspecto:

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

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

A VolumeSnapshotClass Debe ser definido por un administrador para poder crear instantáneas. Se crea una clase de instantánea de volumen con la siguiente definición:

El driver especifica a Kubernetes que las solicitudes de instantáneas de volumen de csi-snapclass Las clases son gestionadas por Trident. El deletionPolicy Especifica la acción que se debe realizar cuando se deba eliminar una instantánea. Cuando deletionPolicy está configurado para Delete Cuando se elimina una instantánea, se eliminan tanto los objetos de instantánea de volumen como la instantánea subyacente en el clúster de almacenamiento. Alternativamente, configurándolo a Retain significa que VolumeSnapshotContent y se conserva la instantánea física.

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

Cuando se recibe 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 identificador único.
VolumeSnapshotContent objeto. Puede crear instantáneas a partir de PVC existentes y utilizarlas como fuente de datos al crear nuevos PVC.

Kubernetes VolumeSnapshotContent El objeto 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, VolumeSnapshotContent el objeto mantiene una correspondencia uno a uno con el VolumeSnapshot objeto, que había solicitado la creación de la instantánea.

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

Cuando llega una solicitud de instantánea, Trident crea la instantánea en el backend. Después de crear la instantánea, Trident configura un VolumeSnapshotContent objeto y, por lo tanto, expone la instantánea a la API de Kubernetes.

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

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

El driver especifica a Kubernetes que las solicitudes de instantáneas de grupos de volúmenes de csi-group-snap-class Las clases son gestionadas por Trident. El deletionPolicy Especifica la acción que se debe realizar cuando se deba eliminar una instantánea de grupo. Cuando deletionPolicy está configurado para Delete Cuando se elimina una instantánea, se eliminan tanto los objetos de instantánea del grupo de volúmenes como la instantánea subyacente en el clúster de almacenamiento. Alternativamente, configurándolo a Retain significa que VolumeGroupSnapshotContent y se conserva la instantánea física.

Kubernetes VolumeGroupSnapshot El objeto es una solicitud para crear una instantánea de múltiples volúmenes. Así como un PVC representa una solicitud realizada por un usuario para obtener un volumen, una instantánea de grupo de volúmenes es una solicitud realizada por un usuario para crear una instantánea de un PVC existente.

Cuando se recibe 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 la expone creando un identificador único. VolumeGroupSnapshotContent objeto. Puede crear instantáneas a partir de PVC existentes y utilizarlas como fuente de datos al crear nuevos PVC.

Kubernetes VolumeGroupSnapshotContent El objeto representa una instantánea de grupo 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, VolumeSnapshotContent el objeto mantiene una correspondencia uno a uno con el VolumeSnapshot objeto, que había solicitado la creación de la instantánea.

El VolumeGroupSnapshotContent El objeto contiene detalles que identifican el grupo de instantáneas, como por ejemplo: volumeGroupSnapshotHandle y los identificadores de instantáneas de volumen 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 crear la instantánea del grupo de volúmenes, Trident configura un VolumeGroupSnapshotContent objeto y, por lo tanto, expone la instantánea a la API de Kubernetes.

Los recursos personalizados de Kubernetes son puntos de conexión en la API de Kubernetes que son definidos por el administrador y se utilizan para agrupar objetos similares. Kubernetes admite la creación de recursos personalizados para almacenar una colección de objetos. Puede obtener estas definiciones de recursos ejecutando kubectl get crds .

Kubernetes almacena las definiciones de recursos personalizados (CRD) y sus metadatos de objetos asociados en su almacén de metadatos. Esto elimina la necesidad de una tienda separada para Trident.

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

Los CRD son una construcción de Kubernetes. Los objetos de los recursos definidos anteriormente son creados por Trident. Como ejemplo sencillo, cuando se crea un backend utilizando tridentctl , un correspondiente tridentbackends El objeto CRD se crea para su uso por Kubernetes.

Aquí hay algunos puntos a tener en cuenta sobre los CRD de Trident:

Trident crea clases de almacenamiento coincidentes para Kubernetes. StorageClass objetos que especifican csi.trident.netapp.io 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 compara estos requisitos con los atributos presentes en cada grupo de almacenamiento; si coinciden, ese grupo de almacenamiento es un destino válido para el aprovisionamiento de volúmenes utilizando esa clase de almacenamiento.

Puede crear configuraciones de clases de almacenamiento para definir directamente las clases de almacenamiento mediante la API REST. Sin embargo, para las implementaciones de Kubernetes, esperamos que se creen al registrar un nuevo Kubernetes. StorageClass objetos.

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

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

Los grupos de almacenamiento representan las distintas ubicaciones disponibles para el aprovisionamiento en cada backend. Para ONTAP, estos corresponden a agregados en SVM. Para NetApp HCI/ SolidFire, estos corresponden a las bandas QoS especificadas por el administrador. Para el Cloud Volumes Service, estos corresponden a las regiones del proveedor de la nube. Cada grupo 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í presentes, los candidatos a grupo de almacenamiento siempre se descubren y gestionan automáticamente.

Los volúmenes son la unidad básica de aprovisionamiento, que comprende puntos de conexión de backend, como recursos compartidos NFS y LUN iSCSI y FC. En Kubernetes, estos se corresponden directamente con PersistentVolumes . Cuando cree un volumen, asegúrese de que tenga una clase de almacenamiento, que determina dónde se puede aprovisionar ese volumen, junto con un tamaño.

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

Trident genera internalName al crear el volumen. Esto consta de 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 de la forma <prefix>-<volume-name> . A continuación, procede a sanear el nombre, reemplazando los caracteres no permitidos en el backend. Para los backends de ONTAP , reemplaza los guiones con guiones bajos (por lo tanto, el nombre interno se convierte en <prefix>_<volume-name> ). Para los backends de Element, reemplaza los guiones bajos con guiones.

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

Las instantáneas son una copia puntual de los volúmenes, que se puede utilizar para aprovisionar nuevos volúmenes o restaurar el estado. En Kubernetes, estos se corresponden directamente con VolumeSnapshotContent objetos. Cada instantánea está asociada a un volumen, que es la fuente de los datos para la instantánea.

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

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

El conjunto de demonios Trident consume un system-node-critical Clase de prioridad: la clase de prioridad más alta disponible en Kubernetes, para garantizar que Trident pueda identificar y limpiar volúmenes durante el apagado ordenado de nodos y permitir que los pods del conjunto de demonios de Trident prevalezcan sobre las cargas de trabajo con una prioridad más baja en clústeres donde hay una alta presión de recursos.

Para lograrlo, Trident emplea un ResourceQuota objeto para garantizar que se cumpla una clase de prioridad "crítica del nodo del sistema" en el conjunto de demonios Trident . Antes del despliegue y la creación del DaemonSet, Trident busca el ResourceQuota objeto y, si no lo descubre, lo aplica.

Si necesita un mayor control sobre la cuota de recursos y la clase de prioridad predeterminadas, puede generar un custom.yaml o configurar el ResourceQuota objeto que utiliza el gráfico Helm.

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

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