Learn Kubernetes External Storage Provisioner by Looking at How Local Path Provisioner Works
By: Mohamad Fadhil
Tags: DevOps, Kubernetes, Storage, Distributed Systems, Software Engineering

Photo by Patrick Lindenberg on Unsplash

For the past month, I’ve been researching for bare metal k8s distribution to use at our company. I’ve been using Rancher’s k3s, lightweight Kubernetes distribution, and I find it very light and convenient to setup. Together with a bunch of built-in tools bundled with k3s, I like its super cool storage provisioner the most. Thank you, Rancher, you guys rocks.

What we’ll learn here

What it takes to provision a PV in Kubernetes dynamically

What is Rancher’s Local Path Provisioner

How to use Rancher’s Local Path Provisioner

How dynamic storage external-provisioner works

Frankly speaking, I find it a bit hard for commoners like me to get more information about this kind of stuff unless I work on the Kubernetes project itself or storage-related system company. Otherwise, I have to make extra effort to examine Open-Source projects like this by myself. I am sharing this to help people like me to get started to know more about Kubernetes storage and external-provisioner specifically.

How Kubernetes Dynamic Storage Provisioning work

I recommend you to read documentation from IBM to know in detail how storage works in Kubernetes.

In short, a user can ask a storage space for their application, and the Kubernetes system will magically prepare the storage for them. The storage can come in any form, i.e., RAM, Local Disk, Cloud Block Storage, etc. depending on how the developers’ request.

This is how Kubernetes attach a storage volume into a pod:

What happens when you request for Persistent Volume Claim (PVC)

A user (developer/administrator) creates a PVC The storage device (Storage Class) listen to that request The storage provisioner creates a PV PVC now Bounded to the PV The pod created is linked to the PV created

The role of storage provisioner here is to help you provision the PV. There are many provisioners available out there, both open source and closed source. If you are using managed Kubernetes service (i.e., AWS EKS, GKE, AKS), the service provider will likely handle step #2 and #3 for you already. Therefore, you do not have to worry about that. They are tightly integrated with their block storage offerings (e.g., Google Cloud Persistent Disk, AWS EBS, etc.)

The problem happens when you are using the bare-metal Kubernetes cluster where you have to provision and manage the storage by yourself. There are several options available when you’re on bare metal setup:

Use Rook.io or Rancher’s Longhorn (thanks again) to set up a clustered storage within the Kubernetes cluster

(thanks again) to set up a clustered storage within the Kubernetes cluster Use networked storage cluster running on Ceph or GlusterFS

running on Ceph or GlusterFS Use proprietary solutions like PortWorx, StorageOS, OpenEBS

like PortWorx, StorageOS, OpenEBS Use Local Persistent Volume or HostPath on the local node

or on the local node many other ways

I am interested in using Local Persistent Volume for my setup because of its speed. There’s one caveat when using clustered network storage solution (e.g., Ceph/ GlusterFS / Rook.io), the IO performance will drop by ~60% of its original performance because of data replication. Still, of course, you don’t have to worry about data loss when the disks/nodes are missing. However, the Local Persistent Volume feature just released in official Kubernetes v1.14, and it DOES NOT come as dynamic storage provisioner. This means you have to beforehand provision a PV and let the Kubernetes engine bound to the PVC, instead of letting the Kubernetes system provision the PV for you. I wonder if they are working to make it as dynamic storage provisioner in the future.

Introducing Local Path Provisioner

This is where Local Path Provisioner comes in. Local Path Provisioner provides its user the convenience to dynamically provision Persistent Volume (PV) based on Persistent Volume Claim (PVC). It utilizes the local storage in each node. Based on the user configuration, the Local Path Provisioner will create hostPath based persistent volume on the node automatically. It works just fine for my use case for now.

How to use Local Path Provisioner on your local cluster

Step 1: Install the Local Path Provisioner in your cluster (Skip this if you are using k3s)

Step 2: Prepare a PVC

Step 3: Create a volume-test pod

Step 4: Check for the PV being created for you