Perhaps the easiest way to understand the objects, what they are for, and how they interact, is to follow a single request for storage from a Kubernetes user:

A Kubernetes PersistentVolumeClaim object is a request for storage made by a Kubernetes cluster user.

In addition to the standard specification, Trident allows users to specify the following volume-specific annotations if they want to override the defaults that you set in the backend configuration:

If the created PV has the Delete reclaim policy, Trident deletes both the PV and the backing volume when the PV becomes released (that is, when the user deletes the PVC). Should the delete action fail, Trident marks the PV as such and periodically retries the operation until it succeeds or the PV is manually deleted. If the PV uses the Retain policy, Trident ignores it and assumes the administrator will clean it up from Kubernetes and the backend, allowing the volume to be backed up or inspected before its removal. Note that deleting the PV does not cause Trident to delete the backing volume. You should remove it using the REST API (tridentctl).

Trident supports the creation of Volume Snapshots using the CSI specification: you can create a Volume Snapshot and use it as a Data Source to clone existing PVCs. This way, point-in-time copies of PVs can be exposed to Kubernetes in the form of snapshots. The snapshots can then be used to create new PVs. Take a look at On-Demand Volume Snapshots to see how this would work.

Trident also provides the cloneFromPVC and splitOnClone annotations for creating clones. You can use these annotations to clone a PVC without having to use the CSI implementation.

Here is an example: If a user already has a PVC called mysql, the user can create a new PVC called mysqlclone by using the annotation, such as trident.netapp.io/cloneFromPVC: mysql. With this annotation set, Trident clones the volume corresponding to the mysql PVC, instead of provisioning a volume from scratch.

Consider the following points:

The sample-input directory contains examples of PVC definitions for use with Trident. Refer to [Trident Volume objects] for a full description of the parameters and settings associated with Trident volumes.

A Kubernetes PersistentVolume object represents a piece of storage that is made available to the Kubernetes cluster. It has a lifecycle that is independent of the pod that uses it.

When you create a PVC that refers to a Trident-based StorageClass, Trident provisions a new volume using the corresponding storage class and registers a new PV for that volume. In configuring the provisioned volume and corresponding PV, Trident follows the following rules:

Kubernetes StorageClass objects are specified by name in PersistentVolumeClaims to provision storage with a set of properties. The storage class itself identifies the provisioner to be used and defines that set of properties in terms the provisioner understands.

It is one of two basic objects that need to be created and managed by the administrator. The other is the Trident backend object.

A Kubernetes StorageClass object that uses Trident looks like this:

These parameters are Trident-specific and tell Trident how to provision volumes for the class.

The storage class parameters are:

Storage attributes and their possible values can be classified into storage pool selection attributes and Kubernetes attributes.

Kubernetes VolumeSnapshotClass objects are analogous to StorageClasses. They help define multiple classes of storage and are referenced by volume snapshots to associate the snapshot with the required snapshot class. Each volume snapshot is associated with a single volume snapshot class.

A VolumeSnapshotClass should be defined by an administrator in order to create snapshots. A volume snapshot class is created with the following definition:

The driver specifies to Kubernetes that requests for volume snapshots of the csi-snapclass class are handled by Trident. The deletionPolicy specifies the action to be taken when a snapshot must be deleted. When deletionPolicy is set to Delete, the volume snapshot objects as well as the underlying snapshot on the storage cluster are removed when a snapshot is deleted. Alternatively, setting it to Retain means that VolumeSnapshotContent and the physical snapshot are retained.

A Kubernetes VolumeSnapshot object is a request to create a snapshot of a volume. Just as a PVC represents a request made by a user for a volume, a volume snapshot is a request made by a user to create a snapshot of an existing PVC.

When a volume snapshot request comes in, Trident automatically manages the creation of the snapshot for the volume on the backend and exposes the snapshot by creating a unique
VolumeSnapshotContent object. You can create snapshots from existing PVCs and use the snapshots as a DataSource when creating new PVCs.

A Kubernetes VolumeSnapshotContent object represents a snapshot taken from an already provisioned volume. It is analogous to a PersistentVolume and signifies a provisioned snapshot on the storage cluster. Similar to PersistentVolumeClaim and PersistentVolume objects, when a snapshot is created, the VolumeSnapshotContent object maintains a one-to-one mapping to the VolumeSnapshot object, which had requested the snapshot creation.

The VolumeSnapshotContent object contains details that uniquely identify the snapshot, such as the snapshotHandle. This snapshotHandle is a unique combination of the name of the PV and the name of the VolumeSnapshotContent object.

When a snapshot request comes in, Trident creates the snapshot on the backend. After the snapshot is created, Trident configures a VolumeSnapshotContent object and thus exposes the snapshot to the Kubernetes API.

Kubernetes Custom Resources are endpoints in the Kubernetes API that are defined by the administrator and are used to group similar objects. Kubernetes supports the creation of custom resources for storing a collection of objects. You can obtain these resource definitions by running kubectl get crds.

Custom Resource Definitions (CRDs) and their associated object metadata are stored by Kubernetes in its metadata store. This eliminates the need for a separate store for Trident.

Astra Trident uses CustomResourceDefinition objects to preserve the identity of Trident objects, such as Trident backends, Trident storage classes, and Trident volumes. These objects are managed by Trident. In addition, the CSI volume snapshot framework introduces some CRDs that are required to define volume snapshots.

CRDs are a Kubernetes construct. Objects of the resources defined above are created by Trident. As a simple example, when a backend is created using tridentctl, a corresponding tridentbackends CRD object is created for consumption by Kubernetes.

Here are a few points to keep in mind about Trident's CRDs:

Trident creates matching storage classes for Kubernetes StorageClass objects that specify csi.trident.netapp.io in their provisioner field. The storage class name matches that of the Kubernetes StorageClass object it represents.

Storage classes comprise a set of requirements for volumes. Trident matches these requirements with the attributes present in each storage pool; if they match, that storage pool is a valid target for provisioning volumes using that storage class.

You can create storage class configurations to directly define storage classes by using the REST API. However, for Kubernetes deployments, we expect them to be created when registering new Kubernetes StorageClass objects.

Backends represent the storage providers on top of which Trident provisions volumes; a single Trident instance can manage any number of backends.

For more information about how to construct these objects, refer to configuring backends.

Storage pools represent the distinct locations available for provisioning on each backend. For ONTAP, these correspond to aggregates in SVMs. For NetApp HCI/SolidFire, these correspond to administrator-specified QoS bands. For Cloud Volumes Service, these correspond to cloud provider regions. Each storage pool has a set of distinct storage attributes, which define its performance characteristics and data protection characteristics.

Unlike the other objects here, storage pool candidates are always discovered and managed automatically.

Volumes are the basic unit of provisioning, comprising backend endpoints, such as NFS shares and iSCSI LUNs. In Kubernetes, these correspond directly to PersistentVolumes. When you create a volume, ensure that it has a storage class, which determines where that volume can be provisioned, along with a size.

A volume configuration defines the properties that a provisioned volume should have.

Trident generates internalName when creating the volume. This consists of two steps. First, it prepends the storage prefix (either the default trident or the prefix in the backend configuration) to the volume name, resulting in a name of the form <prefix>-<volume-name>. It then proceeds to sanitize the name, replacing characters not permitted in the backend. For ONTAP backends, it replaces hyphens with underscores (thus, the internal name becomes <prefix>_<volume-name>). For Element backends, it replaces underscores with hyphens.

You can use volume configurations to directly provision volumes using the REST API, but in Kubernetes deployments we expect most users to use the standard Kubernetes PersistentVolumeClaim method. Trident creates this volume object automatically as part of the provisioning
process.

Snapshots are a point-in-time copy of volumes, which can be used to provision new volumes or restore state. In Kubernetes, these correspond directly to VolumeSnapshotContent objects. Each snapshot is associated with a volume, which is the source of the data for the snapshot.

Each Snapshot object includes the properties listed below:

When a Kubernetes VolumeSnapshot object request is created, Trident works by creating a snapshot object on the backing storage system. The internalName of this snapshot object is generated by combining the prefix snapshot- with the UID of the VolumeSnapshot object (for example, snapshot-e8d8a0ca-9826-11e9-9807-525400f3f660). volumeName and volumeInternalName are populated by getting the details of the backing
volume.

The Trident deamonset consumes a system-node-critical Priority Class—​the highest Priority Class available in Kubernetes—​to ensure Astra Trident can identify and clean up volumes during graceful node shutdown and allow Trident daemonset pods to preempt workloads with a lower priority in clusters where there is high resource pressure.

To accomplish this, Astra Trident employs a ResourceQuota object to ensure a "system-node-critical" Priority Class on the Trident daemonset is satisfied. Prior to deployment and daemonset creation, Astra Trident looks for the ResourceQuota object and, if not discovered, applies it.

If you need more control over the default Resource Quota and Priority Class, you can generate a custom.yaml or configure the ResourceQuota object using Helm chart.

The following is an example of a `ResourceQuota`object prioritizing the Trident daemonset.

For more information on Resource Quotas, refer to Kubernetes: Resource Quotas.