Articles in this section

VAST CSI Driver Overview

Irina Malysheva
  • Updated
Follow

VAST CSI Driver allows container orchestration frameworks such as Kubernetes to dynamically provision storage volumes on a VAST cluster. 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 the following elements that allow for dynamic volume provisioning:

  • A storage class, which is a YAML class definition that specifies a dynamic provisioner and volume-related options.

  • A dynamic provisioner.

When an application makes a Persistent Volume Claim (PVC), the Kubernetes framework employs the dynamic provisioner to dynamically create a persistent volume. Later, when a container (via its YAML) references a PVC, Kubernetes provides the volume to the container. For more information about VAST and Kubernetes interaction, see A Deeper Dive into VAST CSI.

Important

Dynamic provisioning is optimized to provide storage that is accessible only from the Kubernetes containerized environment. Do not use dynamic provisioning if you need to expose existing storage on VAST to both Kubernetes containerized applications and non-Kubernetes applications.

VAST CSI Driver 2.2.x is deployed using a Helm chart. Check the deployment requirements and follow these steps to implement dynamic provisioning with VAST CSI Driver.

Optionally, take advantage of the following capabilities:

A Deeper Dive into VAST CSI

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 VIP 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 (VIPs) to the node.

    Note that each volume will get a single VIP on each node. Multiple volumes on the same node or the same volume on different nodes will likely get different VIPs 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).

View per Volume

VAST CSI Driver creates a VAST Cluster view for each volume it provisions. Such a view is automatically deleted when its volume is deleted.

The views created by VAST CSI Driver can be monitored and configured 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 you specify for each storage class in the configuration file.

 

NFS Support

Starting with version 2.2.1, VAST CSI Driver supports NFSv4.1 and NFSv3. Enabling NFSv4.1 access by VAST CSI Driver is done the same way as for other NFSv4.1 clients; see Configuring Storage Access for NFSv4.1 Clients for details. To mount volumes with NFSv4.1, specify mountOptions: "nfsvers=4" for the storage class.

VAST CSI Driver 2.2.0 supports NFSv3 but does not support NFSv4.1. Specifying mountOptions: "nfsvers=4" for a storage class would result in a failure when the pod attempts to mount a volume.

 

SSL Support

VAST CSI Driver supports SSL encryption. To secure the connection to the VAST cluster with SSL:

  1. Add the verifySsl=true option to the configuration file (values.yaml) for the VAST CSI Driver Helm chart.

  2. Do one of the following:

    • If you want to use a CA-signed SSL certificate, upload it to the VAST cluster.

    • If you want to use a self-signed SSL certificate, specify the certificate file on the VAST CSI Driver Helm chart installation command.

 
 
 

Related articles

Comments

0 comments

Article is closed for comments.