Why Docker Is Deprecated in Kubernetes and What to Use Instead

Kubernetes has officially deprecated Docker support; the dockershim module that bridged Docker’s API to the Container Runtime Interface (CRI) is being removed, and future releases will no longer provide this bridge.

The deprecation stems from Docker’s lack of native CRI support and the maintenance burden of the bridge, as well as security concerns caused by unused Docker networking and storage features.

In a Kubernetes cluster, Docker (or any container runtime) is only used by kubelet to launch containers on nodes via the CRI. Since Kubernetes communicates exclusively through the CRI, a dedicated CRI runtime is now required.

Two primary CRI runtime implementations are recommended:

containerd – a lightweight runtime that originated from Docker, fully compatible with Docker’s image format and providing a complete CRI implementation; ideal for straightforward migration from Docker.

CRI‑O – developed by Red Hat, a minimalistic runtime that does not depend on Docker and is used in OpenShift; it focuses solely on the CRI without extra components.

Both runtimes are open‑source and can be inspected on GitHub ( https://github.com/containerd/containerd/ and https://github.com/cri-o/cri-o ).

Understanding the distinction between CRI and OCI runtimes is essential:

CRI runtime – receives gRPC requests from kubelet, translates them into OCI‑compatible JSON specifications, and forwards them to an OCI runtime.

OCI runtime – uses Linux kernel features (cgroups, namespaces) to actually create containers; examples include runC and gVisor.

OCI runtimes like runC execute directly on the host kernel, which can expose the host to vulnerabilities if the runtime is compromised. gVisor adds a “guest kernel” layer to isolate containers further, though it may have performance trade‑offs and limited compatibility.

In summary, Docker is no longer supported in Kubernetes; users should transition to a CRI runtime such as containerd (for Docker‑compatible workloads) or CRI‑O (for minimal, Docker‑free environments). Additionally, a clear grasp of the roles of CRI and OCI runtimes helps in making informed decisions about security, performance, and workload requirements.

Relevant links:

https://gvisor.dev/docs/

https://gvisor.dev/docs/user_guide/compatibility/