About VAST CSI Driver

Overview of VAST CSI Driver

VAST CSI Driver allows container orchestration frameworks such as Kubernetes to dynamically provision storage on a VAST cluster using the Container Storage Interface (CSI). VAST provides scalable, reliable, and fast persistent storage that can be accessed remotely by any Kubernetes application container.

With dynamic provisioning, you do not need to create container-specific persistent volumes. Instead, you deploy a dynamic provisioner and a YAML class definition that specifies the dynamic provisioner and provisioning options. When an application makes a claim for storage, the Kubernetes framework employs the dynamic provisioner to dynamically create a persistent volume. Later, when a containerized application (via its YAML) references this claim, Kubernetes provides the storage to the container.

With VAST CSI Driver, you can:

• Provision volumes based on multiple Kubernetes storage classes

• Provision static volumes

• 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

• mTLS authentication of client NFS connections

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 can be deployed using one of the following methods:

• Helm chart-based deployment

• VAST CSI Operator for Kubernetes

• VAST CSI Operator for OpenShift

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:

1. 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.

2. 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.

3. 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.

4. Kubernetes begins the application launch sequence and recognizes that the application referenced a PVC.

5. Kubernetes asks the VAST CSI controller to publish the volume to the node where the application is to run.

6. 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.

7. Kubernetes asks VAST CSI Driver on the node to mount the volume, making it available for the application.

8. Kubernetes causes the application within the pod to start.

9. 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 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.

Note: When provisioning static volumes, automatic creation of views is disabled by default, but can be enabled for a PV by setting a flag in the PV definition.

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 described in the VAST Cluster Administrator's Guide.

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.

When using VAST CSI Driver with VAST Cluster 5.3.3 or later, you can specify the VAST cluster tenant from which to provision storage for a claim. To do so:

• Supply the tenant parameter in the Kubernetes secret (that provides credentials used to connect to the VAST cluster). Create a Kubernetes Secret for VAST CSI Driver

• Use a VMS user that is a Tenant Admin for the desired tenant when connecting to the VAST cluster.

  To check VMS user type in VAST Web UI, go to Administrators -> Managers, click a user and look at the User type field, which should be set to Tenant Admin.

When no tenant parameter is supplied or supported (which is the case when VAST Cluster 5.3.2 or earlier is used), the tenant is determined based on the view policy that is attached to the view that exposes the volume.

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

See VAST best practice for efficient load balancing across VAST cluster CNodes when using VAST CSI Driver for Kubernetes.