I am currently setting up a multi-node Kubernetes cluster on Ubuntu 22.04, but I keep hitting a wall when executing the initial cluster bootstrap. When I run the kubeadm init command, the process hangs at the preflight checks or returns a CRI (Container Runtime Interface) socket error. I've ensured that swap is disabled and my ports are open, but I can't seem to get the control plane to initialize properly. Is there a specific configuration for containerd or the cgroup driver that I might have missed during the setup?
3 answers
The most frequent cause for kubeadm init failures in modern Cloud Technology environments is a mismatch between the container runtime and the kubelet's cgroup driver. Kubernetes now defaults to the systemd cgroup driver, so if your containerd or Docker configuration is still using cgroupfs, the initialization will fail. You need to verify your /etc/containerd/config.toml file and ensure SystemdCgroup = true is set. Additionally, ensure that your container runtime is actually running and the socket path is correctly identified.
Running kubeadm reset before each new attempt is also critical to clear out stale iptables rules or mount points from previous failed initializations.
That sounds frustrating! Are you seeing a specific error message regarding the 'image pull' phase, or is it strictly a connection timeout with the API server? Sometimes the default Google container registry is blocked in certain network environments, which prevents the essential control plane images from being downloaded during the init process.
You should check if your firewall (ufw) is blocking port 6443. Kubernetes cannot initialize the API server if that port isn't accessible locally for the health checks.
I agree with Lisa. Port conflicts or firewall rules are often the silent killers of cluster setups. As Kimberly mentioned, double-checking the cgroup driver is step one, but ensuring your network overlay can communicate is a very close step two for a successful bootstrap.
Mark, the error actually says "failed to run Kubelet: misconfiguration: kubelet cgroup driver: cgroupfs is different from docker cgroup driver: systemd". I thought Kubernetes was supposed to detect this automatically now. Do I need to manually create a Kubeadm configuration file to force both components to use systemd, or is there a way to fix this globally so I don't run into this issue again when I try to join the worker nodes to the cluster later this week?