3 ms·

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

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

sp332 6y ago
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.
p_l 6y ago
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.
moduspwnens14 6y ago
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 https://en.wikipedia.org/wiki/Open_Container_Initiative

sp332 6y ago

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.

p_l 6y ago

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.

moduspwnens14 6y ago

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 https://en.wikipedia.org/wiki/Open_Container_Initiative