The recently introduced resource transformations in Backup and Recovery for Kubernetes enable you to modify a resource as it is being restored. This is useful when the restored version needs to differ from the original — for example, changing a virtual machine's IP address when restoring it to a different network.
We can use the following operations to modify resources:
- add: Add a value to a resource.
- copy: Copy a value from one path to another.
- move: Move a value within a resource.
- remove: Remove a value from a resource.
- replace: Replace a value within a resource.
- test: Test an operation before performing it.
Note that modifying PersistentVolumeClaims and Namespaces by resource transformations is currently not supported.
The destination namespaces can be specified during the restore process, though.
In this blog post, we’ll walk you through two restore scenarios using resource transformations using the Console UI:
- scale up and application during restore
- restore a virtual machine into the Stopped state
We also show you how to create resource transformation templates in the UI.
Scenario and prerequisites
To demonstrate both scenarios, we have two OpenShift clusters pu-ocp1 and pu-ocp2 discovered in Backup and Recovery already. NetApp Trident is already installed and configured on both clusters, and the local Trident Protect version was already upgraded to its latest version directly from the Console (supported from Trident Protect 26.05 onwards).
Rescale an application during restore
To demonstrate how to use resource transformations to rescale an application during a restore, we have installed a simple Alpine application on the pu-ocp2 cluster:
$ kubectl get all,pvc -n pu-alpine
Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+
Warning: kubevirt.io/v1 VirtualMachineInstancePresets is now deprecated and will be removed in v2.
NAME READY STATUS RESTARTS AGE
pod/alpine-85cb86d5fb-rdv67 1/1 Running 1 86d
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/alpine 1/1 1 1 86d
NAME DESIRED CURRENT READY AGE
replicaset.apps/alpine-85cb86d5fb 1 1 1 86d
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
persistentvolumeclaim/alpinedata Bound pvc-a10a2d24-c778-4a08-9964-7dbf8390c0a3 2Gi RWX ontap-rtp-a800-nas <unset> 86d
The Alpine app is already protected in Backup and Recovery as application pu-alpine-ocp2 with a protection policy.
Let’s start a restore in the usual way be selecting View and Restore from the Actions menu to the right of the application in Inventory.
We pick the latest restore point from the list to restore from and fill in the restore details in the General settings screen:
In the destination settings screen, expand the Resource transformations section and enable Resource transformation:
We don’t select a template yet and specify which resource we want to modify by entering the resource group, version, kind, and name.
To scale up the Alpine application’s deployment from one to two replicas during the restore, the target resource is determined by entering these values in the respective fields:
- Group: apps
- Version: v1
- Kind: Deployment
- Resource name: alpine
As we want to replace the value for the number of replicas, we enter/select in the Operations section:
- Operation: Replace
- JSON path: /spec/replicas
- Value: 2
After selecting Restore, the restore process finishes in a couple of minutes and we can confirm that the deployment of the restored Alpine application in the pu-alpine-restore namespace was indeed scaled up to two replicas:
$ kubectl get all,pvc -n pu-alpine-restore
NAME READY STATUS RESTARTS AGE
pod/alpine-85cb86d5fb-26hdl 1/1 Running 0 6m35s
pod/alpine-85cb86d5fb-rbhq7 1/1 Running 0 6m35s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/alpine 2/2 2 2 6m35s
NAME DESIRED CURRENT READY AGE
replicaset.apps/alpine-85cb86d5fb 2 2 2 6m35s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
persistentvolumeclaim/alpinedata Bound pvc-c2a6e871-b383-4bad-adb3-5d5d9f682e10 2Gi RWX ontap-rtp-a800-nas <unset> 6m
Before the introduction of resource transformation, operations like, e.g., rescaling an application or changing its image registry during restore were only possible by using post-restore hook scripts executed in helper pods, as outlined in these two blog post:
- Automating registry failover for disaster recovery with Trident protect post-restore hooks
- Rescale Kubernetes applications with Trident protect post-restore hooks
You’ll agree that using resource transformation for such operations is much easier and less error prone.
Create and use resource transformation templates
Resource transformation templates make the use of resource transformation even more easy and reproducible. We’ll show you how to create a template for the post-restore rescale operation we did in the previous section.
To create a resource transformation template, go to Settings in Backup and Recovery, expand the Resource transformation template section, and click Create template:
In the next screen, we name the template and add an optional description. Then we fill in the values for Group, Version, and Kind (app, v1, Deployment), leaving the Resource name empty, as we want the name of the deployment be entered when using the template.
In the Operations section of the form, select the Operation (Replace) and enter the JSON path (/spec/replicas), leaving the Value field empty for later population.
Clicking Add will add the new template to the list of available templates, from where we could edit, delete, or duplicate the template from its Actions menu.
Restore with rescale template
Now we can use the newly created template to simplify the restore with scaling-up we did in the previous section.
In the restore process, we now select the PU scale up replicas template we just created from the list of available templates (we’ll cover the predefined templates in the list later):
We now need only to fill in the values for the Resource name (alpine) and the Value (2) for the number of replicas we want to have after the restore.
After the restore finishes, we confirm that the deployment alpine was scaled up to two replicas:
$ kubectl get all,pvc -n pu-alpine-restore
NAME READY STATUS RESTARTS AGE
pod/alpine-85cb86d5fb-vzs6n 1/1 Running 0 43s
pod/alpine-85cb86d5fb-xd4g8 1/1 Running 0 43s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/alpine 2/2 2 2 44s
NAME DESIRED CURRENT READY AGE
replicaset.apps/alpine-85cb86d5fb 2 2 2 44s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
persistentvolumeclaim/alpinedata Bound pvc-47c5671f-62dd-44b6-a76c-a8b5854cb9bd 2Gi RWX ontap-rtp-a800-nas <unset> 53s
Virtual machine restores with transformation templates
Now let’s have a look at how we can use one of the predefined resource transformation templates with restores of virtual machines. We want to restore a virtual machine from an existing recovery point to another cluster and don’t start the VM but keep it in the Stopped state. For this purpose, we can use the predefined keep-vm-halted-on-restore template.
We have a virtual machine app pu-vms containing the VM app-vm-1 on the pu-ocp1 cluster that we want to restore to the pu-ocp2 cluster without starting the VM.
After selecting the restore point to restore from we fill in the parameters to restore to the pu-ocp2 cluster and destination namespace and application name:
We select to restore all resources and expand the Resource transformations section in the final screen. In the Template 1 field, we see all available transformation templates, predefined and custom ones. We select the keep-vm-halted-on-restore template:
We then need to only fill in the Resource name app-vm-1 of the virtual machine and can start the restore operation.
Once the restore finishes, we confirm that the VM is restored and in the Stopped state:
$ kubectl -n app-ns get vms
NAME AGE STATUS READY
app-vm-1 135m Stopped False
Summary and call to action
NetApp Backup and Recovery for Kubernetes now includes a powerful feature called resource transformations, which enables users to modify resources as they are being restored. This feature supports various operations such as adding, copying, moving, removing, replacing, and testing values within resources.
The blog post walks through two scenarios to illustrate the use of resource transformations:
- Scaling Up an Application During Restore: Demonstrates how to modify the number of replicas for a deployment during the restore process using the Console UI.
- Restoring a Virtual Machine in a Stopped State: Shows how to use a predefined template to restore a virtual machine without starting it, ensuring it remains in a Stopped state.
Additionally, the blog post explains how to create and use resource transformation templates, making the process more efficient and less error prone. The templates allow users to save common transformation operations and apply them easily during the restore process.
By leveraging resource transformations, users can achieve greater flexibility and control over their restore operations, simplifying tasks that previously required complex post-restore scripts. This feature enhances the overall efficiency and reliability of the Backup and Recovery for Kubernetes product.
Login to NetApp Console, navigate to Protection --> Backup and Recovery and sign up for a free trial, discover your OpenShift clusters and bring their protection to the next level.
Also check our repository of Backup and Recovery guided demos!