To a casual observer, OpenStack and Kubernetes seem to be having a lovefest. After all Kubernetes can run on OpenStack (containers in VMs) with project such as OpenStack Magnum. And OpenStack can be containerized and orchestrated by Kubernetes with project Kolla (and others). However, taking a 10,000 ft view, OpenStack and Kubernetes are both cloud technologies -- so when the dust settles, you might end up with jilted lovers. Up until now, OpenStack was better for VMs and Kubernetes was better for containers (I’m ignoring bare-metal).
Until now.
With two new open source projects: Virtlet from Mirantis and Kubevirt from RedHat, it will be possible to schedule VMs with Kubernetes. That just might be a TKO win for Kubernetes… and leave OpenStack in a dazed stupor. I acknowledge that OpenStack is sooo much more than just Nova, so you might end up with a mashup stack that uses Kubernetes for scheduling, orchestration, monitoring etc. and OpenStack for storage, networking, image repository, authentication, NFV etc.
With Kubernetes able to schedule VMs, why would you not use a lighter, newer, more streamlined piece of software to orchestrate both VMs and containers? Plus Kubernetes also takes into account important issues such as lifecycle management, self healing, monitoring and other day-2 concerns from the get-go, that have always been an afterthought for OpenStack.
There are differences between the two projects though. Kubevirt is similar to adding an outdoor garage to your house and Virtlet is similar to adding a new bedroom. Kubevirt uses the Kubernetes's third party resource concept that loosely weaves in VMs into Kubernetes. The plus here is that you can use your own mechanisms to manage the VM, but the downside is that the VM isn’t well integrated into Kubernetes. Virtlet on the other hand uses the Kubernetes Container Runtime Interface (CRI). This means that you are forced to use Kubernetes constructs to manage the VM, but the integration with Kubernetes is a lot tighter. You can use the same SDN controller, monitoring framework, health monitoring, scaling/ HA techniques etc. as containers.
Which one is better suited? That depends. For an enterprise use case, I might argue that Kubevirt is better. It allows more flexibility in terms of managing the VM and enterprise use cases don’t really care about a tight integration and coexistence between VMs and containers. For NFV, I’d say Virtlet wins hands-down since you can do service function chaining by mixing VM and container VNFs that have the same SDN, storage volumes and other Kubernetes mechanisms listed above.
What do you think? Let us know!