cancel
Showing results for 
Search instead for 
Did you mean: 
JorgeAndrade
Flight Engineer Flight Engineer
Flight Engineer
  • 5,426 Views

Kubevirt is coming...

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.
8 Replies
kaiser
Flight Engineer
Flight Engineer
  • 5,418 Views

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

flozano
Moderator
Moderator
  • 5,412 Views

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

0 Kudos
kubeadm
Flight Engineer Flight Engineer
Flight Engineer
  • 5,399 Views

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
Moderator
Moderator
  • 5,396 Views

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
Flight Engineer Flight Engineer
Flight Engineer
  • 5,388 Views

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

0 Kudos
gbsalinetti
Flight Engineer Flight Engineer
Flight Engineer
  • 5,371 Views

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
Moderator
Moderator
  • 5,368 Views

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
Flight Engineer Flight Engineer
Flight Engineer
  • 5,364 Views

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.

 

0 Kudos
Join the discussion
You must log in to join this conversation.