Introducing Konveyor Move2Kube

Are you deploying your applications in Cloud Foundry or Docker swarm/compose and would like to try out Kubernetes, but not sure where to start? Konveyor Move2Kube is here to give you a headstart.

You application is yet to be containerized? Konveyor Move2Kube can help accelerate your journey.

Move2Kube was conceived in IBM Research to help accelerate the replatforming journey to Kubernetes. One of the challenges in moving to Kubernetes is understanding its various concepts and creating the optimal deployment artifacts. It requires a good understanding of Kubernetes concepts, and the right mapping from the source platform. Move2Kube helps solve this problem by using an opinionated approach and automating the process, while involving you for critical information.

Move2Kube also helps you customize your configurations for the specific cluster type you are planning to deploy. May it be Openshift or any flavor of Kubernetes, Move2Kube looks at the specific features supported by that cluster type, and tailors the artifacts for that cluster type.

When it comes to replatforming your application to Kubernetes there are a few crucial steps:

1. Containerization
2. Creation of deployment artifacts
3. Incorporate best practices in deployment artifacts
4. Customizing for a specific cluster

Move2Kube helps users in all the above steps by looking at the source artifacts, runtime artifacts, analysing, correlating them and coming up with a plan for transformation. It then involves you in an interactive journey to create the right artifacts for the application. We will look into how Move2Kube handles the above steps in detail in subsequent related blogs.

Here is a quick preview of them:

Containerization:

Move2Kube can containerize the application using the below techniques.

1. New Dockerfile
2. Source 2 Image
3. Cloud Native Buildpack
4. Detect and reuse existing dockerfiles

Creation of deployment artifacts:

Move2Kube can create various deployment artifacts that are required for deploying applications to Kubernetes.

1. Deployment (Deploymentconfig, Deployment, ..)
2. Service
3. Ingress (Route, ..)
4. NetworkPolicy (based on docker compose network)
5. Storage (PVC, Secret, ConfigMap)
6. Knative Service

Incorporate best practices in deployment artifacts:

Move2Kube can incorporate best practices in the deployment artifacts depending on an opinionated design, like enforcing minimum number of replicas.

Customizing for a specific cluster:

Move2Kube can customize the artifacts for a specific cluster in an opinionated manner. For example, if the target cluster is a Openshift cluster, it will generate DeploymentConfig instead of Deployment. Also based on the specific version of the api supported by the cluster, Move2Kube can generate the yamls for the specific Kind Group Versions.

What more? Move2Kube code is completely extensible, and more features can be easily added to Move2Kube by leveraging the Move2Kube framework.

Move2Kube Usage

Move2Kube takes as input the source artifacts and outputs the target deployment artifacts.

Move2Kube accomplishes the above activities using a 3 step approach of

1. Collect : If runtime inspection is required, move2kube collect will analyse your runtime environment such as cloud foundry or kubernetes, extract the required metadata and output them as yaml files in m2k_collect folder.
2. Plan : If you need fine granular control over the services detected in the source artifacts and runtime inspection, move2kube plan -s <sourcefolder>will allow you to create a m2k.plan yaml file, with information about the services it detected and the various ways it can transform it. You can curate this file before proceeding to translate step.
3. Translate : move2kube translate translates the artifacts into target deployment artifacts based on the m2k.plan you have curated.

At the end of the translate step, you could potentially have the following artifacts:

1. Helm Chart/Kubernetes/Knative yamls
2. Containerization scripts + Docker compose file
3. Operator Stub

Depending on the complexity of your application you can either choose to follow the 3 steps, or just go with a much simplified one step process.

Once you have the move2kube binary in your path, all you need to do is to point Move2Kube to that folder using :

move2kube translate -s <PathToSource>

We are just starting and are looking for feedback as we improve Move2Kube along with our partners at RedHat Konveyor project. Do join us in the journey by participating in github issues, slack, creating pull requests and star the project if you find the project useful.

If you are interested to contribute to the repository as part of Hacktoberfest, here are some issues (other move2kube repos too have some) that you can fix in short time.

We are working on making Move2Kube even more consumable, stay tuned…