In this RX-M Cloud Native Short Take, Christian Lacsina covers the Kubernetes Block Storage module. Christian demonstrates how to use CSI plugins in Kubernetes to enable dynamic block storage provisioning for a cluster using AWS Elastic Block Store (EBS). He demos the process of creating a Persistent Volume Claim (PVC) which triggers dynamic provisioning of a Persistent Volume (PV) via the AWS EBS CSI driver.
Video Transcript
Welcome to another Cloud Native Short Take, my name is Christian Lacsina and today we’ll take short take the RX-M Kubernetes Block Storage module. In this module we introduce the Container Storage Initiative (CSI), talk about the evolution of dynamic storage provisioning for Kubernetes, present examples and use cases of CSI plugins, and will demonstrate the use of a CSI plugin in Kubernetes.
For the demo I’m going to show the steps required to enable dynamic block storage provisioning for my Kubernetes cluster using AWS Elastic Block Storage (EBS). My Kubernetes cluster consists of a single node and in order to set up dynamic provisioning I first need to set up my CSI plugin. A CSI plugin on Kubernetes provides a “provisioner” which runs on the cluster; it’s the provisioner’s job to realize my requests for storage using the chosen backend for my storage–in this case AWS EBS. To do this the provisioner must have credentials which are ideally provided by a Kubernetes secret. For AWS EBS I needed to provide a valid Identity and Access (IAM) key which i’ve already loaded onto my cluster.
Next I need to deploy the provisioner itself and its supporting components. The provisioner runs as pods on the cluster with a managing controller running as a Deployment and a DaemonSet. Running a pod on every node in the cluster that ensures the created volumes are properly attached to each node. Our back elements are also included to ensure the provisioner can communicate with the api-server. Finally a CSI driver resource enables the Kubernetes Persistent Volume subsystem to identify the driver.
With the provisioner deployed I need to create a Kubernetes Storage Class resource that enables my Persistent Volume Claims to use the provisioner. This Storage Class identifies the provisioner using the name established by the CSI driver resource created earlier. I’ll go ahead and apply it to my cluster.
Now that i have my Storage Class in place I can create a PVC that uses the EBS CSI driver. The key line in this PVC is the Storage Class name. The Storage Class name refers to my EBS Storage Class which uses the AWS EBS CSI driver. Once i apply this PVC to the cluster it will soon bind to a brand new PV automatically. I’ll go ahead and establish a watch for Persistent Volumes and Persistent Volume Claims and I will then apply my PVC. We can see the PVC is created it’s in a pending state and shortly after a Persistent Volume is created. During this process the provisioner reaches out to the EBS subsystem on AWS itself tells it to create a PV or rather tells it to create a block storage device on EBS which best fulfills my request for storage. Depending on the storage back end you might see slight differences between your request and the provisioned PV. AWS EBS has a minimum volume size of one gigabyte so my initial request for 512 megabytes was fulfilled with a one gigabyte volume.
And that’s it! Any PVC applied to the cluster using the Storage Class will automatically provision an EBS block storage device for itself. The use of block storage devices on Kubernetes is just one of the things you’ll learn in the Kubernetes Block Storage module from RX-M. You can create your own customized Kubernetes courses with this and many other modules using the courseware builder here on the RX-M website.
That’s our Cloud Native Short Take on the Kubernetes Block Storage module! Thank you for watching!