Getting started with the Kubernetes CSI driver

The purpose of this post is to provide an introduction to “Kubernetes CSI” with examples you can use to build your own projects. Before we start, if you need to build your own Kubernetes cluster to follow along this write up you can follow these instructions. The files for this blog post including the “simplog” Python code are in the “CSI” folder of this GitHub repository

https://github.com/cermegno/kubernetes-csi

Prior to CSI, Kubernetes provided in-tree (ie as part of the core code) plugins to support volumes but that posed a problem in that storage vendors had to align to the Kubernetes release process to fix a bug or to release new features amongst other problems.

CSI (Container Storage Interface) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes. Using CSI, third-party storage providers such as DellEMC can write and deploy plugins exposing new storage systems in Kubernetes without ever having to touch the core Kubernetes code. This gives Kubernetes users more options for storage and makes the system more secure and reliable.

CSI introduces the three important concepts PV (Persistent Volume), PVC (Persistent Volume Claim) and SC (Storage Class). These are used to provision storage dynamically to pods in Kubernetes. The process is depicted in the diagram below and consists of 3 steps:

1. An admin installs the driver and defines a Storage Class which essentially maps to a certain quality of service the underlying storage provides. It is a similar concept to VMware’s VASA
2. A developer creates a Persistent Volume Claim. This is the “right to use” a persistent volume. At this point an existing volume reserved for that PVC or a new one is created on the fly
3. The developer deploys an app and mounts the Persistent Volume to the pods by referencing the PVC

For the purpose of this lab our Kubernetes cluster is attached to an XtremIO over iSCSI. CSI driver installations vary from vendor to vendor and between products. I personally find the CSI implementation to be one of the easiest. For instructions on how to install it you can follow:

https://github.com/dell/csi-xtremio-deploy

The CSI installation installs a number of pods in the “kube-system” namespace. You can describe them if you want. Other CSI implementations like VxFlexOS create their own namespace and create their infrastructure pods there

kubectl get pod -n kube-system

The controller and node CSI pods work together to ensure that when a PVC is created a volume is created in the storage array and it is presented to Kubernetes as a PV

Now let’s examine what storage classes have been created and verify that no pv or pvc exists in our namespace

kubectl get sc

You can use “kubectl describe” to see more details about a given object such as a storage class. Notice parameters such as “ReclaimPolicy”

kubectl describe sc csi-xtremio-sc

For this exercise I will use a small application I wrote in Python. It is simple logging application called “simplog”. I find it helps understand the concepts because the log is a plain text file, which is more accessible than other examples I have seen out there. With this app there is nothing preventing you from opening a terminal session to your pod and seeing the contents of the file. A few details about the app:

• The app writes an entry to a log every time it gets a hit
• A folder called “data” holds the log and will mount to an XtremIO volume if it exists. “data” is a subfolder of the folder that contains the app
• If the folder is not present it simply returns “log file not found”
• The app serves a second “/dump” route that reads back all log entries
• The app is available in a containerized form in Docker Hub. So you can test it with Docker if you want as well. Find it at: https://hub.docker.com/r/cermegno/simplog

This is the behavior of the app if the “data” folder doesn’t exist

And this is the behavior if it exists. The counter increases with every hit

Show the dump function here as well

The first step is to create a PVC. The following YAML file “simplog-pvc.yml” will create a 5GB Volume in XtremIO and make it available to Kubernetes as a Persistent Volume

Let's "apply" this YAML file and see what it does

kubectl apply -f simplog-pvc.yml
kubectl get pvc
kubectl get pv

At the beginning you might see that the status is pending as it will take a few seconds to complete. If all goes well, you should see that a PVC and PV have been created

If we look at the XtremIO GUI you can see that the volume has been created, the display name is the same as the PV name in Kubernetes. You can also see that it hasn’t been mapped yet.

The next thing we need to do is to deploy our application by applying the following YAML file

Let’s apply and watch the pods coming up

kubectl apply -f simplog-deploy.yml
kubectl get pod

As you can see the pod has been created

Check the XtremIO GUI and verify volume has been mapped

The final step to make expose it by running this service YAML file

Let's apply it

kubectl apply -f simplog-service.yml

Now we can use browser to see app

http://<kubernetes_IP_addr>:<NodePort> 

We can see what’s happening by attaching a terminal session to the pod and explore the file system

kubectl exec -it <your_pod_name> /bin/bash
cat /app/data/log.txt

Now let's see how the volume' lifecycle differs from the pod's. We could try deleting the pod directly to force Kubernetes to create a new one to satisfy the “desired state” expressed in the deployment. Before deleting it make a note of the latest value of the counter that the web app displays

kubectl get pod
kubectl delete pod <pod_name>
kubectl get pod

Verify that the volume is still there with “kubectl” and in XtremIO

kubectl get pod
kubectl get pv

Finally apply the deployment again and validate that the counter picks up from where it left

kubectl apply -f simplog-deploy.yml