Transforming StorageClasses with Kasten

In previous posts we have deployed various StorageClass’s, namely the VMware CSI driver and the NetApp Trident CSI driver. As the names suggest they use different underlying storage technologies, The VMware CSI driver uses VMware datastores and the NetApp Trident CSI drivers uses NetApp.

So, what happens if you wanted to move between two storage types? obviously, one does understand the other so simply moving the backend storage won’t work, there is also the relationships between Persistent Volumes and PersisentVolumeClaims that need to be taken into account and suddenly this all seems far too difficult…BUT FEAR NOT, Kasten has the answer leveraging one of their capabilities called Resource Transforms.

This came into fruition when I wanted to move some applications from one Kubernetes stack to another which in this case had different StorageClasses and thus different underlying storage in two different countries I might add. Shout out to Ben Thomas for being my DR site 🙂

Concept

As mentioned, I have two sites, Australia and New Zealand configured almost identically apart of the aforementioned StorageClasses.

The concept here is to backup an application on my Kubernetes stack in Australia and migrate it to New Zealand leveraging Kasten.

This will be done by backing up the application, exporting the snaphots to Wasabi S3 Storage, importing the backups on my NZ cluster and restoring the application as well as changing the StorageClass inline to the restore.

Sound fun? sure does! so let’s get to it..

Backup to S3

  • Add a Location profile in Kasten, you can do this by following Wasabi’s documentation located HERE.
    Location profiles are used to create backups from snapshots, move applications and their data across clusters and potentially across different clouds, and to subsequently import these backups or exports into another cluster.
  • Repeat this step on the second cluster aswell so that both clusters have access to the same S3 bucket

  • Configure your backup policy in Kasten to Export your snapshots to your desired location profile.

  • When we run our backup again, we can see that there is now an export step.

Checking our Wasabi bucket we can see the K10 data has uploaded successfully.

Importing Backups

  • Navigate back to the policy and copy the import code, this will be used on the secondary cluster.

Let’s move to the secondary cluster and create a new import policy.

  • Navigate to Policies
  • Create a new Policy
  • Provide the policy with a name and select “import”
  • Paste the import token we copied earlier from the first cluster and select the Location profile we mapped earlier.
  • Run the import to import the backups so they are available to the secondary cluster

Restoring the application

Now for the fun bit and the secret sauce. We are now at the step where we need to change the storageclass and restore the application.

  • We start off by navigating to applications and selecting our app on the second cluster where you imported the backups.
  • Click the three dots and select restore.
  • select a restore point, this will pop up a window where we need to provide some additional information.
  • Select “Apply Transforms to restored resources” and add a new Transform.
  • Drop down examples and select Change StorageClass
  • This will auto-populate some field for us, Edit the operation and add the new Storageclass name. (You can get this by running kubectl get storageclasses.storage.k8s.io in your cluster)
  • Running a quick test, we can confirm that the Transform is working as we expect.
  • Click create Transform which will add it to the restore job
  • Click restore to kick off the restore
  • After a few minutes we can see the restore has been completed successfully and that our storageclass has been transformed on the fly during the restore.
  • We can confirm by checking the PersisentVolumeClaims and the Persistent Volumes that they are indeed using the new storageclass on the second cluster.

Logging into our NetApp array we can confirm that the PVC matches our newly created volumes

Conclusion

Moving apps has never been simpler; we have successfully migrated our application and all its persistent data from a cluster in Australia to our Disaster Recovery node in New Zealand! Kasten’s capabilities are impressive, and I’m continually astounded at how easy it is to use. Now, to move the rest of my workloads!

I hope that this helps you on your journey and as always, keep learning.