At Dell, we offer a variey of storage arrays and protocols to be consumed by the kubernetes platform, the focus of today’s post, is a new integration with the s3 protocol (object), using our ObjectScale array
Container Object Storage Interface (COSI) is a standard for provisioning and consuming object storage in Kubernetes. Dell ObjectScale COSI driver is released in Tech Preview as part of the CSM 1.8. The Dell COSI drives will provide the ability to dynamically provision and manage Object Storage from Dell ObjectScale Storage.
In this demo we are going to install and configure the Dell ObjectScale COSI driver into a Kubernetes cluster and use the Dell ObjectScale COSI driver to dynamically provision and use the Object Storage from Dell ObjectScale inside our application. For this demo a Kubernetes cluster and Dell ObjectScale 1.2 deployed. You can read about the ObjectScale 1.2 in our previous blog here and here.
Install the COSI CRD and the COSI controller manager into the Kubernetes cluster.
COSI defines below CRDs:
COSI is made up of three components:
COSI Controller Manager
Before installing the Dell COSI driver, we need to make sure the COSI CRDs and the COSI controller manager is installed into the Kubernetes cluster.
Add the Dell Helm Repo
We are installing the Dell ObjectScale COSI driver using the dell helm charts, so we will add the Dell helm repo into our management machine.
Create the COSI driver configuration file.
Create the ObjectScale configuration file, get all the necessary values from the ObjectScale console.
Install the Dell ObjectScale COSI Driver
Create Bucket Class
The BucketClass is very similar to the Storage Class. BucketClass represents a class of Bucket resources with similar characteristics. It is used to specify the driver for creating Buckets, and for configuring driver-specific parameters. Admins will be creating the BucketClass, and the end users can provision the Buckets by creating the BucketClaim.
Create Bucket Access Class
BucketAccessClass represents a class of BucketAccess resources with similar characteristics. Admins will be creating the BucketAccessClass, and the end users can use the bucket access class to create bucket access which will give the permission for accessing the bucket.
Create Bucket Claim
BucketClaim represents a claim to provision a Bucket. Uses will be creating the BucketClaim using the BucketClass to provision the Bucket in the ObjectScale.
We can verify the bucket created inside the ObjectScale, after the application creates the Bucket Claim.
Create Bucket Access
BucketAccess resource represents an access request to generate a Secret, that will allow you to access Object Storage.
After the successful creation of the bucket access, a secret with the bucket access details is created. This secret will be used by the application to access the S3 bucket.
We are deploying a demo application; below is the application manifest. The application will be uploading files in to the S3 bucket. The secret created by the bucket access is mounted inside the application pod. The application will be using the bucket access secret to access the S3 bucket created inside the ObjectScale.
Once the application pods are in running state, we can verify the S3 bucket content using S3 browser, and we can observer the files are being uploaded in to the S3 bucket by our demo application.
You can see a demo below, showing how to configure the driver