Hacker News Reader

Comment by shykes | Hacker News Reader

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.

View on HN

> 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.

Reply on news.ycombinator.com