Kubevirt is coming...

[JorgeAndrade]

Has anyone tried https://github.com/kubevirt ?

Any thoughts?

For me this seems to be future for Running VMs on Kubernetes / Openshift ! One platform to rule them all.

[kaiser]

Not bad, But I am an "Old School" fan.

[flozano]

See CNV: Container Native Virtualization from Red Hat:

This was a presentation during Red Hat Summit:

https://www.redhat.com/files/summit/session-assets/2018/Introducing-Container-native-Virtualization....

And this was an OpenShift commons brefing:

https://www.youtube.com/watch?v=jlr4_CKG7AQ

[kubeadm]

Interesting, but I don't see the logic behind running a 'VM' on top of containers. 

I thought the idea of containers is to "do away" with the extra baggage (e.g. cpu/RAM associated with the guest OS in the VMs) and run the workload on light-weight containers.

So, with kubevirt, we're going to run VMs on top of containers? 

What are the benefits of doing that? Why not just run VMs on top of bare-metal instead? 

Puzzled .... 

[flozano]

With Kubevirt, VMs still run as bare-metal, not inside containers. The goal is using Kubernetes primitives to orchestrate applications somposed of multiple VMs (and VMs + containers). You'd manage networking, storage, multitenancy, resource consuption, etc for VMs the same way you do for containers.

For examples, a kubernetes service would load balance among VMs. An OpenShift route would allow external access to a VM. A containerized appliction would access a service without knowing if it is backed by a container or a VM.

[kubeadm]

Oh ... that makes sense - running VMs on bare-metal and using kubernetes primitives to manage them. Thanks Flozano!

More info: https://github.com/kubevirt/kubevirt/blob/master/docs/architecture.md

[gbsalinetti]

Kubevirt uses Custom Resourse Definitions (CRD) from Kubernetes but it doesn't implement the Container Runtime Interface (CRI). It treats VMs like different objects and needs an extra command line tool, virtctl.

If you are looking for something that implements CRI, look at Virtlet, a project developed by Mirantis. The main difference is that it treats VMs like pods thus enabling all deployment methods like ReplicaSet, DaemonSet, Jobs, etc that can't be used with Kubevirt (who has its own resource called VirtualMachineReplicaSet). You also have Liveness/Readiness probes, taints and tolerations, Virtlet also supports SR-IOV, unsupported by Kubevirt. Its greater limit is in the storage, which support only FlexVolumes, at least until Container Storage Interface (CSI) will be mature.
Kubevirt has a broader support for storage backends.

There are other similar projects, same goals with different approach. For example Kata Containers aim to run lightweight VM as containers. The main difference is that they are implemented to satisfy the OCI standards.

[flozano]

Kubevirt takes a different approach by design. They don't try to make VMs look like pods/containers, but to make VMs a first-class Kubernetes resource type. Like not all workloads can be managed by a replication controller or replica set (thus daemon sets, jobs, etc) VMs have very different characteristics so Kubevirt thinks that making them look as pods is the wrong idea. Let's see how those approaves work in the real world.

[gbsalinetti]

Yes, you are definitively right.
That's why I like the idea of having both Kubevirt and Virtlet at disposal for different approaches and different kind of workload.