Provision Object Storage with VAST COSI Driver

VAST COSI Driver Workflow

VAST COSI Driver lets you use the Kubernetes API to create and manage S3 buckets, and also to manage access to the buckets. After a bucket is provisioned, end users can perform object operations on the bucket.

Note: COSI buckets can be provisioned on the default VAST Cluster tenant only.

To provision a bucket with VAST COSI Driver:

1. In the VAST COSI Driver Helm chart configuration file, specify a Bucket Class that provides parameters and attributes to be used when provisioning buckets through VAST COSI Driver. You can use a predefined bucket class provided with VAST COSI Driver, or you can define one or more custom bucket classes.

2. Create and apply a Kubernetes YAML configuration file with the following definitions:

   • A BucketClaim, which is a request to create a bucket of the bucket class specified for the driver.

   • A BucketAccessClass, which provides various options and settings for bucket access requests made through the driver.

   • A BucketAccess request, which contains credentials that can be used to access the bucket.

Define Bucket Class

A bucket class (BucketClass) acts as a container for various parameters and attributes that VAST COSI Driver uses when creating buckets.

You define a bucket class in the VAST COSI Driver Helm chart configuration file.

A minimal bucket class would specify a virtual IP pool, a storage path, and a view policy, for example:

endpoint: <IP>
secretName: <secret>
<...>

bucketClasses:
  vastdata-bucket:
    vipPool: cosi_vippool
    storagePath: /buckets
    viewPolicy: my_s3_policy
    create_dir: true
<...>

Optionally, you can specify parameters that allow you to:

• Determine whether to keep or delete the bucket and the associated VMS user when the bucket object is deleted:

  deletionPolicy: "Delete|Retain"
  

• For an SSL-protected VAST cluster, enable use of HTTPS when creating the bucket endpoint:

  scheme: "http|https"
  

• Set up features and capabilities that can be configured for the bucket using the VAST REST API's /api/v1/views/ endpoint of your VAST cluster.

For more information about options that can be specified for a bucket class, see Bucket Class Option Reference.

Bucket Class Option Reference

You specify bucket class options in the Helm chart configuration file created for VAST COSI Driver during initial deployment.

Tip: In addition to the VAST COSI Driver options listed above, VAST COSI Driver can pass through parameters that are accepted by the VAST REST API's /api/v1/views/ endpoint of your VAST cluster. For the endpoint parameter reference, see VAST REST API documentation.

create_dir

This is a required option. Set this option to true.

Syntax:

create_dir: true|false

deletionPolicy

Determines the action to be taken when the bucket object is deleted:

• Delete (default). Delete the underlying bucket and associated VMS user.

• Retain. Do not delete the underlying bucket and associated VMS user.

Syntax:

deletionPolicy: "Delete|Retain"

scheme

Determines whether to use HTTP (default) or HTTPS when creating the bucket endpoint. If the VAST Cluster is equipped with SSL, set it to https.

Syntax:

scheme: "http"|"https"

storagePath

The storage path within VAST Cluster to be used when provisioning storage for COSI buckets. VAST COSI Driver will automatically create a VAST Cluster view for each bucket being provisioned.

Caution: You can specify '/' as the <path>.

This option is required when defining a bucket class in the Helm chart configuration file.

Syntax:

storagePath: "<path>"

viewPolicy

The name of the VAST Cluster view policy to be assigned to VAST Cluster views created by VAST COSI Driver.

A view policy defines access settings for storage exposed through a VAST Cluster view. For more information, see Configure VAST Cluster for VAST COSI Driver.

All view policies used with VAST COSI Driver must have the same security flavor.

If you are going to use VAST COSI Driver with VAST Cluster 4.6 or later, a view policy set for a bucket class must belong to the same VAST Cluster tenant as the virtual IP pool(s) specified for that bucket class.

This option is required when defining a bucket class in the Helm chart configuration file.

Syntax:

viewPolicy: "<policy name>"

vipPool

The name of the virtual IP pool to be used when provisioning storage for COSI buckets. For more information, see Configure VAST Cluster for VAST COSI Driver.

If you are going to use VAST COSI Driver with VAST Cluster 4.6 or later, a virtual IP pool that you specify for a bucket class must belong to the same VAST Cluster tenant as the view policy used for this bucket class.

This option is required when defining a bucket class in the Helm chart configuration file.

Syntax:

vipPool: "<virtual IP pool name>"

Define Bucket Claim

A bucket claim (BucketClaim) creates a bucket.

A minimal example of a bucket claim would include the bucket name, bucket class, and protocol specification, for example:

kind: BucketClaim
apiVersion: objectstorage.k8s.io/v1alpha1
metadata:
  name: sample-bucket
spec:
  bucketClassName: vastdata-bucket
  protocols:
  - s3

Define Bucket Access Class

A bucket access class (BucketAccessClass) is a set of common properties that VAST COSI Driver uses to set up bucket access.

A minimal bucket access class would include the driver name and authentication type, as shown below:

kind: BucketAccessClass
apiVersion: objectstorage.k8s.io/v1alpha1
metadata:
  name: sample-bac
driverName: csi.vastdata.com
authenticationType: KEY

Define Bucket Access

Bucket access (BucketAccess) represents a combination of parameters necessary to get access to a particular bucket.

A minimal bucket access block would include the name of the bucket claim, the name of the bucket access class, and the name of the Kubernetes secret that contains the credentials required for accessing the bucket, for example:

kind: BucketAccess
apiVersion: objectstorage.k8s.io/v1alpha1
metadata:
  name: sample-access
spec:
  bucketClaimName: sample-bucket
  bucketAccessClassName: sample-bac
  credentialsSecretName: sample-access-secret

After you apply the configuration file with the bucket access definition, verify that the Kubernetes secret exists and can be attached to a Kubernetes pod:

kubectl get secret
<...>
NAME                               TYPE                 DATA   AGE
sample-access-secret               Opaque               1      11s