I played around with a prototype a long time ago with getting clear containers deployable by container. Then you could use a kubernetes daemonset to deploy/manage additional runtimes.
If I remember correctly, I failed at the time because crio was not reenterent (may be now). But since then I've also learned of nsenter and think that could be used to solve the problem, and do it in a much lighter weight way.
Has anyone considered this use case recently?
Thanks, Kevin ________________________________________ From: Stefan Hajnoczi [stefanha@redhat.com] Sent: Wednesday, March 27, 2019 9:05 AM To: Hunt, James O Cc: Lokesh Mandvekar; kata-dev Subject: Re: [kata-dev] kata image types compared
On Tue, Mar 26, 2019 at 09:21:06AM +0000, Hunt, James O wrote:
Le mar. 26 mars 2019 à 08:02, Stefan Hajnoczi stefanha@redhat.com a écrit :
On Mon, Mar 25, 2019 at 04:42:17PM +0000, Venegas Munoz, Jose Carlos wrote: Lokesh: Out of the various options for building Kata images (initramfs vs disk image, systemd vs agent), which ones are friendliest for Fedora packaging?
There may be an alternative solution to the ongoing issue of packaging binaries images...
- Kata needs a binary rootfs image and a binary kernel image to boot the
hypervisor. Once booted, the user's chosen (binary) disk image will be made available for the workload (you might be able to see where this is going... :)
- Our OBS packaging currently packages images and kernels as a convenience
to users.
- Container managers like Docker also require binary images. But those
images are not packaged - they are downloaded on demand ("docker pull").
- This leads to a potential solution to the packaging blocker: Kata could
be packaged without any binary assets.
- If the binaries were not packaged, an additional step would be required
before a Kata container could be created, something like [2]:
$ sudo kata-runtime pull [all-assets|image|initrd|kernel]
There are complications with this concept though, including:
- Where would we host such assets?
- How would the kernel be handled?
- How would the system determine which type of image to download?
- How would updates to these assets be handled? We need to avoid / minimise
the "stale container" scenario [3].
I am not familiar enough with Fedora and Debian packaging policies to know whether this approach is acceptable under those policies. I like it though because it gives the Kata Community control over producing and updating images without complicating package maintainers' lives.
From a user perspective it would be nice not to know or worry about the
sandbox kernel & rootfs. That's an implementation detail of Kata Containers.
Stefan