# cri-dockerd for Kubernetes and Docker Engine

> cri-dockerd is a standalone Go adapter that exposes Docker Engine through the Kubernetes Container Runtime Interface. It is intended for environments that require the Docker runtime model, but it adds CNI and kubelet configuration responsibilities that native Docker support in Kubernetes once handled.

**Mirantis/cri-dockerd** — dockerd as a compliant Container Runtime Interface for Kubernetes

- Repository: https://github.com/Mirantis/cri-dockerd
- Website: https://mirantis.github.io/cri-dockerd/
- Stars: 1,371 · Forks: 356
- Language: Go
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mirantis-cri-dockerd

## Why cri-dockerd Exists After dockershim Removal

cri-dockerd solves a compatibility gap for Kubernetes environments that still depend on Docker Engine as their container runtime. Kubernetes components such as kubelet communicate with a runtime through the Container Runtime Interface, while Docker Engine presents a different API. This Go process supplies an adapter between those interfaces, translating Kubernetes CRI requests into operations against Docker Engine.

The project is aimed at platform operators and distributors rather than application developers deploying ordinary pods. The README specifically cites Mirantis Kubernetes Engine, Mirantis Container Runtime, and Docker Desktop as intended users or shipping contexts. It also describes the adapter as a standalone continuation of functionality formerly associated with Kubernetes dockershim.

That history matters because the solution preserves Docker Engine as an infrastructure choice, but it does not restore every part of the old integrated setup. Since version 0.2.5, the default network plugin is `cni`. Kubernetes 1.24 and later removed `kubenet` and other network plumbing from upstream during the dockershim removal. A working cluster therefore needs a separate CNI such as Calico, Flannel, or Weave. The adapter solves the CRI and Docker API boundary, while pod networking remains a separate requirement.

## The CRI Request Path Through Docker Engine

The central mechanism is a shim process. Kubernetes speaks CRI to `cri-dockerd`, and `cri-dockerd` controls Docker through the Docker Engine API. This arrangement lets an operator retain an existing Docker-based node model while presenting the runtime endpoint expected by Kubernetes.

The repository layout reflects several distinct responsibilities. Directories such as `backend/`, `libdocker/`, `containermanager/`, `network/`, `streaming/`, and `store/` separate Docker access, container lifecycle handling, networking, I/O handling, and state storage. Command startup and version handling are separated under `cmd/`, with `main.go` acting as the entry point. The `metrics/` directory also indicates a distinct observability surface, although the README does not document its endpoints or configuration.

The dependency list confirms the interfaces involved. It includes `k8s.io/cri-api`, Kubernetes components at `v0.29.15`, `github.com/docker/docker v27.0.2+incompatible`, and `google.golang.org/grpc`. CNI support is represented by `github.com/containernetworking/cni v1.1.2`. Based on those dependencies and package boundaries, the adapter handles CRI-facing requests, converts work into Docker operations, manages supporting runtime data, and participates in CNI-backed networking.

That architecture is more than a thin executable wrapper. It is a compatibility service whose configuration, socket wiring, network setup, and lifecycle behavior must match the rest of the node. The README does not document default socket paths or a complete kubelet configuration, so those details should be taken from the selected distribution's installation documentation rather than inferred.

## Package Installation and First Supported Use

The README does not include package names, repository setup commands, service configuration, or kubelet flags for installing `cri-dockerd`. It directs users to the official install page at `https://mirantis.github.io/cri-dockerd/usage/install/` for package-manager installation. A real node setup should therefore follow that page and the linked Kubernetes instructions rather than commands assembled from generic Docker guidance.

The first documented local action in the repository is for documentation development. From the repository root, the following Make target starts the Hugo development server:

```bash
make docs
```

The README states that the server is then available at `http://localhost:1313/`. This is a contributor workflow, not a runtime installation test, so it does not demonstrate that the adapter has connected to Docker or configured kubelet.

For unsupported platforms, the README separately directs operators to the manual installation page at `https://mirantis.github.io/cri-dockerd/usage/install-manually/`. The meaning of "unsupported" is not defined in the README. That makes platform selection an important pre-install check, especially for organizations that standardize on a particular operating system, package format, service manager, and Kubernetes distribution.

The repository also exposes a direct build target, but it is a source-tree development command rather than a documented installation procedure:

```bash
make cri-dockerd
```

The Makefile defines this target as a Go build that writes `cri-dockerd` in the current directory and embeds version, prerelease, and commit information. The documentation does not state that this locally built binary should replace a package-managed installation on a cluster node.

## CNI Responsibility and Cluster-Ready Networking

The largest operational constraint is the separation of runtime and network configuration. For users of `cri-dockerd` 0.2.5 or above, the default network plugin is `cni`. Upstream Kubernetes 1.24 removed `kubenet` and other network plumbing as part of dockershim removal and deprecation. Installing the adapter without a compatible CNI does not produce an operational cluster.

The README names Calico, Flannel, and Weave as examples, as well as the general category of another CNI. It does not say that `cri-dockerd` installs or configures any of them. The cluster operator must select one, deploy it, and ensure that its prerequisites are available on the nodes.

For continuous integration workflows that need basic networking, the README points to `containernetworking/plugins`. That statement is narrower than a production cluster recommendation. CI use, production networking, and platform support should not be treated as the same acceptance case. The README provides no metrics for scaling, image startup time, pod density, or upgrade behavior, so it cannot support a performance comparison with another runtime.

A careful deployment design should keep three concerns separate: access from kubelet to the CRI endpoint, access from `cri-dockerd` to Docker Engine, and CNI-managed pod networking. An error in any one of them can prevent cluster startup even when the adapter process itself has started. The available documentation does not enumerate each failure message, which makes logs and distribution-specific validation important during rollout.

## Maintenance, Versions, and Dependency Upgrade Cost

The repository is not archived, and its last push was on 2026-10-12. Recent releases include v0.4.9 on 2026-10-12, v0.4.8 on 2026-10-08, and v0.4.7 on 2026-09-09. These facts indicate recent release activity, although the README does not publish a support policy covering particular Kubernetes, Docker, or Go versions.

The current `go.mod` declares Go 1.24.9, Docker at `v27.0.2+incompatible`, Kubernetes libraries at `v0.29.15`, and the CRI API at `v0.29.15`. It also vendors dependencies under `vendor/`. Upgrading therefore requires checking compatibility across Go, Kubernetes, Docker, CNI, and the platform package, not merely replacing the `cri-dockerd` binary. The release branches in the README list different Go lines: `release/0.4` uses v1.26.x, while `release/0.3` uses v1.24.x.

That branch table also creates a practical warning: the dependency declaration on the default branch should not be assumed to describe every release branch. Organizations should select a release branch and build toolchain together. The Makefile embeds version data derived from Git tags and revision history, so reproducible packaging also depends on how the source and build metadata are supplied.

The project is licensed under Apache-2.0. Its LICENSE file and dependency licenses govern distribution and modification. This identifies the stated licensing model, but it does not answer organization-specific compliance questions or remove the need to examine bundled dependency licenses.

## cri-dockerd Versus Choosing a Cluster-Native Runtime

The relevant alternative is to select a runtime that Kubernetes supports through its normal CRI integration rather than adding an adapter whose purpose is Docker Engine compatibility. The decision should be based on the platform's required runtime model. If Docker Engine is not a requirement, an extra translation layer has little obvious value.

`cri-dockerd` takes the migration path described in the README: keep Docker Engine, remove the former built-in Kubernetes runtime component, and run the standalone CRI adapter instead. A cluster-native runtime approach starts from the runtime and communicates with kubelet through CRI directly. The second approach does not preserve a requirement to manage containers through Docker Engine.

There is a compatibility difference beyond terminology. `cri-dockerd` depends on the Docker Engine API and is tied to Docker-specific behavior, while CNI supplies networking separately. A distribution that has standardized its node images, runtime defaults, security controls, and support contract around Docker Engine may have reasons to retain this model. A new cluster with no such constraint has fewer project-specific reasons to introduce the adapter.

The README's motivation names Mirantis and Docker as parties maintaining the standalone shim, and says Docker continues to ship it in Docker Desktop. It does not publish a feature matrix comparing `cri-dockerd` with containerd, CRI-O, or other CRI implementations. As a result, operators should not select it merely for feature parity claims that the project documentation does not make.

## Conclusion

Adopt cri-dockerd when an operator or distribution specifically requires Docker Engine behind the Kubernetes CRI contract, and reject it when choosing the runtime independently, since newer cluster-native options are a cleaner fit. Before deployment, verify package-manager support for the node platform, select and install a supported CNI, and confirm how the distribution configures kubelet to use the cri-dockerd socket. The first decision is therefore operational compatibility, not merely whether the adapter can reach the Docker Engine API.

## FAQ

### What is cri-dockerd used for in Kubernetes?

It lets Kubernetes control Docker Engine by translating the Kubernetes Container Runtime Interface into Docker Engine operations. It is intended for environments that retain Docker Engine as their runtime.

### Does cri-dockerd configure pod networking?

Not by itself. The default network plugin is `cni`, and Kubernetes 1.24 or later requires a separate CNI such as Calico, Flannel, or Weave for cluster networking.

### How do I install cri-dockerd?

The README directs users to the official install page for package-manager instructions. Unsupported platforms are directed to the separate manual installation page.

## Sources

- [License: Apache-2.0](https://github.com/Mirantis/cri-dockerd/blob/master/LICENSE)
- [Mirantis/cri-dockerd on GitHub](https://github.com/Mirantis/cri-dockerd)
- [Project website](https://mirantis.github.io/cri-dockerd/)
- [README](https://github.com/Mirantis/cri-dockerd/blob/master/README.md)
- [Releases](https://github.com/Mirantis/cri-dockerd/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mirantis-cri-dockerd