Open Stack

On Thu, 2 Apr 2020 at 11:11, Whaley, Graham <graham.whaley at intel.com> wrote:

>
> OOI Ilya, is there a particular reason you are using Kata for this, and
> not using just vanilla VMs?
> I think adding Kata to the mix is going to make your life significantly
> harder - it is/was not designed to 'just work' on any kernel without
> specific features etc., as you are finding.
> If there is a specific reason to use Kata, fine, great - but we'd probably
> be interested to hear it 😉
> If not, then your life might get significantly easier if you switch to
> using plain QEMU (and if your apps are in containers, then having docker
> installed on the client you run under vanilla QEMU etc.).


Graham, as I mentioned on IRC, I am pretty certain of what I'm after here.

Conceptually, this is about running Kubernetes-in-Kubernetes, which is a
know general patter, and this is just a variation of that.
I have a requirement on having kernel isolation as well as a strong
desire to test different kernels also. I actually have some of
this working already.

I do think it's plausible to consider not using kata and e.g. have qemu or
firecracker inside container image and just run it from
the pod, as I don't see a major need for storage after VM startup, it could
be quite simple, yet I would still need to make networking
work resource management would have to be take care of - whatever pod needs
to run the VMM and whatever the VM resources
should be set to... I guess for some use-cases this might just work, but
ultimately one will eventually desire a more native pod-as-VM
setup, something very much like kata.

KubeVirt could be another option, but from what I gathered it's much less
native to Kubenernetes, and you cannot map a KubeVirt VM
to a service like you can with Kata.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20200404/c2fbd51d/attachment.html>