18.3 Docker Kubernetes Relation

The Docker-Kubernetes relationship is frequently misunderstood, since Kubernetes does not actually run "Docker" in the way many assume, but rather runs OCI-compliant container images through a runtime like containerd directly, a distinction that became explicitly visible when Kubernetes deprecated and removed its direct Docker Engine integration, dockershim, without this affecting the actual ability to run images built with Docker at all.

What dockershim actually was and why it was removed

Dockershim was a compatibility layer Kubernetes used to translate its own internal container runtime interface (CRI) calls into instructions Docker Engine specifically understood, since Docker Engine itself was never designed to natively implement the CRI specification Kubernetes uses to communicate with container runtimes:

kubelet → dockershim → Docker Engine → containerd → runc

kubelet → containerd (directly, via CRI) → runc

Removing dockershim simplified this chain by having Kubernetes communicate directly with containerd, which Docker Engine itself was already using internally anyway, removing an unnecessary, additional translation layer rather than removing actual container-running capability.

Images built with Docker remain fully usable

The critical clarification this change makes visible: a container image built with docker build is an OCI-compliant image, and OCI-compliant images work identically regardless of which specific runtime ultimately runs them, which means dockershim's removal had no effect whatsoever on whether an image built with Docker could be deployed to Kubernetes:

docker build -t my-api .
docker push registry.example.com/my-api:1.4.2

spec:
  containers:
    - image: registry.example.com/my-api:1.4.2

This deployment continues to work identically before and after dockershim's removal, since the image itself, and the Kubernetes manifest referencing it, were never dependent on Docker Engine specifically being the runtime actually executing it on a given node.

Building images and deploying to Kubernetes as separate concerns

The practical workflow most teams actually use, building images with Docker (or an equivalent OCI-compliant builder) and deploying those images to a Kubernetes cluster running an entirely different runtime underneath, reflects this clean separation directly: Docker's value in this workflow is specifically as a build tool and local development environment, not as the production runtime actually executing containers within the cluster itself.

docker build -t my-api .
kubectl apply -f deployment.yaml

Recognizing this separation clarifies that "using Docker" and "using Kubernetes" are not mutually exclusive or competing choices; a team can, and commonly does, use Docker for local development and image building while deploying those same images to a Kubernetes cluster that has nothing to do with Docker Engine at all on its own nodes.

kubectl and docker CLI conceptual mapping

While the two tools operate at different levels of abstraction, several Kubernetes concepts map loosely onto familiar Docker ideas, which is useful context for someone already comfortable with Docker approaching Kubernetes for the first time:

docker run my-api
kubectl run my-api --image=my-api

docker ps
kubectl get pods

docker logs my-api
kubectl logs my-api-7d9f8b

These mappings are approximate rather than exact, since Kubernetes introduces considerably more structure, Pods, Deployments, Services, ConfigMaps, each with its own specific semantics, but the rough correspondence is a useful starting orientation rather than something to take as a precise, one-to-one equivalence.

Docker Desktop's own Kubernetes feature does not change this relationship

Docker Desktop's built-in, optional single-node Kubernetes cluster, covered in dedicated content elsewhere, runs a genuine Kubernetes control plane using containerd as its actual runtime, the same underlying relationship described here, just packaged conveniently within the same Desktop interface already used for ordinary Docker work, rather than representing some special, Docker-specific variant of Kubernetes.

kubectl config use-context docker-desktop

Common misconceptions worth addressing directly

A persistent misconception holds that Kubernetes "replaced" or made Docker obsolete; in reality, the two solve different, complementary problems, Docker as a development and image-building tool, Kubernetes as a cluster orchestrator running OCI images through whichever runtime it is configured with, and dockershim's removal specifically clarified rather than changed this underlying relationship.

"Docker is dead" — inaccurate; Docker Engine and Kubernetes serve different purposes
"Kubernetes runs Docker containers" — imprecise; Kubernetes runs OCI images via containerd or another CRI-compliant runtime

Common mistakes

• Believing dockershim's removal meant images built with Docker could no longer be deployed to Kubernetes, when the underlying OCI standard ensured full continued compatibility.
• Treating Docker and Kubernetes as mutually exclusive, competing choices rather than understanding their common, complementary use together in most real-world workflows.
• Assuming Kubernetes runs "Docker containers" literally, rather than understanding it runs OCI-compliant images through whichever CRI-compatible runtime, commonly containerd, is actually configured on each node.
• Treating the rough kubectl-to-docker command mapping as an exact equivalence rather than a loose, approximate orientation aid for someone newly approaching Kubernetes.
• Assuming Docker Desktop's built-in Kubernetes feature represents some special, Docker-specific variant rather than a genuine, standard Kubernetes cluster running the same underlying containerd-based architecture.

The Docker-Kubernetes relationship is best understood through the OCI standard that makes images interoperable regardless of which specific runtime ultimately executes them, with Docker serving as a build and local development tool and Kubernetes as a cluster orchestrator running those same standardized images through containerd or another CRI-compliant runtime, a relationship that dockershim's removal clarified explicitly rather than altered in any way that affects how teams actually build and deploy containerized applications.