the HPE CSI Driver for Kubernetes to perform Dynamic Provisioning of Persistent Storage.
My name is Michael Mattsson, I'm a Tech Marketing Engineer with Hewlett Packard Enterprise.
Before we dive in, I want to walk through a few powerpoint slides on how dynamic provisioning for Kubernetes works
and showcase a few of the API objects that we work with
when provisioning persistent storage for Kubernetes.
Imagine for a second that we have a Kubernetes cluster
with any of the in-tree storage plugins or we're using a cloud provider or any vendors' CSI driver.
You have a number of different API objects at your disposal.
The first thing that you need to declare on the cluster is something called a StorageClass.
A StorageClass is implementation specific, whether you're using a cloud or a CSI driver or any of such sorts,
you need to have something that describes the provisioner,
the provisioner name and the different parameters that are specific for that provisioner.
The next thing you would use is something called a PersistentVolumeClaim and
this is where the end-user comes in where he declares his needs for his application.
In this particular case here the user requests a 100GiB volume,
and request that from a particular StorageClass, if the cluster has a default StorageClass,
on the cluster you don't have to declare the StorageClass.
You also specify the AccessMode, since we're using the HPE CSI Driver which is a block storage plugin,
we're going to use ReadWriteOnce.
Once you've declared a PersistentVolumeClaim on the cluster, the dynamic provisioner will listen for that particular event.
And basically create a new PersistentVolume that matches the StorageClass.
The StorageClass is like a cookie cutter template.
The PersistentVolumes in itself describes something we would call an external volume.
Once that external volume has been declared on the cluster, what Kubernetes does
is basically binds the PersistentVolume with the PersistentVolumeClaim.
At this stage, the volume will be ready for use by the user
so the user can reference the PersistentVolumeClaim from his particular workload.
I'm switching over to my terminal and I'm just going to show that we have the HPE CSI Driver already installed.
I haven't declared any StorageClasses or I don't have any way to reference my backend storage system yet,
but we're going to create those objects.
First I'm just going to do a Helm list in namespace kube-system
"-o yaml" to show you that the driver is already installed.
Next we need declare something called a Secret. The Secret basically just references the backend storage system that I have in my lab.
It contains the username/password and things like that to allow me to create PersistentVolumes from that system.
The next thing I need to create is a StorageClass.
This StorageClass basically references the Secret I just created.
I'm going to give it a name. I want to make it the default StorageClass.
All my users PersistentVolumeClaims will be declared against this StorageClass.
I want to allow volume expansion as I want to show you how that works as well.
And there's some other CSI provisioner specific things, I want to create an XFS volume,
and I want to specify mount options for the volume.
In this particular case I'm going to create a 32GiB volume.
AccessMode ReadWriteOnce,
and no extra flavor, extra color or extra declarations, I'm just asking the cluster for a 32GiB volume.
So you can immediately see that the volume has been bound.
We'll have a physical volume that is being referenced from my PersistentVolumeClaim I named "data"
and my PersistentVolume is "pvc-" and the long UUID that we can see here.
The next thing I'm going to declare is a workload.
This is a single replica Deployment.
It's using a very simple command called "ioping" and
and it basically just does an IO to a mount point or a block device or a file or anything like that.
The default behavior of this particular instance of ioping
it will simply do an ioping on the /data mount point.
So we're going to see that in the logs afterwards.
And you can also see here I'm referencing from my container spec a volumeMount
that references my PersistentVolumeClaim I named "data".
65
Now I'm going to get the logs from this Pod and see what the container is doing.
We can see here that the ioping application is issuing 4K IOs,
on the "/data" mount point and we can also see that this is an XFS filesystem,
it's referencing a multipath device of 32GiB.
That matches what I asked the cluster to provision for me, so we're all good here.
I'm also going to show you how to resize, or
more or less expand and volume, there's no shrink,
there's only expand. So we can see here that I'll do a
"kubectl exec" a I can see that my multipath device is indeed 32GiB.
And then I'm just going to edit the PVC.
You go down to the "spec" and look at resource, requests, storage.
It's 32GiB at the moment and if I set that to 64GiB,
the CSI resizer will call the HPE CSI Driver to resize the backend volume
and then go over to the CSI node driver to do a volume expansion.
And we can already see the PVC has been expanded.
And we should then be able to do a "kubectl exec" inside our Deployment again and see that
the filesystem has actually been expanded.
And there we go, 64GiB!
As a responsible Kubernetes user, I'm just going to clean up after myself,
if you're interested in learning more about HPE storage and the HPE CSI Driver for Kubernetes
Visit hpe.com/storage/containers.
See you next time!