Automating Kubernetes Cross-Account and Cross-Cluster Restore
Why settle for less! The challenge of manually dealing with self-hosting a product like Velero or Kasten on dozens of clusters and multiple clouds, and then trying to migrate data across different accounts and even different clouds is very different from dealing with a single cluster and a single cloud environment.
CloudCasa provides a guided workflow for cross-account and cross-cluster Kubernetes restores in Amazon EKS from an intuitive GUI. When creating an EKS cluster on restore, CloudCasa allows you to customize the IAM role, subnet group, security group etc. to use in a new account or region. This minimizes the need for user intervention and allows a “bare metal recovery” like functionality.
When restoring to an existing cluster other than the original cluster, users can browse the available storage classes in the destination cluster. This makes remapping storage classes quicker and easier, and CloudCasa will automatically handle changing volume IDs for PVs.. In general, cross-cluster restores should work with no user intervention as long as matching storage classes exist on the target cluster. If they don’t, you should use the option to remap storage classes to those that exist on the target.
We generally recommend restoring individual namespaces rather than the full cluster when restoring to an existing cluster. Also, only copy-backups should be restored to a different target cluster, not snapshot-backups. For automatic cross-cluster restores, only dynamically provisioned PVs are supported.
Learn how to do a cross-account and cross-cluster restore of Kubernetes using CloudCasa on Amazon EKS in this sequence of videos by Martin Phan, Field CTO Americas for Catalogic. Part 1 covers Setup, followed by part 2 on Backup, and part 3 on Restore. Users can browse clusters and map the available storage classes in the source and destination cluster across different AWS accounts and different cloud providers such as AKS and DigitalOcean.