The more conversations I have, the more it becomes clear: There are many customer (if not all) who value application mobility. Whether you move from one k8s cluster to another, move from one storage platform to another, or just move to a different namespace: the need is there. Luckily we have the Dell CSM modules, and the (currently in tech preview) application-mobility module is here to serve!
Moving apps: The Persistence Complexity
As I see more and more customers who have more than 10 k8s clusters, the need arises to be able to move apps quickly and easily between them. These are the type of moves you can think of:
- Move an app to another namespace
- Move an app to another k8s cluster
- Move an app’s persistent storage between storage platforms
- Any combination of the above.
For stateless apps this is relatively easy: You basically tear down in one place and then you redeploy onto the next. But persistency (so stateFUL apps) make this move much more complex; how do we actually move the persistent volumes or PVs somewhere else along with the app?
Dell CSM modules to the rescue!
For any of the mobility situations mentioned above Dell’s app-mobility module can help. This module is part of the Dell CSM (or Container Storage Modules) and all of these modules basically “continue where k8s stops“
“Dell CSM Continues where k8s stops”
Dell’s CSM modules aim to add functionality to k8s beyond what k8s is natively capable of. Think of things like storage-based replication, group snapshotting, statefulSet resiliency and… Application Mobility. The power to “Simply move a stateful container app” turns out to be of incredible value over and over again, whether you are moving from on-prem into public cloud, repatriating back to on-prem, or just have a need to move an app to a different namespace or k8s platform.
Volume group snapshots
As you move a stateful application, you can run into the issue where k8s is incapable of creating multiple snapshots in one go, basically snapshotting persistent volumes one-by-one instead of all at the same time. Dell solves this issue by extending their CSI drivers to support “volume group snapshotting”. By allowing the CSI driver to group volumes into a volume group on the storage platform, a snapshots to be taken from the app can be instructed to occur at the volume group level and not the volume level. As a result, all volumes that make up your persistent app will be snapshotted at the exact same time. Another issue solved đ
Demo video: Moving an app between platforms
In the demo video below I have a stateful app (yelb) running on OpenShift 4.11. The app runs in the default namespace, and is backed by two persistent volumes (for database and redis) that sit on a PowerStore using the Dell CSI driver.
In the demo we will now move the app to another k8s platform (in this case Rancher), another stroage platform (from PowerStore to PowerFlex) and a different namespace, all in one go:
The way app-mobility works
What you require for application-mobility to work, is that you have a source and destination K8s cluster (which may be the same cluster or a different one) with application-mobility installed. In this version you’ll also need access to an S3 bucket as a temporary storage while the app moves.
Next you just need some extremely simply yaml code to backup, restore or clone (which is a restore that is triggered automatically after a backup completes):
Backup.yaml:
apiVersion: mobility.storage.dell.com/v1alpha1
kind: Backup
metadata:
name: backup-name
namespace: application-mobility
spec:
includedNamespaces: [default]
datamover: Restic
clones: []
restore.yaml:
apiVersion: mobility.storage.dell.com/v1alpha1
kind: Restore
metadata:
name: restore-name
namespace: application-mobility
spec:
backupName: backup-name
namespaceMapping:
"source-ns" : "destination-ns"
One last thing to consider: If you move between storage platforms, you will need to tell application-mobility where the persistent volumes should go. This can be done by using a ConfigMap. In the example below we move from a powerstore storageclass to a powerflex storageclass:
apiVersion: v1
kind: ConfigMap
metadata:
name: change-storage-class-config
namespace: application-mobility
labels:
velero.io/plugin-config: ""
velero.io/change-storage-class: RestoreItemAction
data:
powerstore-ext4: powerflex
This is basically all you need to enable app mobility in your environment! Also, please note that this actually works on ANY storage platform that is connected into k8s using a CSI driver that at a minimum supports snapshotting. So you can even move workloads between storage platforms from different vendors!