Hacker News Reader

Comment by atombender | Hacker News Reader

You missed another, big reason: "Fewer, simpler moving parts" is the main reason I would prefer if Kubernetes could run without Docker as a container runtime.

At the moment, Kubelet needs to control the Docker daemon (a somewhat brittle relationship), and a bunch of concepts — from networking to volume management — could be simplified by making the container runtime more K8s-specific and less general-purpose. A tighter coupling would also mean you'd always be running K8s against the exact container logic it was made for, as opposed to now, where the loose coupling means you'll be subject to bugs (and there are so many) in new Docker versions.

That and the fact that Docker is increasingly building in competing concepts (services, etc.) via swarm mode, which I don't care for.

Docker still has a place for things like image building, of course.

View on HN

I would categorize that under 5: competition. Kubernetes started out as an extension/modification of Docker, and over time Docker has evolved some of the same features as its kub-based competitors. The result is an uncomfortable integration between partially competing platforms.

Personally I think the long-term solution is for kubernetes to adopt containerd - it's the small, stable, rock-solid container runtime that it needs.

Whether the Kubernetes community continues to build primarily on Docker, or switches to containerd - either way we will support them and help in every way we can. Behind the superficial internet drama, there is a solid engineering collaboration between both communities, particularly between Docker and Google. We may disagree on a lot, but at the end of the day we have a lot of users who rely on us, and we have a responsibility to work together to solve their problems.

> Kubernetes started out as an extension/modification of Docker, and over time Docker has evolved some of the same features as its kub-based competitors. The result is an uncomfortable integration between partially competing platforms.

That's quite inaccurate. It's is like saying that OpenStack started out as an extension to KVM. Both had very different (original) scopes.

> Whether the Kubernetes community continues to build primarily on Docker, or switches to containerd

Kubernetes has 3 container runtimes at the moment: Docker, Rocket, and the new remote runtime which allows you to plug in a separate server using a protobuf interface. There is a lot of focus on the remote runtime now. The CRI-O project for example is implementing a remote runtime that allows any OCI conformant runtime to be plugged into Kubernetes.

All of the early Kubernetes resources I can find describe it as involving Docker. Was running it without Docker really a thing early on?

No. Kubernetes was launched at the first Dockercon, with a very specific focus of "we want to help expand what can be done with Docker by leveraging the significant operational experience we accumulated at Google". They delivered very successfully on that promise.

The focus on diversifying away from Docker is very recent, and is the direct result of the competitive tension I talk about earlier in the thread. It's completely understandable.

EDIT: A perfect example of that competitive dynamic is actually this very thread! the GP (`sysexit`) works at a competing vendor. You can tell in his post that de-emphasizing the dependency on Docker is important to him. In fact that talking point is so recognizable that I knew where he worked before even looking him up. There is nothing wrong with that, every vendor has an "official party line", and Docker is no exception. The point is, this is a delicate issue which has more to do with inter-personal and business dynamics than with code. And you should definitely verify the credentials and agenda of everyone speaking of authority on the topic of containers platforms. We vendors are everywhere, and we are biased as hell.

> We vendors are everywhere, and we are biased as hell.

As a Pivot, I can confirm: I am biased as hell.

My day job is not related to containers, but yes, working in the industry has of course biased me (but my opinions are still my own).

> The focus on diversifying away from Docker is very recent, > and is the direct result of the competitive tension

I think you miss a reason at least equally as important, if not more: There are a lot of people who want to do non-container runtimes but still leverage the rest of Kubernetes. I don't want to say no to them (who am I to decide what tech is "good"?) but I don't want their code in my tree (too big already, too hard to maintain, too much email, etc).

Ergo: plugins.

You're absolutely right. I was focused on the subset of kub-based platforms which are container-focused and are overlapping more and more with Docker.

But you're right, kub itself is a neatly generic orchestration component which can be used with non-container things. That is an excellent reason for decoupling the underlying container runtime.

Docker have broken out some Docker logic into libraries, which is why the Garden team swapped out their driver to use runC. Kubernetes could presumably follow suit and target the libraries instead of the Docker daemon.

The experience of the Garden API (a containerising system that ultimately predates Docker) is that tighter coupling is actually a mistake.

If Garden had been tightly bound to its implementation or orchestrator, it'd still be using raw Linux system calls and running under a 2nd-generation orchestrator.

Instead it's now using runC, OS X or Windows APIs to create containers and runs under multiple consumers -- most heavily under Diego, a 3rd-generation orchestrator and Concourse, a project automation tool.

Disclosure: I work for Pivotal. Many, but not all, of the engineers who've worked on Garden work for Pivotal also.

Reply on news.ycombinator.com