Skip to content
Facilitate workloads movement across namespaces and providers
Branch: master
Clone or download
umamukkara Merge pull request #17 from umamukkara/badges
Update KEP-1 with acceptance criteria
Latest commit a1a414d May 19, 2019

kube move logo

Go Report Card Build Status CII Best Practices


Workloads running on Kubernetes do not make assumptions about the underlying infrastructure. However, it is still non-trivial to move them across different clusters. It is also non trivial to move them to another namespace within the same cluster scope such as to a different zone. KubeMove provides a set of tools and API to coordinate the orchestration and workflow of moving an application in production across cluster or namespace boundaries.

Architecture/Design proposal

The initial KEP (KubeMove Enhancement Proposal) is at KEP-1

Join the discussion through the issue here

Using Kubemove

  • Install kubemove using helm - helm install
  • Annotate the application to be moved with"true"
  • Use MoveEngine API with the required configuration to start the data movement or sync
  • Wait for the movement or datasync to complete and switch the application on the target cluster using MoveSwitch API


Example move commands:

kubectl km move init <app> <kubemove-template.yaml>

kubectl km status <movepair-cr>

kubectl km move switch <movepair>

Use cases

  • Hybrid and multi-cloud deployments - Move applications on-prem to cloud or vice-versa or from cloud-cloud
  • Onramp to Kubernetes - KubeMove can help migrate the data from legacy volumes onto Kubernetes
  • Kubernetes and/or application upgrades - Applications may need to be moved back and forth while following blue green strategy


KubeMove is developed under Apache 2.0 license.


We welcome participation from the community in defining more use cases, developing API spec and implementation. Please write new issues as you like.

You can’t perform that action at this time.