Migrate any OpenShift or Kubernetes workloads to OKE cloud using Migration as a Service

Many organizations are choosing Oracle cloud infrastructure (OCI) due to its industry-leading performance and pricing simplicity. If you are already using another cloud, you should consider all the benefits of migrating to OCI. With Oracle and partner RackWare, you can seamlessly move your applications from any container cloud platform to Oracle Container Engine for Kubernetes (OKE) platform.

In this blog, we will look at how to migrate your applications from any container platform to OKE.

SWIFT supports migration from SWIFT supports migration from,

  • Local Kubernetes  

  • Google (GKE)  

  • AWS (EKS, 

  • Azure (AKS)  

  • IBM (IKS)  

  • Any OpenShift environment to OKE

SWIFT makes migration simple with just 3 steps,

Step1: Launch a SWIFT server from Oracle Marketplace.

  • Search for the template on Oracle Marketplace.

  • Name of the of the template is RackWare Kubernetes Solution - SWIFT (Migration-Subscription).

  • Click on ‘Get App’. Select the market where you want to deploy the SWIFT

  • Enter OCI credentials for login. It will redirect you to launch instance page where select the shape, network, and other details. Click on ‘Create’.

That’s it. It will launch SWIFT. Now we are ready to migrate applications.

Step2: In this demo we will migrate a blogger app deployed on GKE cluster

Discover the source cluster where your current workload is present. Also, discover the target OKE cluster. To discover a cluster, click on ‘Container Cluster’ > ‘Add’. Enter the required details on cluster add popup,

Discover action pulls the metadata from the source and target cluster which will allow you to select the workload for migration.

After discover, we are ready to migrate all types of applications from the source cluster to the OKE.

Step3: Add a migration job. To add a job,

  • Go to ‘Sync Administration’ > ‘All Replications’ menu.

  • Click on ‘New’ > ‘Application Replication’. It will open ‘New Replication’ popup, select the application/namespace to migrate along with a few other parameters like storage class to use on OKE for migrated application.

  • Click on ‘Add’ to create a job.

1) Sync Type: SWIFT supports 3 types of sync

  • Passthrough: In this type, sync is run between the source and destination clusters directly. SWIFT will create a passthrough channel between the clusters and the data is replicated directly from source to target cluster.

  • Stage1: In this mode, sync is run between the source cluster and the SWIFT. All the objects and volume selected for sync are captured in SWIFT.

  • Stage2: In this mode, sync is run between the SWIFT and the Target cluster. All the objects and volumes captured in Stage1 are migrated to the destination cluster.

2) Platform Type: Select platform type from Kubernetes and OpenShift.

3) Cluster Name: Select the discovered cluster to migrate.

4) Namespace: Select the namespace from which you need to migrate the applications.

5) Applications: You can either migrate all objects from the namespace or you can select objects for migration. SWIFT is capable enough to find the objects linked with the object you migrate. For example. if you migrate a deployment, SWIFT will find the ConfigMaps, Secrets, ServiceAccount, etc. objects associated with deployment and migrate those for you.

6) Storage Class: The dropdown lists all the storage classes available in the destination cluster.: The dropdown lists all the storage classes available in the destination cluster.

7) Sync Webhooks: Use this flag to sync all webhooks, i.e., MutatingWebhookConfiguration and ValidatingWebhookConfiguration. All the services to which webhooks point will also be synced along with the webhooks. If the service is in a namespace which does not exist on the target, then it will be created first and then the services will be synced. Native Webhooks - Use this flag to synchronize all platform-native admission controller webhooks. By default, most K8S native webhooks are excluded from cross-platform synchronization.

8) TRAI Ports: These ports need to be from the cluster’s service port range. If not specified, they will be auto picked from the respective cluster’s service port range. Make sure all the cluster service port range or specified ports are whitelisted in all intermediate firewalls between the SWIFT and the remote cluster.

9) Image: Name of the TRAI image that we pushed to the private registry.

10) Secret: Name of the secret that we created in the namespace that has the credentials for accessing the TRAI image from private registry.

11) Dry Run: This flag will cause sync to not replicate any real data or objects. It will confirm that sync will successfully run to the end. No new volumes will be created on the target side, though, pre-existing volumes on the target side may be freed up by removing their owner objects. Any deleted target objects would be recreated. The dry-run sync would also collect data and object sync stats, to show you what real sync would have replicated.

After adding a migration job, status of migration can be checked under all replications section. It shows the detailed information of synced objects count and transferred data.

After successful deployment, login to your Kubernetes dashboard deployed on OKE cluster and check all objects status

You can also compare your application with the source application.

You can now remove the SWIFT instance created for migration.

Note: If you want to migrate specific objects e.g., migrate specific service, then it is also possible with SWIFT. SWIFT intelligently finds all the dependencies and associated objects like deployments, PVCs, PVs and migrates it.

If you want to know more about SWIFT contact RackWare team. Click here

By - Vaibhav Galande

>