Hacker News Reader

Comment by sp332 | Hacker News Reader

I'd say it's down to two things. First is the sheer amount of work they're putting into standardization. They just ripped out some pretty deep internal dependencies to create a new storage interface. They have an actual standards body overseen by the Linux Foundation. So I agree with the blog post there.

The second reason is also about standards, but using them more assertively. Docker had way more attention and activity until 2016 when Kubernetes published the Container Runtime Interface. By limiting the Docker features they would use, they leveled the playing field between Docker and other runtimes, making Docker much less exciting. Now, new isolation features are implemented down at the runc level and new management features tend to target Kubernetes because it works just as well with any CRI-compliant runtime. Developing for Docker feels like being locked in.

View on HN

> By limiting the Docker features they would use, they leveled the playing field between Docker and other runtimes, making Docker much less exciting.

Isn't the most popular k8s case to deploy Docker images still though?

Yes. But I think k8s took a lot of attention away from Docker in terms of headspace and developer interest. RedHat for example is pushing CRI-O, which is a minimalist CRI-compliant runtime which lets admins focus even more on k8s and less on the whole runtime level.

Yes. The big difference, however, is that k8s removed docker from consideration when actually running the system. Yes, you have docker underneath, and are probably going to use docker to build the containers.

But deploy to k8s? There's no docker outside of few bits involving "how to get to the image", and the actual docker features that are used are also minimized. The result is that many warts of docker are completely bypassed and you don't have to deal with impact of legacy decisions, or try to wrangle system designed for easy use by developer at local machine into complex server deployment. And, IMHO, interfaces used by k8s for the advanced features are much, much better than interfaces used or exported by docker.

It's confusing, but Docker images (and image registries) are also an open standard that Docker implements [1].

A lot of the Kubernetes "cool kids" just run containerd instead of Docker. Docker itself also runs containerd, so when you're using Kubernetes with Docker, Kubernetes has to basically instruct Docker to set up the containers the same way it would if it were just talking to containerd directly. From a technical perspective, you're adding moving parts for no benefit.

If you use containerd in your cluster, you can then use Docker to build and push your images (from your own or a build machine), but pull and run them on your Kubernetes clusters without Docker.

[1] https://en.wikipedia.org/wiki/Open_Container_Initiative

Reply on news.ycombinator.com