Adding Kubernetes Storage Platform Challenges

Adding a new storage platform to Kubernetes comes with a set of challenges. First is the inclusion of a native storage driver. Kubernetes uses an “in-tree” solution where the code used for the storage platform must be merged into the core Kubernetes code. This requires your code to pass rigorous tests, live up to a “Google” standard to be merged, and perpetually keep it up to date. An alternative solution uses the FlexVolume interface to perform basic attach/detach operations (which was done with FlexREX). This uses an outside integration but can’t perform all operations necessary for the volume lifecycle.

The big news this week is stateful applications running on a Kubernetes cluster can now consume data stored on ScaleIO volumes!

Unfamiliar with ScaleIO?

ScaleIO creates a server-based SAN (storage area network) by taking a local application server’s DAS resources and converting them into block storage to enable scalable high-performance storage. ScaleIO converges storage and compute resources to create a single-layer architecture. An alternative two-layer option allows application and storage to maintained separately, depending on what works best for a given application. Read More.

This is a big milestone for our team as ScaleIO becomes part of the core Kubernetes code and a first class storage provider. Customers looking to pursue containerized workloads with Kubernetes can utilize ScaleIO as a native storage solution. This also applies to RedHat OpenShift, which is built on Kubernetes.

The {code} contribution for this effort started in November 2016 and targets ScaleIO version 2.0.x. A volume driver was implemented using the Kubernetes Volume Plugin API to allow the usage of ScaleIO for Kubernetes. Being part of the Kubernetes source tree means the ScaleIO storage operations are part of the standard distribution of Kubernetes.

Storage orchestration and volume lifecycle tasks can take place in a multitude of ways for applications to access ScaleIO volumes from Kubernetes:

  • A PersistentVolume (PV) is a label used for a pre-provisioned volume, normally done through ScaleIO toolsets, that can be called directly from a pod deployment or replica set to have a highly available container architecture. Furthermore, cluster users may define PersistentVolumeClaims (PVCs) to create storage requests with specific characteristics. Administrators can utilize claims to allow the storage provisioning and lifecycle to be maintained independently of the applications consuming storage. A background process will satisfy claims from an inventory of persistent volumes.
  • Dynamic provisioning is a mechanism that allows storage volumes to be created on demand, rather than pre-provisioned by an administrator. The first step is creating a storage class and creating a PersistentVolumeClaim that utilizes the storage class. Now the deployment of a pod that uses the PVC will dynamically create the volume from ScaleIO and mount it to the container.

This integration opens a new opportunity for those running Kubernetes in on-premise data centers. It allows utilization of your commodity x86 server hardware for very high performance and highly available storage for running stateful apps in containers.

Want to learn more?

Visit the ScaleIO Volume Example in the Kubernetes repo and view the requirements and instructions needed to deploy pods with persistent volumes. Look for an addition to the {code} Labs on building a Kubernetes and ScaleIO cluster once Kubernetes 1.6 has been released.