diff --git a/docs/adrs/cri-dockerd.md b/docs/adrs/cri-dockerd.md new file mode 100644 index 00000000000..47933938842 --- /dev/null +++ b/docs/adrs/cri-dockerd.md @@ -0,0 +1,53 @@ +# Package cri-dockerd to replace dockershim + +Date: 2022-07-29 + +## Status + +Accepted + +## Context + +Upstream Kubernetes dropped dockershim from the kubelet in the 1.24 branch: https://kubernetes.io/blog/2022/02/17/dockershim-faq/ + +This means that the docker container runtime is no longer directly supported by the Kubelet; continuing to use it +requires installing cri-dockerd to translate the CRI API to the Docker API. After some internal discussion, it was +decided that we did not wish to include dockershim, in favor of requiring users to deploy cri-dockerd themselves. + +``` + what’s our roadmap for dockershim/cri-dockerd migration? Kubernetes 1.24 finally drops dockershim. + RKE will clearly need to migrate over to cri-dockerd, but for products like K3s where docker is supported but not the default, do we want to keep it around? Seems to work OK in K3s with some slight modifications. + If we don't do this work, can a user configure k3s manually to use the shim? + I'd rather reduce the surface area if possible + the work is already done, the question is do we want to include it lol + Understood, the second half of the question is the part I care about + kk + Can they manually get there without it + If they can, then I don't want to include it. Less surface area for bug fixes and CVEs. And i don't see a need to make it easy for users to user docker with k3s. + users should be able to install and start cri-dockerd and then run k3s agent --container-runtime-endpoint=unix:///var/run/cri-dockerd.sock and it’ll work. + But we would need to drop the --docker flag since that explicitly uses the kubelet’s dockershim + Well, we historically did make it easy. If we want to stop, that’s fine. + Isn’t K3s supposed to be “lightweight” anyway? Who’s to say we didn’t put it on a diet for 1.24 and made it get smaller (especially cause the containerd split made it bigger) + Ok, I THINK bill will be ok with this. CW, can you pitch to bill next week (um he might be out too) that we are dropping the docker flag with 1.24. I guess we have a little time, so no rush right? + with the way the ecosystem has evolved, I think we can easily justify the diet + does k3d use/need --docker for anything? + Ask thorsten to be sure but I didn't think so. + But we do need product to agree, fyi +``` + +The initial releases of 1.24 shipped without docker support; use of the `--docker` flag returns an error indicating that +the user should install and use cri-dockerd instead. This has been somewhat disruptive to the community; K3s is often +used in CI or dev environments where it is useful to use docker as the container runtime, but users are not equipped to +install and manage cri-dockerd due to its relative inaccessibility compared to docker itself. Ref: +https://github.com/k3s-io/k3s/issues/5741 + +## Decision + +* We will embed cri-dockerd, and start it when the `--docker` flag is used. This is a drop-in replacement for K3s's + previous behavior when the Kubelet included dockershim. This meets user expectations around K3s support for the Docker + container runtime, and eases user adoption of Kubernetes 1.24. + +## Consequences + +* The size of our self-extracting binary and Docker images increase by several megabytes. +* We take on the support burden of keeping cri-dockerd up to date, and supporting docker as a container runtime.