The world is rapidly moving towards containarized deployments, serverless applications and away from traditional infrastructure based on virtual machines and bare metal servers. Mind you, virtual machines and bare metal servers are still a huge part of infrastructure, but they have become hidden away under layers upon layers of abstraction. Developers no longer need to worry that changing a version for one of the dependencies of their application, might break other applications on a running system. That is so 2015. These days we just create one container in which our application is the sole tenant. Problem solved.
Right, right…but you mentioned something about migrating VMs in the same sentence with Kubernetes?
Indeed I did.
While the world may be moving towards containarized deployments, there are still a large number of environments and legacy systems that are built directly on top of virtual machines. In cases like this you can choose to spend the time and money to re-platform your stack to function properly in the new paradigm, or you can go for something that will get you most of the way there.
We will be discussing about the latter. While long-term you will probably re-platform your stack, short term you will undoubtedly benefit from something that will de-duplicate your infrastructure footprint, while maintaining functionality. This is where projects like Kubevirt come into play. Kubevirt is a Kubernetes extension that adds virtual machine management capabilities to any standard cluster. It leverages libvirt to create KVM based virtual instances, using the same Kubernetes APIs you already leverage to create containers.
Yes, that’s right, you can now create virtual machines in Kubernetes. But why is this important? Or better yet, how is this useful?
To put it plainly, this means that you are now able to gradually start re-platforming your application stack from VM based deployments, to a fully containerized solution. You don’t have to make one giant push to re-platform everything, duplicating your infrastructure to ensure business continuity while you do it. There are no complicated networking configurations to enable connectivity between the tenant network of your VM based deployments and the pod network in your cluster.
You have one single platform that combines both containers and virtual machines. One platform that makes interoperability between containers and VMs virtually transparent: Kubernetes.
You might be thinking that while all this sounds great, you already have everything deployed on VMs. Redeploying everything on different virtual machines inside Kubernetes is a huge undertaking that will take a lot of time and resources. In some cases it might not even be feasible to do, given the nature of some legacy systems running on old machines with extended support after EoL (looking at you Microsoft).
The good news is that you don’t have to redeploy anything. You can simply move those workloads in their entirety.
Migrating to Kubevirt using Coriolis
It turns out, that Coriolis is a perfect fit for this scenario. With its plugable architecture, adding a Kubevirt import provider to Coriolis was simple and quick. Moreover, it allows Coriolis to migrate instances into your Kubevirt deployment from any of the existing public and private clouds we currently support. To name a few:
- OCI-C (Oracle Cloud Infrastructure Classic)
- OVM (Oracle VM server)
You have an existing deployment of virtual machines inside a private or public cloud and you’d like to move it to your Kubevirt deployment? No problem! Coriolis can do that for you, in a fully automated way. Coriolis was designed with disaster recovery in mind. This means that you can sync your existing infrastructure from one of the supported clouds, to your Kubevirt deployments, and migrate whenever you are ready.
Coriolis strives to ensure that you never loose business continuity while your data is being synced from source to destination. Your running virtual machines will stay running while we copy everything over to their new home. This is done completely agentless. We will never require you to install anything inside your virtual machines.
So, want to test out a deployment before committing to actually shift traffic to the Kubernetes backed virtual machine deployment? That is perfectly fine. Coriolis enables you to do as many test deployments of your workload as you wish. The virtual machine data is already synced inside your Kubernetes cluster.
Deploy your migrated virtual machines inside Kubernetes, test them out, validate that everything is fine, tare them down, migrate them again. You decide when you want to shift traffic. You are in full control.
By now I hope I’ve made you curious enough to want to see a quick demo. Below you can find a video of an actual migration from VMware to Kubevirt. This demo is in real time. There are no speedups or edits. Enjoy!