{{snippet.CSI Driver overview}}

With VAST CSI Driver, you can:

Provision NFS volumes based on multiple Kubernetes storage classes
Provision ephemeral volumes
Protect the volumes being provisioned with VAST snapshots and clones

VAST CSI Driver provides support for the following:

NFSv3 and NFSv4 access protocols
SSL encryption of the connection to the VAST cluster

VAST CSI Driver capabilities include:

Automatic creation of a VAST cluster view for each volume being provisioned
Leveraging the VAST cluster's Trash Folder Access functionality to handle deletions
Support for multiple VAST cluster tenants
Support for multiple VAST clusters
DNS-based resolution of virtual IPs

VAST CSI Driver is deployed using a Helm chart. Check the deployment requirements and follow these steps to implement dynamic provisioning with VAST CSI Driver. Note that the driver can also be deployed in OpenShift environments, which requires an additional step to be performed as part of the deployment procedure.

A Deeper Dive Into VAST CSI Driver

VAST CSI deployment has two components:

A controller pod that is responsible for creating and deleting volumes.
A node pod responsible for creating the mount on the node (host) it is running on. The node pod contains VAST CSI Driver that invokes mount and umount commands.
A node gets all necessary information about existing virtual IP pools and views from the controller. It does not communicate with the VAST Management Service (VMS) directly. The only exception to this is for handling Ephemeral Volumes, where the node pod handles the entire volume lifecycle.

The operation sequence is as follows:

An application makes a Persistent Volume Claim (PVC), which indirectly references the storage class which, in turn, references the dynamic provisioner for VAST Cluster via CSI.
The CSI receives the request to create a persistent volume. Based on the NFS configuration information provided via the storage class, it creates a VAST Cluster view and a directory on the VAST cluster (named for the persistent volume) and informs Kubernetes that the volume has been created.
Kubernetes allocates the logical persistent volume which references the VAST Cluster directory. At this point, you can see the directory by listing the view on the VAST cluster.
Kubernetes begins the application launch sequence and recognizes that the application referenced a PVC.
Kubernetes asks the VAST CSI controller to publish the volume to the node where the application is to run.
The VAST CSI controller gets the API request and allocates one of the VAST Cluster's virtual IPs to the node.
Note that each volume will get a single virtual IP on each node. Multiple volumes on the same node or the same volume on different nodes will likely get different virtual IPs for proper load spreading across volumes and nodes.
Kubernetes asks VAST CSI Driver on the node to mount the volume, making it available for the application.
Kubernetes causes the application within the pod to start.
The application can create a file in what appears to be a local directory within its container, but actually points to a directory on the VAST cluster (the directory being the persistent volume).

Automatic Creation of A View per Volume

VAST CSI Driver creates a VAST Cluster view for each volume or bucket being provisioned. Such a view is automatically deleted when its volume or bucket is deleted.

The views created by VAST CSI Driver can be monitored using VAST Cluster's Web UI or CLI.

To control access permissions for storage exposed through these views, VAST CSI Driver uses a view policy that is attached to the view. You specify the view policy for each storage class.

Leveraging Trash Folder Access to Handle Deletions

VAST CSI Driver gains a substantial performance boost during volume deletions through the use of Trash Folder Access, a feature of VAST Cluster.

Note
VAST Cluster 4.7.0-SP6 or later is required for the VAST drivers to be able to use the Trash Folder Access feature.

When deleting a volume that resides on VAST Cluster 4.7.0-SP6 and later where the Trash Folder Access feature is enabled, the delete request is processed using the VAST REST API's /folders/delete_folder/ endpoint. This means that the processing takes place locally on the VAST cluster.

VAST CSI Driver can delete either through Trash Folder Access, or by using a backward-compatibility mode which requires you to dedicate a virtual IP pool and a view policy for deletions through the deletionVipPool and deletionViewPolicy parameters in the VAST CSI Driver Helm chart configuration file.

When deleting volumes that reside on a VAST Cluster version earlier than 4.7.0-SP6, or when Trash Folder Access is disabled for any reason, you still need to specify deletionVipPool and deletionViewPolicy.

Note
For deletions to succeed, the tenant in the deletion view policy (deletionViewPolicy) must match the tenant of the view policy (viewPolicy) specified for the storage class.

Support of NFSv3 and NFSv4

VAST NFS CSI Driver supports NFSv4 and NFSv3. Enabling NFSv4 access by VAST NFS CSI Driver is done the same way as for other NFSv4 clients.

To mount volumes with NFSv4, specify mountOptions: "nfsvers=4" for the storage class.

Support of VAST Cluster Multi-Tenancy

VAST CSI Driver can operate on multiple VAST Cluster tenants.

To determine from which tenant to provision storage for a claim, VAST Cluster looks at the view policy that is attached to the view that exposes the volume or bucket.

To be able to operate in a multi-tenant environment, VAST CSI Driver requires VAST Cluster 4.7.0-SP6 or later with the Trash Folder Access feature enabled.

Note
If a deletion view policy (deletionViewPolicy) is specified in the VAST CSI Driver's Helm chart configuration file, the tenant in the deletion view policy must match the tenant of the view policy (viewPolicy) specified in the storage class. Otherwise, deletions would fail.

Load Balancing across VAST Cluster Nodes