Thanks, I looked at my kubelet.conf but doesn’t seem to have that:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data:XXXXXXXXXXXX
server: https://192.168.x.y:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: system:node:homelab-a
name: system:node:homelab-a@kubernetes
current-context: system:node:homelab-a@kubernetes
kind: Config
preferences: {}
users:
- name: system:node:homelab-a
user:
client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem
however I looked at the way I brought up the cluster with kubeadm, and it does point to dockershim
apiVersion: kubeadm.k8s.io/v1beta2
bootstrapTokens:
- groups:
- system:bootstrappers:kubeadm:default-node-token
token: abcd12345678efghi
ttl: 24h0m0s
usages:
- signing
- authentication
kind: InitConfiguration
localAPIEndpoint:
advertiseAddress: 192.168.x.y
bindPort: 6443
nodeRegistration:
#criSocket: /var/run/crio/crio.sock
criSocket: /var/run/dockershim.sock
name: homelab-a
taints:
- effect: NoSchedule
key: node-role.kubernetes.io/master
---
apiServer:
timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta2
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: 192.168.x.y:6443
controllerManager: {}
dns:
type: CoreDNS
etcd:
local:
dataDir: /var/lib/etcd
imageRepository: k8s.gcr.io
kind: ClusterConfiguration
kubernetesVersion: v1.19.3
networking:
dnsDomain: cluster.local
podSubnet: 10.1.0.0/16
serviceSubnet: 10.96.0.0/12
scheduler: {}
so despite not seeing any process running mentioning dockershim, and the kubelet config not saying “dockershim” specifically, it seems that it still might be using dockershim. I can try pointing to /var/run/containerd/containerd.sock in the kubelet config and restart the cluster to see if that works.