Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kata Containers – The speed of containers, the security of VMs

katacontainers.io

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Kata Containers – The speed of containers, the security of VMs

#71

Post by paulfurtado »

redtuesday wrote: post #56
paulfurtado wrote: post #35

Earlier quoted context omitted.

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.

Can't you just combat fork bombs with e.g docker run --pids-limit=64

Yes, there are several ways to combat fork bombs (ulimits or pid namespaces). This was purely for the sake of the live demo that required a kernel crash example, there are certainly other ways to combat it.

Re: Kata Containers – The speed of containers, the security of VMs

#72

Post by bergwolf »

acobster wrote: post #51

> It is designed to be architecture agnostic, run on multiple hypervisors and be compatible with the OCI specification for Docker containers In what sense is this "OCI compatible"? Do they implement the runtime, image format spec, or both? My understanding of containerization and OCI runtimes is that they're fundamentally different from hardware-level virtualization.

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.

Re: Kata Containers – The speed of containers, the security of VMs

#73

Post by helper »

qaq wrote: post #70
helper wrote: post #63

Earlier quoted context omitted.

http://www.zerodayinitiative.com/advisories/ZDI-16-168/ http://www.zerodayinitiative.com/advisories/ZDI-16-274/ These were both in Illumos found by the person you are replying to.

Good point does not look too horrible as far as track record though :) less than number of docker vuln. and about the same as vmware which is an actual vm

Please don't take the first two urls I found with a single google search as a comprehensive survey of Illumos kernel vulnerabilities over the last few years.

Re: Kata Containers – The speed of containers, the security of VMs

#74

Post by e_d_e_v »

bonzini wrote: post #64
e_d_e_v wrote: post #42

How is this better than using rkt with an lkvm stage1[1], which also uses the work done by the Clear Containers team? It looks like Kata packages QEMU as well, which seems a bit overkill. [1] https://coreos.com/rkt/docs/latest/running-kvm-stage1.html

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

Right, in many cases, small is beautiful! I think that's what contributed so heavily to the massive success of the Xen platform. Is that what you mean?

Re: Kata Containers – The speed of containers, the security of VMs

#75

Post by bonzini »

e_d_e_v wrote: post #74
bonzini wrote: post #64

Earlier quoted context omitted.

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

Right, in many cases, small is beautiful! I think that's what contributed so heavily to the massive success of the Xen platform. Is that what you mean?

Then why does Kata Containers use KVM?

Xen was successful because it was innovative, and because it worked around the fact that x86 was not virtualizable at the time. But after ten years of healthy competition, the only reason to prefer Xen to KVM would be things like QubesOS.

Re: Kata Containers – The speed of containers, the security of VMs

#76

Post by mugsie »

bonzini wrote: post #60
mugsie wrote: post #46

Earlier quoted context omitted.

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.

There are hundreds of engineers working on RHEL (disclaimer, that includes me), so it's not as simple as you put it...

No, it is not - I over simplified the process a lot. (/me used to work in a vendor, and in a different large Linux distro :) )

I didn't mean to undermine the work that goes into turning a project like this, OpenStack, Kubernetes, Cloud Foundry etc into a real product that users can download and install on random hardware in random configurations, and get a working system - it is a ton of work, and is massively important for getting actual users to install what are very complex distributed systems.

Post reply on HN