<p>First check what kubelet says</p>
<pre><code>journalctl -u kubelet
</code></pre>
<p>What worked for me was that in the plugins section in /etc/containerd/config.toml that systemdcgroup had to be true</p>
<pre><code>[plugins.&quot;io.containerd.grpc.v1.cri&quot;.containerd.runtimes.runc.options]
            SystemdCgroup = true
</code></pre>
<p><a href="https://kubernetes.io/docs/setup/production-environment/container-runtimes/" rel="nofollow noreferrer">https://kubernetes.io/docs/setup/production-environment/container-runtimes/</a></p>
<p>systemctl restart containerd after that of course</p>
<p>On another cluster the logs said something like &quot;server http response to https client&quot; so containerd did not end up pulling images.</p>
<p>The solution for that was to turn on TLS skip verify</p>
<pre><code> [plugins.&quot;io.containerd.grpc.v1.cri&quot;.registry.configs.&quot;&lt;MASTERIP&gt;:5000&quot;.tls]
          insecure_skip_verify = true
</code></pre>
<p>and most important setting grpc.mirrors endpoint as http.</p>
<pre><code>[plugins.&quot;io.containerd.grpc.v1.cri&quot;.registry.mirrors.&quot;&lt;MASTERIP&gt;:5000&quot;]
  endpoint = [&quot;http://&lt;MASTERIP&gt;:5000&quot;]
</code></pre>
<p>So one cluster on k8s V1.26 has the systemdcgroup as true and https enabled and the other on k8s V1.23 has systemdcgroup as true and http enabled. Only after those kubectl get nodes showed a CRI of containerd on both</p>

CC BY-SA 4.0
2023-03-10T14:49:49.687Z
I updated this setting but unf it didn't fix the problem. Somewhere along the way Ive taken a wrong turn.
ethrbunny
CC BY-SA 4.0
2023-03-13T06:19:58.933Z
updated with another thing I remembered over the weekend that might solve the problem
Serve Laurijssen
CC BY-SA 4.0
2023-03-20T12:41:20.887Z
This mainly solves the problem. Note that (at least in my case) /var/lib/kubectl/kubeadm-flags.env  doesn't have a trailing " by default. This caused me no end of headaches.
ethrbunny
CC BY-SA 4.0
2023-03-21T05:48:19.560Z
those things can take a long time indeed
Serve Laurijssen
CC BY-SA 4.0
2023-03-08T08:07:25.020Z
2023-03-13T06:19:21.370Z
2023-03-13T06:19:21.370Z
Serve Laurijssen
<p>Following directions from <a href="https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/#install-containerd" rel="nofollow noreferrer">here</a>. End goal is upgrading cluster to 1.24 and beyond.</p>
<p>At the end when I run <code>kubectl get nodes -o wide</code> seems like I would see 'containerd' as the runtime (<a href="https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/#verify-that-the-node-is-healthy" rel="nofollow noreferrer">link</a>) but instead I see <strong>docker://23.0.1</strong>. Granted - the other nodes are showing <strong>docker://1.13.1</strong> so its an improvement?</p>
<p>On the node I see many instances of <code>/usr/bin/containerd-shim-runc-v2</code> whereas on other nodes I see <code>/usr/bin/docker-containerd-shim-current</code> so its definitely <em>different</em>.</p>
<p>Anyway - what step(s) did I miss?</p>

<docker><kubernetes><containerd>
Migrating from dockershim to containerd - kubectl continues to show docker runtime
ethrbunny
# Migrating from dockershim to containerd - kubectl continues to show docker runtime

(Asked by: username_0 on 2023-03-07)

Following directions from [here](https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/#install-containerd). End goal is upgrading cluster to 1.24 and beyond.

At the end when I run `kubectl get nodes -o wide` seems like I would see 'containerd' as the runtime ([link](https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/#verify-that-the-node-is-healthy)) but instead I see **docker://23.0.1**. Granted - the other nodes are showing **docker://1.13.1** so its an improvement?

On the node I see many instances of `/usr/bin/containerd-shim-runc-v2` whereas on other nodes I see `/usr/bin/docker-containerd-shim-current` so its definitely *different*.

Anyway - what step(s) did I miss?

**Tags:** docker, kubernetes, containerd


---

## 1 answers

### Answer by username_1 on 2023-03-08. Score: 2 | Accepted answer

First check what kubelet says
journalctl -u kubelet

What worked for me was that in the plugins section in /etc/containerd/config.toml that systemdcgroup had to be true
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
            SystemdCgroup = true

https://kubernetes.io/docs/setup/production-environment/container-runtimes/
systemctl restart containerd after that of course
On another cluster the logs said something like "server http response to https client" so containerd did not end up pulling images.
The solution for that was to turn on TLS skip verify
 [plugins."io.containerd.grpc.v1.cri".registry.configs.":5000".tls]
          insecure_skip_verify = true

and most important setting grpc.mirrors endpoint as http.
[plugins."io.containerd.grpc.v1.cri".registry.mirrors.":5000"]
  endpoint = ["http://:5000"]

So one cluster on k8s V1.26 has the systemdcgroup as true and https enabled and the other on k8s V1.23 has systemdcgroup as true and http enabled. Only after those kubectl get nodes showed a CRI of containerd on both

> **Comments:**
> **username_0**: I updated this setting but unf it didn't fix the problem. Somewhere along the way Ive taken a wrong turn.  
> **username_1**: updated with another thing I remembered over the weekend that might solve the problem  
> **username_0**: This mainly solves the problem. Note that (at least in my case) /var/lib/kubectl/kubeadm-flags.env  doesn't have a trailing " by default. This caused me no end of headaches.  
> **username_1**: those things can take a long time indeed  

---

