Transitioning to Red Hat OpenShift Service on AWS (ROSA) HCP from classic with MTC

Explore how the migration toolkit for containers (MTC) paves the way for seamless migration of application workloads from ROSA classic to ROSA HCP clusters, right down to the namespace level.

Discover how the migration toolkit for containers (MTC) simplifies the complex process of migrating applications between Red Hat OpenShift clusters ensuring seamless transitions.

In order to get the full benefit from taking this lesson, you need:

  • A basic understanding of containerization and Kubernetes concepts.
  • Familiarity with Red Hat OpenShift platform functionalities and terminology.
  • Awareness of challenges and considerations involved in application migration between clusters.

In this lesson, you will learn:

  • What MTC is
  • The architecture and key components of MTC

Migration toolkit for containers (MTC)

MTC makes it easy to move your applications between Red Hat OpenShift clusters using a simple web console and Kubernetes APIs. It handles migration at the namespace level, moving all related objects and resources like services and pods. Even if a resource in the namespace depends on one at the cluster level, MTC takes care of migrating both. 

For example, if a service account (SA) relies on a security context constraint (SCC), MTC ensures both are moved together. Similarly, the MTC migrates persistent volumes (PV) that are linked to the persistent volume claims (PVC) of the namespace. While most migration is automated, some cluster-scoped resources might have to be migrated manually, depending on the resource.

See Figure 1 for a simplified MTC architecture.

An image depicting the architecture around MTC and how it works through OpenShift
Figure 1: Simplified MTC architecture.

Let’s get familiar with the MTC terminology.

  • Source cluster: The cluster from which applications are migrated.
  • Target (destination) cluster: The cluster to which applications are migrated.
  • Host (control) cluster: The cluster on which the migration-controller pod and the web console are running. The control cluster communicates with the source cluster and target clusters via the Velero API to drive migrations.
  • Remote clusters: The source and destination clusters which run Velero are called remote clusters. A remote cluster requires an exposed secure registry for Direct Image Migration (DIM). Remote clusters also require the migration-controller service account token. This token is used by the control cluster to access the migration-controller of the remote clusters.
  • Replication repository: An object storage accessible by all clusters and used for copying images, volumes, and Kubernetes objects during indirect migration or for Kubernetes objects during Direct Volume Migration (DVM) or Direct Image Migration (DIM).
Previous resource
Overview: Transitioning to ROSA HCP from ROSA classic simplified with MTC
Next resource
Understanding migration variants