Kata Containers – The speed of containers, the security of VMs (opens in new tab)

It is comprised by many parts that, already, have seen development as:

Kata Agent: https://github.com/kata-containers/agent

Kata Shim: https://github.com/kata-containers/shim

Kata Proxy: https://github.com/kata-containers/proxy

KSM Throttler: https://github.com/kata-containers/ksm-throttler

And some forks to provide for their necessities, I suppose, as:

Linux Kernel: https://github.com/kata-containers/linux

QEMU: https://github.com/kata-containers/qemu

The code comes from Intel's Clear Containers and hyper. The interesting bit is that the tech is now part of the openstack foundation, under the name Kata Containers. At Kubecon yesterday, they did a demo, showing a fork bomb taking out a container, but not the host. It actually seems nearly ready to use.

There does seem to be a fair bit left to write (or clean up and open source from Hyper.sh and Intel)

e.g. the entire testing repo is empty

I would suggest we are looking at a conference driven development release

> On the other hand, isn't this the realm of mainline distributions like RHEL, Debian and the like?

At least Debian doesn't develop isolation solutions on its own; it tends to package software that's already out there. And if it's popular enough, it might be integrated fairly tightly into the distribution.

Interesting that nearly half of the backers are Chinese companies.

At the Kubecon demo yesterday they cracked a joke about promising to support more architectures. They seem to sincerely want to, which is why they donated the project to OpenStack. Honestly it seems really cool, the spin up time is damn impressive.

> Impressive backing by the big name companies.

From someone who works at big name companies: this should not impress anyone. Big companies love slapping their name on things that give them "innovation" credibility. It's like Pepsi sponsoring the X Games.

> why a separate project like this

This is an OpenStack project, so it's not vendor-specific. It's also supposed to be a new "standard container", which I highly doubt will happen because they're just slapping together two other projects.

> The idea of treating containers as secure and isolated as VMs is enticing for non-ephemeral services

Are you saying that security and isolation is not enticing for ephemeral services? I know that an ephemeral container is reset after a restart but I think that it's a bit naive to think that that is a good enough replacement for true isolation.

Separate projects like this is how a lot of these "RHEL Enterprise $FOO" are actually made.

RedHat / Suse / Ubuntu / $Vendor take the upstream project, tidy it a bit, package it, get it integrated in their ecosystem, and add an easy installer.

Having it in a vendor neutral foundation means that all the vendors can colaborate, and not have one group with a massive advantage or complete control over a roadmap.

Sat through the talk at kubecon yesterday - an important goal of theirs is to not compete with the docker. They said it was compatible with docker, containerd, and cri-o. I believe with docker, it sits at the runc level, so to the end user, you're using docker in the standard fashion, but the underlying isolation mechanism is different. They also said it can be chosen per container so different containers on the same host can use different isolation mechanisms

It doesn’t have to replace Docker – just becoming a better container engine as backend for Kubernetes will be very useful.

If it's using Hyper runV, my guess is that their intent is to be compatible with OCI and Docker.

So there is no country called "Input/Output", what a bummer.

I'm not sure I get the connection. Also: https://en.m.wikipedia.org/wiki/Depopulation_of_Chagossians_...

That place has some sad history: https://en.wikipedia.org/wiki/Depopulation_of_Chagossians_fr...

> a bit overkill

They also said the same about Xen, that a special purpose microkernel was a better choice than Linux as a hypervisor...

FreeBSD jails are known to not be silver bullets. I've heard many instances of breaking out of a FreeBSD jail.

Generally, treating any OS-level technology as a silver bullet is a huge mistake. Any serious developer would make multiple levels of security that _should_ be sound.

Does Windows have anything like this?

Funny, I never thought about it that way. Namespaced processes being a linux kernel feature in the first place. That's where the whole container thing CAME from in the first place. It's only because the Windows and OSX kernels _don't_ support namespacing, that we have to run docker et al inside a virtual machine on those environments. It is not the container implementation, but the virtual machine, which makes containers "secure" on those platforms.

So put more finely: containers are not secure, anywhere. Virtual machines are. So you should run your containers inside virtual machines if security is important to you. Environments that can't run containers natively are forced into the more secure configuration.

If you're interested in the ongoing work to make containers more secure, Jessie Frazelle has very clear posts on the subject [1][2]. The Bubblewrap project also has a great summary of various approaches being used to "jail" container processes properly. [3]

[1] https://blog.jessfraz.com/post/containers-zones-jails-vms/ [2] https://blog.jessfraz.com/post/getting-towards-real-sandbox-... [3] https://github.com/projectatomic/bubblewrap

This is a combined work of the people behind Intel Clear containers and Hyper containers.

Both. The hardware virtualization related settings are configured out side of OCI spec but the runtime accept OCI spec and plays with it accordingly. As for image format, Kata runs unchanged docker images.

Different approaches to isolation. A kata container is using Clear Linux to load a feature-complete Linux kernel into tiny VMs (disclaimer: I do not know exactly how it's different from any other VM,) a unikernel is a small bare-metal "library" that gives you minimal OS-like functions to put in a hypervisor to run your application. Unikernels are still more minimal, I'd guess.