Cross-cluster migration of Kubernetes workloads continues to be challenging since workloads are isolated from each other by design. There are a number of reasons why you may want to separate your workloads, whether it is to reduce complexity or to have the cluster closer to the user base. However, this can be complex as Kubernetes has many components.
In this video, Kamlesh Lad, VP of Engineering & Chief Architect at CloudCasa by Catalogic, sits down with Swapnil Bhartiya to discuss the different scenarios where developers may want cross-cluster migration of Kubernetes workloads and the associated challenges. He also takes a deep dive into the available tools and how CloudCasa is helping simplify cross-cluster migration of Kubernetes workloads for developers.
Key highlights from this video interview are:
- There are several reasons why enterprise Kubernetes deployments have so many clusters. There are also different reasons for why developers may want to separate them. Lad goes into detail about the complexities of dealing with lots of clusters and the different scenarios why you may want to separate them.
- Even if you have on-prem, developers may want to have some clusters on-prem and some in the cloud. Alternatively, they may want clusters with different cloud vendors, or to segregate the clusters by different accounts in a single cloud. Lad describes the different infrastructures where developers may want to separate clusters.
- Lad goes into some of the common use cases he sees in production for data migration across clusters, from wanting to move workloads on a cluster to new storage, to cloning production workloads to the development and QA environments.
- Kubernetes has so many different components, but there are several that you cannot migrate the workload without moving them, such as the metadata and persistent volumes. However, Lad explains which components need to be kept in order to migrate the workload.
- One of the challenges of moving or duplicating workloads across different clusters is that there is not any communication between them, since the storage is not shared. Taking the persistent volume or the etcd data in a way so it can be moved to a different cluster is challenging. Lad discusses how you might want to navigate these difficulties.
- There are several open source and proprietary tools to help developers migrate workloads. Lad goes into detail about the available tools.
- Lad goes into depth about how CloudCasa is helping to make this easier for developers. He explains their fully managed SaaS service, and its features and benefits.
- Lad gives Swapnil a demonstration of how CloudCasa helps with migrations, taking him through the workflow of migrating a cluster from one AWS account to another AWS account.
The summary of the show is written by Emily Nicholls.