Kubernetes Storage

Kubernetes Volume Cloning with Cloud Volumes ONTAP

[Cloud Volumes ONTAP, DevOps, Data Cloning, Kubernetes, Master, 4 minute read, Kubernetes Storage]

What should you do if you’re working in Kubernetes and need a test copy of an existing persistent Kubernetes storage volume, let’s say one you might use for software development testing? Normally, you’d need to allocate a new persistent volume (PV) and then restore a backup, a process that takes up a long time and consumes a lot of storage space. This method of Kubernetes volume cloning is too slow to keep up with the pace of development and too expensive given the number of clones created in every dev/test cycle.

Kubernetes volume cloning is a much easier process with NetApp Trident and Cloud Volumes ONTAP. With Cloud Volumes ONTAP you can instantly create highly-space-efficient, writable clones of existing PVs in direct response to persistent volume claims (PVCs).

In this article, we examine the way in which NetApp Trident facilitates persistent volume cloning, and how this is delivered by Cloud Volumes ONTAP using NetApp FlexClone® technology.

Kubernetes Volume Cloning Challenges


Creating test copies of production data is very often a requirement for DevOps engineers implementing CI/CD pipelines or setting up staging clusters for pre-production testing. Automated software test suites will often mutate the data that they access, which means that a fresh copy of the data is required in order to repeat the testing, with test cycles sometimes executed hundreds of times. Ensuring faster TTM (Time To Market) and the delivery of high quality software relies upon developers working in parallel and executing tests as often as required.

Restoring data backups is not a scalable solution for creating test data sets: with the size of the source data involved it just takes too much time to perform a restore. This leads to reduced developer productivity when multiple, up-to-date copies of PVs are required, which also have to be refreshed frequently. Using this approach also means that the amount of storage used to develop and support an application will be many times greater than the storage requirements of the production environment, causing a significant increase in cloud storage costs. That’s not something any developer wants to get blamed for.

The time taken to perform a restore and the storage space it uses can both be very wasteful, as usually most of the restored data remains unaffected by the software testing and must be recreated simply to bring the data to a consistent point or to get an up-to-date copy. In contrast, not only is NetApp FlexClone able to instantly clone a source volume of any size, it also does so with zero storage penalty for any storage size required. NetApp Trident helps you take advantage of this for PVs in a Kubernetes cluster.



Kubernetes Volumes Cloning with NetApp Trident

NetApp Trident is a provisioner for Kubernetes that performs dynamic storage provisioning using Cloud Volumes ONTAP for AWS or Azure, or other on-premises ONTAP storage systems. The major advantage of using Trident is that containerized applications can benefit from NetApp’s enterprise data management features. One of these features is data cloning which can help speed up TTM and reduce storage footprint and costs.

This is how Kubernetes users can benefit: instead of always provisioning new PV in response to PVC, using Trident the user can clone existing volumes. To instruct Trident to create a clone, simply give it the name of the persistent volume claim that was used to provision the original PV, which must also have been allocated through Trident. This information is provided through a metadata annotation on the PVC that is requesting the volume clone.

Persistent Volume Claim

In the background, Trident will find the ONTAP volume that was used to provision storage for the original PVC and then use NetApp FlexClone to perform a data cloning operation. Clones are created by using a snapshot on the parent volume. Both the clone and parent volumes are free to accept changes to their data, which are written to new blocks using a redirect-on-write mechanism that protects blocks locked by a snapshot from being overwritten. Using this technique, the clone requires negligible storage space when it is first created, and only grows with the changes that are made to it.

By using the default reclaim policy of delete, the clone will automatically be deleted when the pod using it is destroyed. This can be used to conveniently clean up any allocated storage at the end of a round of testing, for example. Trident also supports an optional annotation to split the clone from the parent volume it is associated with. This turns the clone into an independent copy of the data, which means the space efficiencies discussed previously will be lost, however, this can be more suitable in scenarios when the clone will undergo a lot of changes, or when the state of a volume is needed to provide seed data for a new requirement.

Conclusion



Persistent volumes provide storage for pods in a Kubernetes cluster, however, the provisioners used to create them do not typically provide mechanisms to stand up copies of existing volumes for testing. NetApp Trident is able to achieve this through a simple set of annotations on a persistent volume claim, which leverage the capabilities of Cloud Volumes ONTAP to instantly provision writable clones of existing PVs. Data cloning is just one of Cloud Volumes ONTAP’s cost-cutting features.

New call-to-action
-