LWN: Comments on "Demystifying container runtimes"

Demystifying container runtimes

rbanffy — Thu, 11 Jan 2018 15:22:41 +0000

One pain point when I started playing with Docker is that I was already using OpenVZ to host system containers - long-running, persistent, whole-system images - that are also called containers.

Container distribution

jhhaller — Fri, 05 Jan 2018 00:08:57 +0000

Having looked into how "docker login" works, and the various credential stores, I'm just very disappointed. The V2 docker registry allows OAUTH2, and does all kind of nice things like returning time-limited tokens. But, docker login cares not one whit about any of that, and just stores the login/password either in a file in cleartext, or in a password helper. The password helper allows trivial retrieval of the login/password used. One would hope that storing the OAUTH2 token would be at least an option, and maybe even the default, so that login/passwords don't sit around in a form easily retrieved in cleartext form. But, not today. It's not even clear where to make such a suggestion. The protocol for distribution is fine, it's just how docker login/logout works today that could be improved.

Demystifying container runtimes

bergwolf — Wed, 27 Dec 2017 07:36:53 +0000

> [1]: Docker, LXC, rkt, cri-o, runc, and containerd

Speaking of container runtimes, docker/cri-o/containerd/containerd-cri do not really fit in there. They all provide management and infrastructure to use different container runtimes. Current available container runtimes are LXC, runc, runV and Clear Containers (the last two got merged as Kata Containers).

Demystifying container runtimes

kleptog — Mon, 25 Dec 2017 15:31:13 +0000

While I sort of agree with you, it seems that there are actually several ways you can use containers. If your application fits the "pod" model that Kubernetes uses then awesome, but not every application can work that way. At least in our case, we figured looking into seeing if we could port our application from running on Docker to Kubernetes and it would require such a large rearchitecting we stopped researching :( The whole service discovery is totally different, the networking, the network isolation, etc.

What Docker offers is having a single file which you can just feed to stack/compose which describes all the images, networks, storage, etc and then you can go to lunch. Maybe it implements features other people don't need, but if you do need them your SOL. It feels like Docker is a general solution and everyone else is serving special niches. I hope I'm wrong.

Demystifying container runtimes

k8to — Sat, 23 Dec 2017 21:29:16 +0000

If you need to deploy a microservices systrem, and are just starting out, it seems like GKE is a pretty painless way to start, to me, if you're willing to be hosted. You can let other people worry about the details, and you can migrate to owning the stack when it's convenient.

If you're trying to own the full stack now, then yes it seems like question marks everywhere.

Other container runtimes

ebiederm — Fri, 22 Dec 2017 01:38:03 +0000

Also very active at the kernel level are the developers of OpenVZ atVirtuozzo.

Demystifying container runtimes

anarcat — Thu, 21 Dec 2017 14:16:50 +0000

That's a correct analysis: Mesos was barely mentioned, and so did OpenStack, FWIW... It is striking how fast the ecosystem is changing: I would be terrified to be running *any* of those tools in a major deployment and think they could be abandoned 2 years later...

The other elephant in the room I only briefly mention here is rkt, a question that was raised in the previous overview article, which we only quickly answered in the article. It feels like CoreOS doesn't focus on runtimes anymore, which is somewhat distressing considering they are the founders of the rkt project. It's now in the hands of the community and, while it is used in production out there, its future seems uncertain to me at least, especially since they do not have a stable release of their OCI/CRI implementation, as Philips mentioned in the article.

If I would be considering a Kubernetes deployment right now, I would certain think very hard about my options, and certainly consider "wait" as a priority... :)

Demystifying container runtimes

anarcat — Thu, 21 Dec 2017 14:07:27 +0000

[1]: Docker, LXC, rkt, cri-o, runc, and containerd

Maybe I don't understand this right, but I thought that runc wasn't really a separate runtime: at least Docker, cri-o and containerd (and i suspect rkt as well) are built on top of it, so it hardly qualifies as a separate "runtime". As for LXC, I do not believe it can be directly used within a Kubernetes environment, which is why it was mentioned only in passing.

Demystifying container runtimes

k8to — Thu, 21 Dec 2017 09:48:35 +0000

It amuses me that the runtime from mesos doesn't even get mentioned. I shouldn't be surprised, given that this is bubbling out of kubecon, but it feels like the mesos support for docker images hasn't gained interest most anyone outside the project.

Demystifying container runtimes

resouer — Thu, 21 Dec 2017 05:03:11 +0000

The reason runV and Intel CC can merge is because: 1. they already shared code for long time, 2. Intel OTC and Hyper can help each other more on both tech and non-tech aspects. So win-win.

While it's definitely not the case for the other runtimes ...

Demystifying container runtimes

jessfraz — Thu, 21 Dec 2017 00:40:08 +0000

It seemed imo the article was focused on the "runtimes" that are likely to be in kubernetes by default.

Demystifying container runtimes

jessfraz — Thu, 21 Dec 2017 00:36:49 +0000

Agree, on all your points and ya I know the politics... but it just makes me sad as far as who will be maintaining all these projects for the long term. It seems like it would be better to have as big a contributor base as that of kubernetes or the kernel to ensure it will be alive in longevity of the ecosystem around it.

Demystifying container runtimes

cyphar — Thu, 21 Dec 2017 00:26:51 +0000

Right now we have at least six[1], so two might be an improvement. The real problem (aside from strong personalities, lots of politics, and NIH) is that there is a legitimate distinction between some runtimes. And some of the differences are quite large technical details (at least I think so). You probably already know all of this Jess, but for those reading at home:

1. LXC is a much more VM-like container runtime. They boot an OS (including systemd, god help them) inside a container and manage it as though it was a VM (with virtual consoles and the whole shebang). Technically you can use LXC in the way that people use other runtimes today, but LXC also has a lot of other features that cater to that use-case. People who use LXC are likely not going to switch away from it. [As an aside, I'm quite disappointed that LXC wasn't mentioned in this article. In many ways the LXC folks are doing the majority of the really cutting-edge kernel work at the moment, and I enjoy working with them a lot.]

2. rkt is a pluggable runtime, designed so that different bits and pieces can be used. From my point of view, this extensibility is a massive strength. It also has quite a few security features that are unique to rkt, and it's a shame that the general community hasn't noticed that. It's also a general-purpose runtime unlike cri-o and cri-containerd.

3. And cri-o is a single-purpose runtime that borrows parts of rkt's ideas but doesn't have the extensibility or usability as a general-purpose runtime. Which is fine for Kubernetes, but people still want to use containers for things other than orchestration (like you!).

I'm not going to comment on containerd or Docker. My point is that while they all do mostly the same thing, due to a mix of technical and a *lot* of inter-personal issues I don't think a merger is possible. And while container runtimes are "plumbing", even plumbers have disagreements about the best way of structuring the pipes for an apartment block (at least I would assume so).

[1]: Docker, LXC, rkt, cri-o, runc, and containerd

Demystifying container runtimes

jessfraz — Wed, 20 Dec 2017 23:25:26 +0000

In my opinion it makes no sense that this split between runtimes has continued this far, I think with the open specifications there is no reason to have two other than differing opinions on small technical details.

I think we can all see at this point that there is no money to be made in a container runtime, it's purely plumbing.

I would love to see some sort of merger or something, since most of these people have worked together in the past. Can't we just have one really good container runtime, vs two?