(Super naive layman question, I don't work in this space.)
What does this mean? I thought that Kubernetes manages Docker containers which makes the title kind of confusing.
What does this mean? I thought that Kubernetes manages Docker containers which makes the title kind of confusing.
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.
You wrote dockerd without caps.
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.
Does it do everything that docker cli does ? Build, pull, etc ?
If you need builds, I'd suggest either run dockerd alongside a containerd kubelet, or use buildkit.
Very valuable. Thanks!!!
There is another lower level of runtime, the OCI runtime, of which the main implementation is runc. Alternatives have interesting attributes, like `runv` running containers in VMs with their own kernel to get even grater isolation, `runhcs` which is the OCI runtime for running windows containers, etc. Most if not all of the higher level runtimes allow switching out the OCI runtime, but in general sticking with the default of `runc` is fine.
Is there a list of these defaults or other downsides to using docker instead of containerd?
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.
Here's an explanation I found helpful:
https://twitter.com/Dixie3Flatline/status/133418891372485017...
You can check out the project here: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl
There are also some pretty cool features. It supports building multi-arch images, so you can do things like create x86_64 and ARM images. It can also do build layer caching to a local registry for all of your builders, so it's possible to scale up your pod and then share each of the layers for really efficient builds.
Container images nowadays can be built by a variety of tools, and run by a variety of tools, with Docker likely being the most popular end-user tool with the most history and name recognition. Others like Podman/Buildah are differently-architected replacements.
As long as a container meets the open container specs, it can be built with whatever tool and run on whatever tool that also follows the specs.
The part of Kubernetes that runs containers has had a shim for docker along with an interface for runtimes to use. It's called the Container Runtime Interface (CRI). The docker shim that worked alongside CRI is being deprecated and now all runtimes (including Docker) will need to use the CRI interface.
These days there are numerous container runtimes one can use. containerd and cri-o are two of them. Container images built with Docker can be run with either of these without anyone noticing.
1. [common, informal] "An OCI container".
2. [pedantic, strictly accurate] "A set of tools for building & interacting with OCI containers".
This article is talking about the latter definition.
Docker is pretty much the a textbook example of why you probably shouldn't use the same word for a lot of different things.
Better yet, .Net.