Change:
<ins> --- title: "Migrate Docker Engine nodes from dockershim to cri-dockerd" weight: 9 content_type: task --- {{% thirdparty-content %}} This page shows you how to migrate your Docker Engine nodes to use `cri-dockerd` instead of dockershim. Follow these steps if your clusters run Kubernetes 1.23 or earlier and you want to continue using Docker Engine after you upgrade to Kubernetes 1.24 and later, or if you just want to move off the dockershim component. ## What is cri-dockerd? {#what-is-cri-dockerd} In Kubernetes 1.23 and earlier, Docker Engine used a component called the dockershim to interact with Kubernetes system components such as the kubelet. The dockershim component is deprecated and will be removed in Kubernetes 1.24. A third-party replacement, `cri-dockerd`, is available. The `cri-dockerd` adapter lets you use Docker Engine through the {{<glossary_tooltip term_id="cri" text="Container Runtime Interface">}}. {{<note>}} If you already use `cri-dockerd`, you aren't affected by the dockershim removal. Before you begin, [Check whether your nodes use the dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/). {{</note>}} If you want to migrate to `cri-dockerd` so that you can continue using Docker Engine as your container runtime, you should do the following for each affected node: 1.  Install `cri-dockerd`. 1.  Cordon and drain the node. 1.  Configure the kubelet to use `cri-dockerd`. 1.  Restart the kubelet. 1.  Verify that the node is healthy. Test the migration on non-critical nodes first. You should perform the following steps for each node that you want to migrate to `cri-dockerd`. ## {{% heading "prerequisites" %}} *   [`cri-dockerd`](https://github.com/mirantis/cri-dockerd#build-and-install) installed and started on each node. *   A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). ## Cordon and drain the node 1.  Cordon the node to stop new Pods scheduling on it: ```shell kubectl cordon <NODE_NAME> ``` Replace `<NODE_NAME>` with the name of the node. 1.  Drain the node to safely evict running Pods: ```shell kubectl drain <NODE_NAME>  --ignore-daemonsets ``` ## Configure the kubelet to use cri-dockerd The following steps apply to clusters set up using the kubeadm tool. If you use a different tool, you should modify the kubelet using the configuration instructions for that tool. 1.  Open `/var/lib/kubelet/kubeadm-flags.env` on each affected node. 1.  Modify the `--container-runtime-endpoint` flag to `unix:///var/run/cri-dockerd.sock`. The kubeadm tool stores the node's socket as an annotation on the `Node` object in the control plane. To modify this socket for each affected node: 1.  Edit the YAML representation of the `Node` object: ```shell KUBECONFIG=/path/to/admin.conf kubectl edit no <NODE_NAME> ``` Replace the following: *   `/path/to/admin.conf`: the path to the kubectl configuration file, `admin.conf`. *   `<NODE_NAME>`: the name of the node you want to modify. 1.  Change `kubeadm.alpha.kubernetes.io/cri-socket` from `/var/run/dockershim.sock` to `unix:///var/run/cri-dockerd.sock`. 1.  Save the changes. The `Node` object is updated on save. ## Restart the kubelet ```shell systemctl start kubelet ``` ## Verify that the node is healthy To check whether the node uses the `cri-dockerd` endpoint, follow the instructions in [Find out which runtime you use](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/). The `--container-runtime-endpoint` flag for the kubelet should be `unix:///var/run/cri-dockerd.sock`. ## Uncordon the node Uncordon the node to let Pods schedule on it: ```shell kubectl uncordon <NODE_NAME> ``` ## {{% heading "whatsnext" %}} *   Read the [dockershim removal FAQ](/dockershim/). *   [Learn how to migrate from Docker Engine with dockershim to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/). </ins>  No newline at end of file

Discussion:
Related to Source comment: This does not block 1.24. Add a how-to for users currently on 1.23 and earlier using Docker Engine with dockershim to migrate to cri-dockerd. Link the how-to in the section. I think the steps would be to install the cri-dockerd binary (), start the service, and add as extra args to the kubelet config /sig docs /language en /cc
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
: Note that it is supposed to read . The scheme will soon be mandatory, and Mirantis changed the default socket location. Otherwise agreed, should be similar to changing from docker to containerd (or to cri-o, new page/story) (this particular instruction would assume that the user already had Docker Engine installed and configured) If this would have been a new installation from scratch, the user would also need to . Before you begin Install cri-dockerd (includes enabling the units and configuring the cri-tools) Drain the node Configure the kubelet Restart the kubelet Verify that the node is healthy The jury is still out on whether we need systemd socket activation, or if we should just start cri-dockerd at boot ? Since the other runtimes don't bother with on-demand, maybe it would be enough with (the containerd instructions on the other page are still complicated, due to using the Docker installation of it)
/sig node
In my view, it's OK to provide outline instructions and to refer people to if they want more details.
/milestone 1.24 This'd really need to land for the v1.24 release or not at all.
/assign
I'm still hoping that Mirantis will provide a user-facing webpage and a packaged release, in time for Kubernetes 1.24.

The current development documentation and building might be OK for testing, but raises question about long-term...
we should add a warning / mention, that the user need to configure a CNI It is possible that they were still using kubenet before, by not configuring anything for docker EDIT: Might have spoken too soon, I think cri-dockerd still has the kubenet by default ?
do we need to add something about how to enable the "cni" network plugin, if used ? It needs to be configured in the CRI, and the feature (CNI) is still in Alpha stage when it comes to cri-dockerd Previously it used the kubelet flag, which has been removed.