Dynamo VAST CSI Integration (Optional)

Prev Next

This guide describes the recommended VAST CSI configuration for Dynamo KV cache workloads. For complete driver capabilities and general installation requirements, see the official VAST CSI deployment guide.

Info

Before you begin: Download the prepared YAML files from the project repository and adapt them to your environment. Confirm that your VAST and Kubernetes versions meet the compatibility requirements in the official guide.

Choose a provisioning method

Choose one of the following approaches before installing the driver:

Method

How it works

Use it when

Static provisioning

A Kubernetes PersistentVolume (PV) points to an existing VAST View. The Dynamo deployment claims that volume through a PersistentVolumeClaim (PVC).

You want to reuse and manage an existing VAST View.

Dynamic provisioning

The VAST CSI driver creates storage for each PVC and removes it when the PVC is deleted.

You want storage to follow the lifecycle of each deployment.

The two paths share the secret and Helm repository setup below. After completing the shared steps, follow only the section for your chosen provisioning method.

Prerequisites

  • The VMS endpoint IP address.

  • A configured and operational VAST DNS service.

  • A configured VIP pool, its FQDN, and at least 32 VIPs.

  • A View Policy configured with an NFS security flavor.

  • A VAST View at /kvcache with NFSv3 and read/write access.

  • A VMS user with the required permissions, plus an access token obtained with the vastpy Python package.

  • Trash Folder Access enabled. This is especially important for cleaning up dynamically provisioned volumes.

The examples assume the default tenant and do not enable SSL verification. Adjust these settings if your environment differs.

Shared setup

1. Configure the Kubernetes secret

Edit secret.yaml and set the VMS endpoint and access token:

..
  endpoint: <VMS-ENDPOINT-IP>
  token: <VMS-ACCESS-TOKEN>

Example

..
  endpoint: 192.168.15.100
  token: aaaAAAaa.aAaAaAaAaAaAaAaAaAaA

Apply the secret:

kubectl apply -f secret.yaml

2. Add the Helm repository

helm repo add vastcsi https://vast-data.github.io/vast-csi
helm repo update

Static provisioning

Use this path to expose the existing /kvcache VAST View through a pre-created PV and PVC.

1. Configure and install the CSI driver

Edit helm.yaml:

..
endpoint: "<VMS-ENDPOINT-IP>"
..

Example

..
endpoint: "192.168.15.100"
..

Render the chart locally to validate the configuration:

helm template csi-driver vastcsi/vastcsi -f helm.yaml

Install the driver:

helm install csi-driver vastcsi/vastcsi -f helm.yaml

2. Configure and create the PersistentVolume

Use pv-rdma.yaml if RDMA is available in your network stack. Otherwise, use pv-tcp.yaml.

Edit the selected file:

..
      vip_pool_fqdn: "<VIP-POOL-FQDN>"
      view_policy: <VIEW-POLICY>
..

Example

..
      vip_pool_fqdn: vippool.vastdata.com
      view_policy: default
..

Apply the PV:

kubectl apply -f pv-rdma.yaml

If you selected TCP, replace pv-rdma.yaml with pv-tcp.yaml in the command.

3. Create the PersistentVolumeClaim

kubectl apply -f pvc.yaml

Confirm that the claim is bound before deploying Dynamo:

kubectl get pv
kubectl get pvc

Dynamic provisioning

Use this path when the CSI driver should create storage for each PVC and remove it when the PVC is deleted.

1. Configure and install the CSI driver

Use helm-rdma.yaml if RDMA is available in your network stack. Otherwise, use helm-tcp.yaml.

Edit the selected file:

secretName: "vast-secret"
endpoint: "<VMS-ENDPOINT-IP>"
verifySsl: false
deletionVipPool: ""
deletionViewPolicy: ""

StorageClassDefaults:
  volumeNameFormat: "csi:{namespace}:{name}:{id}"
  ephemeralVolumeNameFormat: "eph:{namespace}:{name}:{id}"
  vipPoolFQDN: "<VIP-POOL-FQDN>"

storageClasses:
  vastdata-rdma:
    secretName: "vast-secret"
    secretNamespace: "default"
    storagePath: "/kvcache"
    viewPolicy: "<VIEW-POLICY>"
..

Example

secretName: "vast-secret"
endpoint: "192.168.15.100"
verifySsl: false
deletionVipPool: ""
deletionViewPolicy: ""

StorageClassDefaults:
  volumeNameFormat: "csi:{namespace}:{name}:{id}"
  ephemeralVolumeNameFormat: "eph:{namespace}:{name}:{id}"
  vipPoolFQDN: "vippool.vastdata.com"

storageClasses:
  vastdata-rdma:
    secretName: "vast-secret"
    secretNamespace: "default"
    storagePath: "/kvcache"
    viewPolicy: "default"
..

Render the chart locally to validate the configuration:

helm template csi-driver vastcsi/vastcsi -f helm-rdma.yaml

Install the driver:

helm install csi-driver vastcsi/vastcsi -f helm-rdma.yaml

If you selected TCP, replace helm-rdma.yaml with helm-tcp.yaml in both commands.

2. Create the PersistentVolumeClaim

kubectl apply -f pvc.yaml

Confirm that the dynamically provisioned PV is created and the claim is bound:

kubectl get storageclass
kubectl get pv
kubectl get pvc

Next step

After the PVC reaches the Bound state, reference it in the Dynamo deployment and verify that the workload can mount and write to the volume.

yamls.tar
3.60 KB