Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2023-03-10T14:49:49.687Z
Answers: I updated this setting but unf it didn't fix the problem. Somewhere along the way Ive taken a wrong turn.
Answers: ethrbunny
Answers: CC BY-SA 4.0
Answers: 2023-03-13T06:19:58.933Z
Answers: updated with another thing I remembered over the weekend that might solve the problem
Answers: Serve Laurijssen
Answers: CC BY-SA 4.0
Answers: 2023-03-20T12:41:20.887Z
Answers: 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.
Answers: ethrbunny
Answers: CC BY-SA 4.0
Answers: 2023-03-21T05:48:19.560Z
Answers: those things can take a long time indeed
Answers: Serve Laurijssen
Answers: CC BY-SA 4.0
Answers: 2023-03-08T08:07:25.020Z
Answers: 2023-03-13T06:19:21.370Z
Answers: 2023-03-13T06:19:21.370Z
Answers: Serve Laurijssen
Body: <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>
  
Tags: <docker><kubernetes><containerd>
Title: Migrating from dockershim to containerd - kubectl continues to show docker runtime
UserDisplayName: ethrbunny
ThreadText: # 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."<MASTERIP>:5000".tls]
            insecure_skip_verify = true
  
  ```
  
  and most important setting grpc.mirrors endpoint as http.
  
  ```
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."<MASTERIP>:5000"]
    endpoint = ["http://<MASTERIP>: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  
  
  ---
  
  