Change:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update to explain how to tell apart two cases that involve Docker Engine as a container runtime Docker Engine + dockershim + kubelet Docker Engine + cri-dockerd + kubelet The second case, using 2 third-party components, is not affected by the dockership deprecation. As a project we are not telling cri-dockerd users to migrate away. Why is this needed If someone is using cri-dockerd with Docker Engine, they don't need to take action relating to the deprecation of dockershim. That person might visit and then be confused about whether they still need to take action. Comments /sig node /priority important-soon /language en /kind feature Part of
Very relevant to
It really should say , rather than It doesn't say "for cri-containerd" or "for containerd with cri plugin", either. Adding an example could be done too, but not relevant here. It is covered on
Neither nor seem to have a way to tell the CRI in use ? They only describe the container runtime, and in some cases the API version... Needed to look at directly. The output of didn't help.
Looks like crictl is only documented under "debugging", even if required ? That is, is now required even for Docker (it wasn't, for dockershim)
/triage accepted
I think it would be more interesting to look at users using the "docker" container runtime, to see if they have changed CRI... They would need to change their CRI, from to cri- Including kubelet and crictl configuration ? But they don't need to relearn everything or transfer images, etc.
This should say "docker" (which the command does), and not (not really relevant) They main reason is in the confusion between container runtimes, and the CRI being used for them ? "This section presents information you need to know when migrating from dockershim to other container runtimes." Which of course doesn't make any sense to begin with, since dockershim is not a container runtime. So it should be divided into two: 1) how to change dockershim to cri-dockerd 2) how to change docker to containerd Of course, if you are already set on replacing the container runtime, then you don't need to bother with the first one.
That seems fair enough. We can also add instructions for switching your node from Docker Engine to something else, if we want.
where feasible we prefer to link to external docs that are specific to external tools, rather than document them ourselves. This case seems like a reasonable case for doing the documenting ourselves.
Unfortunately it also assumes that there are any good external docs, which doesn't seem to be the case for either CRI ? It is a big problem for minikube, the only container runtime which is easy to install (i.e. ) is no longer supported. So we end up having to pre-install all three of them, rather than doing some simple provisioning before the bootstrapping. "Patches accepted", I suppose...
Visual summary: ! The top diagram would be when running Kubernetes 1.23, and the bottom diagram would be when running Kubernetes 1.24 The docker installation () stays the same, the only introduction is the new cri-dockerd ()
From what I understand, needs to add info about how cri-dockerd users aren't affected, and how to check the CRI socket to tell if you do use cri-dockerd. (how? if crictl is not installed, is there another way?) Also, needs more guidance for migrating from dockershim to cri-dockerd (in addition to migrating from Docker Engine to containerd). Is this out of scope for this issue? /assign
I'd say yes: it is out of scope for this issue. It's fine to track a separate issue to add docs for that.
I believe that is mandatory, without dockershim But I assume you would look at kubelet configuration If it doesn't have any configuration, it is using dockershim. And thus it would be affected by this change. So far, we don't know what the minimum requirements on Kubernetes version and Docker version is, for it. But we can assume that anything after 1.20 and 19.03 should be fine, for changing to cri-dockerd 0.2.x. The recommendation would probably be to go with 1.24 and 20.10, and assuming a real release of 0.2.1 ? This is now up to Mirantis to describe, for cri-dockerd. Kubernetes version | Validated version --- | ---- 12 | 17.03 13 | 18.06 14 | 18.09 18 | 19.03 20 | ???
There is a . If you talk CRI to some unidentified CRI socket and the thing at the other end identifies itself as Docker Engine, odds on you're talking to or . You can narrow it down by running . That's likely to give you either the PID and name of the daemon involved, or possibly point to a socket-activation tool such as systemd. If it is systemd owning the socket, you'd grep through systemd config to find what's configured to listen on that socket.
Is this essentially an umbrella issue for and now?
It's all done!

Discussion:
The output is similar to the following. The column `CONTAINER-RUNTIME` outputs the runtime and its version. <ins> For Docker Engine, the output is similar to this: </ins> ```none <del> # For dockershim </del> NAME         STATUS   VERSION    CONTAINER-RUNTIME node-1       Ready    v1.16.15   docker://19.3.1 node-2       Ready    v1.16.15   docker://19.3.1 node-3       Ready    v1.16.15   docker://19.3.1 ``` <ins> If your runtime shows as Docker Engine, you still might not be affected by the removal of dockershim in Kubernetes 1.24. [Check the runtime endpoint](#which-endpoint) to see if you use dockershim. If you don't use dockershim, you aren't affected. For containerd, the output is similar to this: </ins> ```none <del> # For containerd </del> NAME         STATUS   VERSION   CONTAINER-RUNTIME node-1       Ready    v1.19.6   containerd://1.4.1 node-2       Ready    v1.19.6   containerd://1.4.1

``` Find out more information about container runtimes <del> on [Container Runtimes](/docs/setup/production-environment/container-runtimes/) page. </del> <ins> on [Container Runtimes](/docs/setup/production-environment/container-runtimes/) page. ## Find out what container runtime endpoint you use {#which-endpoint} The container runtime talks to the kubelet over a Unix socket using the [CRI protocol](/docs/concepts/architecture/cri/), which is based on the gRPC framework. The kubelet acts as a client, and the runtime acts as the server. In some cases, you might find it useful to know which socket your nodes use. For example, with the removal of dockershim in Kubernetes 1.24 and later, you might want to know whether you use Docker Engine with dockershim. {{<note>}} If you currently use Docker Engine in your nodes with `cri-dockerd`, you aren't affected by the dockershim removal. {{</note>}} You can check which socket you use by checking the kubelet configuration on your nodes. 1.  Read the starting commands for the kubelet process: ``` tr 0 ' ' < /proc/"$(pgrep kubelet)"/cmdline ``` If you don't have `tr` or `pgrep`, check the command line for the kubelet process manually. 1.  In the output, look for the `--container-runtime` flag and the `--container-runtime-endpoint` flag. *   If your nodes use Kubernetes v1.23 and earlier and these flags aren't present or if the `--container-runtime` flag is not `remote`, you use the dockershim socket with Docker Engine. *   If the `--container-runtime-endpoint` flag is present, check the socket name to find out which runtime you use. For example, `unix:///run/containerd/containerd.sock` is the containerd endpoint. If you use Docker Engine with the dockershim, [migrate to a different runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/), or, if you want to continue using Docker Engine in v1.24 and later, migrate to a CRI-compatible adapter like [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd). </ins>  No newline at end of file