Provisioning Hedvig Storage with Kubernetes

By Suhani Gupta | | Cloud

As containers gain momentum as an ideal way to build, ship, and run applications, organizations are now investigating ways to simplify and automate container deployment, scaling, and management. This has given rise to orchestration tools available that serve this purpose. Kubernetes – a technology that was born within Google – is one of the solutions vying for dominance in the container management space. At Hedvig, containers are one of our areas of focus and so we’ve explored how to plug our software-defined storage platform into not just the likes of Docker and CoreOS, but also with orchestrators like Kubernetes. Here’s what we’ve learned.


Kubernetes is Google’s open source orchestration platform for Linux containers. It is being used by development and operations in companies for automated, scalable management of containerized applications. Kubernetes provides flexibility to developers for efficiently constructing a service and managing it discretely. While using Kubernetes, a developer can think in terms of data center resources instead of worrying about machines or configuration files. Kubernetes, in essence, is an API to manage your data center.


Most production applications need an underlying storage solution to store and share data. Kubernetes provides a range of persistent volume storage plugins to help facilitate this. Before discussing how to provision Hedvig storage, here is an explanation of how Kubernetes provisions persistent storage.

Kubernetes uses Persistent Volumes (PV), which is networked storage provisioned by an administrator. It is a resource in a cluster. PVs are volume plugins, but are independent of the lifecycle of pods. To request storage for pods, and in turn containers, you can use Persistent Volume Claims (PVCs). PVCs consume PV resources based on storage size and access modes.

Kubernetes provides a higher level of abstraction for applications using pods to simplify application deployment and management. Pods serve as units of deployment, horizontal scaling, and replication. Colocation (co-scheduling), shared fate (for example, termination), coordinated replication, resource sharing, and dependency management are handled automatically for containers in a pod. Pods uses PVCs to provision storage for containers. PV is bound to a single project/namespace, and PVCs are project/namespace scoped.


Hedvig uses NFS or iSCSI persistent volumes for provisioning shared storage for pods and containers in Kubernetes. An NFS or iSCSI virtual disk allows a storage volume share to be mounted on a pod and is preserved when the pod is removed; hence, the volume can be handed-off between pods. The only difference is that NFS is multi-writer, while iSCSI is multi-reader and single-writer only.

As this storage can be provisioned on any node in the Kubernetes cluster, you do not need to worry about spawning containers on a specific node. As a prerequisite, you should have already set up a Hedvig cluster and a Kubernetes cluster.


Steps for provisioning Hedvig Storage:

  1. Create an NFS or block virtual disk in the Hedvig WebUI.
  2. Add an export to the Hedvig Storage Proxy for an NFS disk, or add a LUN to the Hedvig Storage Proxy, and give access to all nodes, including the master in the Kubernetes cluster, for a block disk.

Steps to be performed on Kubernetes master:

  1. Create PVs and bind them to PVCs that use Hedvig storage.
  2. Create pods and respective services required for the application. This will have your application up and running supported by Hedvig storage in the backend.
  3. Write some data based on the application.
  4. Remove all services, pods, PVCs, and PVs.
  5. Recreate all of them, and verify that the data written is persisted.

What makes Hedvig unique in this type of deployment is that like Kubernetes and Docker (and solutions like Red Hat OpenShift that incorporate both), Hedvig is itself a scale-out, distributed solution. It’s elastic, just like a container-based environment – and it has the added flexibility of supporting a complete set of storage capabilities, all selectable at a per Virtual Disk level – which also translates to a per container level. This flexibility is key for containerized application deployments at scale.