Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> But Docker Inc strongly discourages the docker runtime being used directly for infrastructure.

Is there a list of these defaults or other downsides to using docker instead of containerd?



Docker did a nice blog post on this a few years ago. Docker uses containerd for running containers. It just does things on top of it that you don't need with Kubernetes. There's a nice diagram in the post, too.

https://www.docker.com/blog/what-is-containerd-runtime/


I'm not sure of any such list, but using containerd directly is faster, less likely to break k8s when docker adds new features, etc.

Much of this all stems from the flak infrastructure people gave docker when they made swarm part of the engine. But it comes to more than that. Docker has its own take on networking, on volumes, on service discovery, etc. If you are trying to use docker as a component of your own product, at least some of these are likely things you want to implement differently. And the same may well be true of any new features docker wants to add in the future. At which point one must ask why bother using docker directly?

containerd was quite literally created when docker decided to extract the parts of docker that projects like kubernetes might want to use. It has evolved heavily since then, but that really does capture the level at which it sits. This leaves dockerd in charge of things like swarm, docker's view on how networking should work, docker's take on service discovery, dockers view on how shares storage should work, building containers, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: