Using Persistent Storage for your OpenShift Applications with Trident

OpenShift is a Platform as a Service (PaaS) offering built around Docker container packaging and uses Kubernetes for orchestration of containerized application deployments across a cluster. One of the exciting features of Red Hat OpenShift Container Platform 3.4, which integrates Kubernetes 1.4, is the introduction of StorageClass objects. Prior to this, storage volumes had to be pre-provisioned and manually registered as PersistentVolume (PV) objects before they could be consumed by an application. StorageClass objects enable us to specify a provisioner which creates storage volumes for your applications on demand.

What is Trident?

NetApp announced Trident, the industry’s first out-of-tree dynamic provisioner for on-premises enterprise storage, last December. Trident integrates with Kubernetes’ Persistent Volume framework and provides a unified interface for storage provisioning from NetApp ONTAP and SolidFire storage systems. It is deployed as a highly available Kubernetes “deployment” and communicates with the API server to process pod storage requests in the form of Persistent Volume Claims (PVCs).

Using Trident as your provisioner in OpenShift

A StorageClass not only specifies the storage provisioner but also allows us to define different tiers of service. Administrators can create StorageClass objects comprised of different media types, e.g. HDD or SSD (in case of ONTAP based systems), QoS bands (for SolidFire based systems), whether snapshots or thin provisioning are required, etc.

Here’s an example of a StorageClass called “gold”:

Once that class is registered with Kubernetes, Trident will see any persistent volume claim (PVC) created by a user to request a persistent volume for their pod that requests a “gold” volume of a specific size.

In response to a new “gold” PVC request, Trident will choose one of the backend storage systems that are registered with it that support both SSD media and thin-provisioning and have enough space to accommodate the request, provision the volume and automatically register it with Kubernetes for use by that pod. For example, you may have registered both ONTAP AFF and SolidFire clusters. Trident may use either one of those systems to fulfill the request.

Creating a PVC

Users request dynamically provisioned storage by including a storage class in their PersistentVolumeClaim. This is done using the volume.beta.kubernetes.io/storage-class annotation. The name of this annotation must match the name of the StorageClass created by the administrator earlier.

To request a volume with “gold” storage class features, a user would create the following PersistentVolumeClaim:

Note: The PVC object here also allows us to specify some of the properties related to the newly created PV. The reclaim policy is set to Retain which tells Kubernetes to retain the volume after it is released from its claim.

Talk is good, doing is better

Let’s deploy a sample application which has persistent storage requirements. Here we deploy a 2-tier web application consisting of a Node.js server and MongoDB database. To store page count data persistently, the MongoDB service makes a PersistentVolumeClaim request. Trident dynamically provisions an NFS volume from the configured ONTAP backend and registers it as a PV, which is then claimed by the MongoDB PVC. We verify that the data persists by deleting the database pod and ensuring that the data is consistent.

Conclusion:

For more information on installing and using Trident, be sure to check out this video series. Also, feel free to reach out using the comments below, on Slack, or on the GitHub issue tracker for Trident.

Amit Borulkar
Amit is a part of the Converged Infrastructure Group at NetApp where he focuses on all-things OpenStack, OpenShift, and infrastructure automation tools, such as Puppet and Chef, with FlexPod.

Leave a Reply