Docker 20.10 and the Kubernetes dockershim Notice

Two announcements in the same week confused many teams: Docker Engine 20.10 was released on 8 December 2020, and Kubernetes 1.20 (also 8 December) deprecated the built-in “dockershim” that lets Kubernetes use Docker as its container runtime. They are different things with different consequences, and neither means your images stop working.

What 20.10 brings

Feature	Why it matters
cgroup v2 support	Needed by newer distributions that default to the unified hierarchy; better resource accounting
Rootless mode (supported)	Run the daemon and containers without root, reducing the impact of an escape
docker context over SSH	Manage a remote daemon securely with docker -H ssh://user@host or contexts
Improved logging	Logs remain readable with docker logs even when using remote log drivers (dual logging)
BuildKit improvements	Faster builds and secrets, still opt-in via DOCKER_BUILDKIT=1
Updated defaults	Newer seccomp profile and containerd 1.4

Upgrade like any engine update: test on a non-production host, read the release notes for removed flags, and remember that live-restore keeps containers running during the daemon restart.

docker version --format '{{.Server.Version}}'
sudo apt update && apt-cache policy docker-ce | head -5
sudo apt install docker-ce=5:20.10.0~3-0~ubuntu-focal docker-ce-cli=5:20.10.0~3-0~ubuntu-focal

What Kubernetes actually deprecated

Kubernetes talks to container runtimes through the Container Runtime Interface (CRI). Docker Engine predates CRI, so Kubernetes included a compatibility layer, dockershim, inside the kubelet. Maintaining it is a burden, and Docker itself already runs on top of containerd, which implements CRI directly.

flowchart TB
  subgraph NOW[Kubernetes 1.19 and 1.20 with Docker runtime]
    K1[kubelet] --> DS[dockershim inside kubelet]
    DS --> DD[dockerd]
    DD --> C1[containerd]
    C1 --> RC1[runc]
  end
  subgraph FUT[Direct CRI runtimes]
    K2[kubelet] -->|CRI| C2[containerd]
    K2 -->|CRI| CR[CRI-O]
    C2 --> RC2[runc]
    CR --> RC2
  end
  IMG[Images built with docker build<br/>OCI format] --> C1
  IMG --> C2

Kubernetes 1.20 prints a deprecation warning when it detects Docker as the runtime; removal is planned for a later release (the Kubernetes project has indicated late 2021). Until then nothing breaks.

What this does not mean

• Images built with Docker still run. They follow the OCI image standard, which containerd and CRI-O both use.
• docker build and Docker on your laptop or CI server remain fine. Developers keep using Docker.
• Compose and single-host Docker use are unaffected.

What may break later

Only things that depend on the Docker daemon being on the Kubernetes node:

• Pods that mount /var/run/docker.sock (monitoring agents, CI “docker-in-docker” tricks, log collectors).
• Scripts on nodes that call docker ps to inspect Kubernetes containers (use crictl instead).
• Logging or security tools that read Docker’s json log files or use the Docker API.
• Node images or tooling with Docker-specific settings (daemon.json options such as registry mirrors move to containerd configuration).

How to check your cluster

kubectl get nodes -o wide                                  # CONTAINER-RUNTIME column
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"  "}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.volumes[]?.hostPath.path=="/var/run/docker.sock") | .metadata.namespace + "/" + .metadata.name'

Managed services: EKS, GKE and AKS control their node images; check each provider’s plan. Newer EKS and GKE node images already offer containerd.

Practical plan

1. Now: inventory the docker.sock users above. Nothing is urgent.
2. 2021: build a test node pool with containerd, move a non-critical workload and run crictl ps, crictl logs, crictl images instead of the docker CLI.
3. Before upgrading to the release that removes dockershim: replace docker.sock dependencies (use Kaniko, Buildah or BuildKit for in-cluster builds), update log and security agents, and switch node runtimes.
4. Keep Kubernetes version upgrades regular, so this change arrives as one small step, not a leap.

For a single server or a Compose stack, the plan is simply: upgrade to 20.10 when your testing is done, and enjoy the new features.