4 ms·

"docker containers" are more accurately called OCI containers, and have been standardized so that various container runtimes can use exactly the same container

"docker containers" are more accurately called OCI containers, and have been standardized so that various container runtimes can use exactly the same container images. Kubernetes can use docker runtime (dockerd) to run OCI containers, but Docker Inc strongly discourages the docker runtime being used directly for infrastructure. Docker runtime imposes a lot of opinionated defaults on containers that are often unwanted by infrastructure projects. (For example docker will automatically edit the /etc/hosts file in containers, in a way that makes little sense for Kubernetes, so Kubernetes has to implement a silly work around to avoid this.) Instead Docker Inc recommends using containerd as the runtime. containerd implements downloading, unpacking, creating CRI manifests, and running the resulting containers all without implementing docker's opinionated defaults on top. Docker itself uses containerd to actually run the containers, and plans to remove it downloading code in favor of using the one from containerd too. The only advantage to using docker proper for infrastructure projects is that you can use the docker cli for introspection and debugging. Kubernetes has created its own very similar cli that works with all supported backend runtimes, and also can include relevant Kubernetes specific information in outputs.

nextaccountic 6y ago
Why do you spell containerd as "ContainerD"? You wrote dockerd without caps.
- kordlessagain 6y ago
  MANY THINGS IGNORE CAPS.
- tylersmith 6y ago
  dockerd is the literal name of a binary while containerd is the name of a project. As far as I can tell containerd stylizes its name in all lowercase but more than half the time I still see it written like a standard name, ContainerD, exactly like this.
  - cpuguy83 6y ago
    Being nitpicky here, but the canonical representation of "containerd" is all lowercase, as in the logo.
k__ 6y ago
Half-OT: What are alternative runtimes and why would you use them?
- mfer 6y ago
  For a runtime in your Kubernetes cluster there are containerd and cri-o. These are good for Docker / Open Container Initiative images. There are others... some for non-Docker image support. There are people running other things than just Docker these days. They are more niche case.
- freedomben 6y ago
  In the OpenShift world we use CRI-O and it has been awesome for us. I've never actually had it be a problem. Occasionally have to SSH into a node and inspect with crictl to see what's going on but it's almost always PEBKAC that points at CRI-O when it's not CRI-O's fault. I'd definitely recommend looking at it.
  - sandGorgon 6y ago
    How has been your experience with crictl ? Does it do everything that docker cli does ? Build, pull, etc ?
    - jsmith45 6y ago
      Only docker, buildkit, podman, buildah, and some non-Dockerfile based tools are able to build. CRI-O or containerd do not have build functionality. It does have pretty much everything else you expect like pull, ps, run exec, attach, rm, rmi, etc. If you need builds, I'd suggest either run dockerd alongside a containerd kubelet, or use buildkit.
      - sandGorgon 6y ago
        That's super valuable. Thanks! I did not know about buildkit (and buildctl), but now see it. Very valuable. Thanks!!!
- 6y ago
judge2020 6y ago
> 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?
- mfer 6y ago
  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/ https://www.docker.com/blog/what-is-containerd-runtime/
- jsmith45 6y ago
  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.
richardwhiuk 6y ago
OCI container images and Docker images aren't the same.
- dosethree 6y ago
  it would be more accurate that they both conform to the OCI runtime spec, right?

nextaccountic 6y ago

Why do you spell containerd as "ContainerD"? You wrote dockerd without caps.

kordlessagain 6y ago
MANY THINGS IGNORE CAPS.
tylersmith 6y ago
dockerd is the literal name of a binary while containerd is the name of a project. As far as I can tell containerd stylizes its name in all lowercase but more than half the time I still see it written like a standard name, ContainerD, exactly like this.
- cpuguy83 6y ago
  Being nitpicky here, but the canonical representation of "containerd" is all lowercase, as in the logo.

k__ 6y ago

Half-OT: What are alternative runtimes and why would you use them?

mfer 6y ago
For a runtime in your Kubernetes cluster there are containerd and cri-o. These are good for Docker / Open Container Initiative images. There are others... some for non-Docker image support. There are people running other things than just Docker these days. They are more niche case.
freedomben 6y ago
In the OpenShift world we use CRI-O and it has been awesome for us. I've never actually had it be a problem. Occasionally have to SSH into a node and inspect with crictl to see what's going on but it's almost always PEBKAC that points at CRI-O when it's not CRI-O's fault. I'd definitely recommend looking at it.
- sandGorgon 6y ago
  How has been your experience with crictl ? Does it do everything that docker cli does ? Build, pull, etc ?
  - jsmith45 6y ago
    Only docker, buildkit, podman, buildah, and some non-Dockerfile based tools are able to build. CRI-O or containerd do not have build functionality. It does have pretty much everything else you expect like pull, ps, run exec, attach, rm, rmi, etc. If you need builds, I'd suggest either run dockerd alongside a containerd kubelet, or use buildkit.
    - sandGorgon 6y ago
      That's super valuable. Thanks! I did not know about buildkit (and buildctl), but now see it. Very valuable. Thanks!!!
6y ago

judge2020 6y ago

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

mfer 6y ago
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/ https://www.docker.com/blog/what-is-containerd-runtime/
jsmith45 6y ago
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.

richardwhiuk 6y ago

OCI container images and Docker images aren't the same.

dosethree 6y ago
it would be more accurate that they both conform to the OCI runtime spec, right?