How Harvester Tricks Kubernetes into Running VMs
Today, whole world going forward with micro services with containers you may wonder we need to manage VMs. But behind the curtain they are there. The old guard virtual machines. They are might be run your payroll system, your legacy CRM, that one legacy java app. Because of this reasons the industry need to maintain two separate worlds.
- The VM stack: VMware, Proxmox or KVm
- The k8 stack: EKS, AKS, Rancher
These world need two different skill sets, as well as needed two sets of automation.
The Magic Trick (KubeVirt)
It is not a magic trick it a just a clever bit of software with one goal. That is to trick the Kubernetes into thinking a Virtual Machine is just another container.
Here is how the magic starts.
We have the normal kubernetes cluster up and running and user ask for a VM not a pod from it. Originally k8 doesn’t know what is VM or how to start a VM. However harvester deploys KubeVirt operator into its that cluster. This teaches kubernetes to learn new language call CRDs (Custom Resource Definitions).
CRD enables the kubernetes to understand the syntax like kubectl get virtualmachines but yet still didn’t know how to create them.
Then KubeVirt has a controller. That create a standard pod called a virt-launcher pod when the need a new vm request comes. To the Kubernetes scheduler, this is just a normal Pod requesting a specific amount of CPU and RAM. Kubernetes happily finds a worker node and schedules the Pod, completely unaware of what is about to happen inside it.
Get Sathindu D Zoysa’s stories in your inbox
Join Medium for free to get updates from this writer.
This is where the magic happens. Inside that virt-launcher Pod is a container. But instead of running a typical web server or database application, this container runs libvirtd and qemu-kvm. Qemu is a open-source machine emulator and visualizer. KVM is a kernel base virtual machine which build directly in to the Linux kernel.
To keep everything running smoothly, KubeVirt deploys a DaemonSet called virt-handler on every single bare-metal node in your cluster. This acts exactly like the standard Kubernetes kubelet, but specialized for VMs. I like to call the virt-handler as the secretory of virt-launcher that it do the actual resource creation and handover to the virt-controller.
So the VM lives inside the Pod. To kubectl, it looks like a container. To the KVM hypervisor, it’s a real VM. To you? It’s both.
The Missing Link (Longhorn Storage)
At this point we tricked the scheduler to treat the vms same as the containers. But how the hack the storage manages in those pods.
A container dies? it is just a redeploy last state which stores in the database.
But a VM dies? The whole finance team dies with it. That VM has a C: drive. It has a decade of registry keys and DLL hell.
Harvester solves this with longhorn engine. Longhorn is software defined for storage. It takes all the bare metal storage servers and pool them into one distributed storage network.
When creating a VM, harvester asks Longhong for storage. It attach the needed storage form his storage pool. Moreover Longhong has recovery system call Persistent Volume Claim (PVC). This mirrors the volume across three different physical server to use in case of a failure.
Final Wrap-Up
Now you may understand that harvester is not hypervisor. It is a transition layer. It gives legacy VMs the superpowers of clould-native container, that are declarative APIs, self-heating, automated failoer, an storage that doesn’t care about physical disks.
If your legacy VM system migrate to harvester you may not needed wake up on the 3 AM on the morning for alarm to that screaming that VM is went down.
