Explain how to tell dockershim apart from cri-dockerd

[sftim]

This is a Feature Request

What would you like to be added
Update https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/ 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 https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/ and then be confused about whether they still need to take action.

Comments
/sig node
/priority important-soon
/language en
/kind feature

Part of kubernetes/kubernetes#104878

[sftim]

Very relevant to #30972

[afbjorklund]

It really should say # For docker, rather than # For dockershim

It doesn't say "for cri-containerd" or "for containerd with cri plugin", either.

Adding an example # For cri-o could be done too, but not relevant here.

It is covered on https://kubernetes.io/docs/setup/production-environment/container-runtimes/

[afbjorklund]

Neither kubectl nor crictl 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 /etc/crictl.yaml directly.

docker@minikube:~$ more /etc/crictl.yaml 
runtime-endpoint: unix:///var/run/dockershim.sock
image-endpoint: unix:///var/run/dockershim.sock

docker@minikube:~$ more /etc/crictl.yaml 
runtime-endpoint: unix:///var/run/cri-docker.sock
image-endpoint: unix:///var/run/cri-docker.sock

The output of crictl version didn't help.

Version:  0.1.0
RuntimeName:  docker
RuntimeVersion:  20.10.8
RuntimeApiVersion:  1.41.0

Version:  0.1.0
RuntimeName:  docker
RuntimeVersion:  20.10.8
RuntimeApiVersion:  1.41.0

[kbhawkey]

/triage accepted

[afbjorklund]

If someone is using cri-dockerd with Docker Engine, they don't need to take action relating to the deprecation of dockershim.

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 dockershim.sock to cri-dockerd.sock. Including kubelet and crictl configuration ?

But they don't need to relearn everything or transfer images, etc.

[afbjorklund]

https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/

This should say "docker" (which the command does), and not # For dockershim (not really relevant)

They main reason is in the confusion between container runtimes, and the CRI being used for them ?

https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/

"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.

[sftim]

it should be divided into two:

1. how to change dockershim to cri-dockerd
2. how to change docker to containerd

That seems fair enough. We can also add instructions for switching your node from Docker Engine to something else, if we want.

[sftim]

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.

[afbjorklund]

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. get.docker.com) 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...

[afbjorklund]

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 (docker.service) stays the same, the only introduction is the new cri-dockerd (cri-docker.service)

[shannonxtreme]

@afbjorklund @sftim

From what I understand, Find out what container runtime is used on a node 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, https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/ 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

[sftim]

more guidance for migrating from dockershim to cri-dockerd … is this out of scope for this issue?

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.

[afbjorklund]

if crictl is not installed, is there another way?

I believe that crictl 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
1.12	17.03
1.13	18.06
1.14	18.09
1.18	19.03
1.20	???

[sftim]

There is a Version request. 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 cri-dockerd or dockershim.

You can narrow it down by running lsof /path/to/unknown/socket. 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.

[chris-short]

@sftim Is this essentially an umbrella issue for #32131 and #31132 now?

[sftim]

It's all done!