Kubernetes Dockershim弃用后，DIND在containerd运行时环境下的兼容性及运行原理咨询

Let’s unpack your confusion step by step—this is a super common question now that Dockershim is deprecated, and the answer boils down to how DIND interacts with Kubernetes and the host system.

1. DIND Runs an Independent Docker Daemon (No Host Runtime Dependency) #

First, let’s clear up the core misunderstanding: DIND doesn’t rely on the host’s container runtime at all. When you run the docker:dind image in a privileged Pod, you’re spinning up a fully self-contained Docker daemon inside that container. This daemon has its own internal runtime stack (these days, Docker actually uses containerd under the hood, but that’s irrelevant to the host’s containerd).

The privileged: true security context is the key here—it grants the DIND container full access to the host’s kernel capabilities. This lets the embedded Docker daemon do everything it needs to run containers: create network namespaces, manage cgroups, mount filesystems, and more. It doesn’t need the host’s docker.sock (which you’re not using anyway) or the host’s containerd instance—because it’s running its own complete container stack.

Kubernetes’ only role here is scheduling the DIND Pod onto a node and using the node’s containerd runtime to start the DIND container. Once that container is up, the embedded Docker daemon operates completely independently of the host’s runtime.

2. Dockershim Deprecation Doesn’t Impact DIND #

The removal of Dockershim in Kubernetes 1.24 only changes how Kubernetes communicates with the node’s container runtime. Previously, Kubernetes used Dockershim to talk directly to Docker daemons on nodes; now it uses the CRI (Container Runtime Interface) with compliant runtimes like containerd or CRI-O.

But this doesn’t affect DIND at all. To Kubernetes, your DIND Pod is just a regular container—Kubernetes uses containerd to run it, but what happens inside that container (running a Docker daemon) is entirely separate. As long as your node uses a CRI-compliant runtime (which containerd is), and you keep the privileged: true setting (required for DIND to access kernel resources), DIND will work exactly the same in 1.24 as it did in 1.21.

3. Your Test Configuration Is Exactly How DIND Is Meant to Run #

Looking at your Pod YAML:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: dind
  name: dind
spec:
  containers:
  - image: docker:20.10.12-dind
    name: dind
    ports:
    - containerPort: 2375
    securityContext:
      privileged: true
    env:
    - name: DOCKER_TLS_CERTDIR
      value: ''
  - name: client
    image: ubuntu:latest
    command:
    - sleep
    - infinity
    env:
    - name: DOCKER_HOST
      value: tcp://localhost:2375

This setup is spot-on for Kubernetes:

• The dind container runs the Docker daemon in privileged mode, listening on TCP port 2375 (you disabled TLS with DOCKER_TLS_CERTDIR='' for testing simplicity, which is perfectly valid).
• The client container shares the Pod’s network namespace, so it can reach the Docker daemon at tcp://localhost:2375 without extra networking hoops.

A Quick Security Note #

While DIND works reliably, keep in mind that privileged: true gives the container broad access to the host system. In production, this can pose security risks. If your goal is just building images, tools like Kaniko (which builds images without privileged access or a Docker daemon) are safer alternatives. But for use cases where you need to run containers for unit tests, DIND in privileged mode remains a valid approach.

内容的提问来源于stack exchange，提问作者Sirish Kumar Bethala