Author: Afan Rasool


In this blog, I will talk about provisioning persistent storage for OpenShift workloads, on a NetApp appliance (supported versions of ONTAP On-Prem and Cloud, Element and SANtricity). Trident by NetApp, is native to OpenShift/Kubernetes and can handle storage requests dynamically. NetApp Trident enables persistent volumes to be provisioned using your existing storage infrastructure, which complements the container orchestration capabilities of OpenShift with NetApp’s enterprise-grade storage solutions.

Persistent Storage on OpenShift

Before I go into the details of Trident and how it functions, let’s discuss the concept of Persistent Storage in the OpenShift/Kubernetes world. While it’s true that developers are more inclined towards creating stateless applications for deploying on OpenShift, there are many use cases where the data needs to persist beyond the life of a pod. OpenShift uses the concept of Persistent Volumes (PV) and Persistent Volume Claims (PVC) to manage the storage layer. Each PVC, which is a request by a user for Persistent Storage, is bound to a PV (A Kubernetes/OpenShift resource which contains information of the volume created on the storage backend). In the case of static provisioning, the cluster administrator needs to plan resources and pre-allocate PVs to be consumed by the users in the cluster. Dynamic provisioning in an OpenShift cluster reduces a lot of the administrative overhead involved in manually creating persistent volumes, both as and when they are required

Dynamic Provisioning with NetApp Trident on OpenShift

For NetApp backends, Trident seamlessly provisions PVs on request without any administration. Depending on the reclaim policy set on OpenShift, it can also clean up storage on the backend, once the PVC is deleted from OpenShift. Automatically allocating and deallocating persistent volumes at the request of the user, not only automates the cluster administrator’s job but can also help to reduce wasted storage that is allocated but never used.

A recommended setup for Trident is to run it in a separate project, created by the cluster administrator. The installer sets it up as a single pod deployment. It is required to run it as a single pod and mutiple replicas, for high-availability, are not supported as of now. Several NetApp backends can be set up with Trident at the same time. The backend type, to fulfil a specific storage request, is defined by the StorageClass being used (more on that later).

Trident needs a PV itself for its etcd (to store its metadata). The way the installer handles this is that it spins up an ephermal Trident pod which sets up a Trident pod with persistent storage. As part of the process, it creates a PVC and a corresponding PV is bound to it dynamically.

For this test cluster, I used Cloud ONTAP as my storage backend. If we turn to the onCommand Cloud Manager to look at the volumes in the test cluster I created, it can be seen that a corresponding volume for its etcd has been created by Trident on the backend. The naming convention it uses for the volumes on the backend is <prefix>_<PVname>. Prefix by default is set to trident and in this case, the name of the PV on OpenShift is trident as well.

After setting up Trident , the cluster administrator can create StorageClasses to use with Trident, and once these are set up, the users of the cluster can make a PVC for their apps and it will be fulfilled dynamically without any preallocation of PVs or approval from the administrator. This abstracts away the storage layer, allowing the users to request storage without having any low level knowledge of the underlying storage infrastructure.

Following is an example of a StorageClass for OpenShift with Trident as the provisioner. In this example we set it up as the default StorageClass which means that if a StorageClass is not specified, this would be used by default.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: basic
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: netapp.io/trident
parameters:
  backendType: “ontap-nas”
  media: “ssd”
  snapshots: “true”

The Trident installer also comes with a handy tridentctl command line tool which allows administrators to review and manage the storage resources the cluster is using. Example usage of tridentctl:

  • Adding a new backend to Trident from a file describing the properties of the backend:

    $ ./tridentctl -n trident create backend -f backend.json
    
    
  • Viewing logs:

    $ ./tridentctl -n trident logs 
    

Conclusion

If your enterprise has already invested in a NetApp Storage solution and is looking to make a move to microservices or a container orchestration platform such as Red Hat OpenShift, NetApp Trident makes the transition much easier by providing the tight integration needed to utilize your existing storage infrastructure for persistent storage needs of your container workloads.

Interested in finding out more about NetApp Trident and RedHat OpenShift? We would love to hear from you!

//take the first step

Tagged:



//comments


//blog search


//other topics