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.
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.
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.
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.
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.
As a Pivot, I can confirm: I am biased as hell.
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.
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.