Kind - Kubelet is not running(It may be related to the version or CPU architecture)

[fzj55]

What happened:
I'm trying to spin-up a cluster with command：
kind create cluster --image=kindest/node:v1.15.6

What you expected to happen:
I'm expecting to have a cluster up-and-running, however it fails and no cluster is available

Environment:
Mac with M2-cpu
kind version: (use kind version):
kind v0.20.0 go1.20.4 darwin/amd64
Kubernetes version: (what I want): v1.15.6
Docker version:
Server Version: 20.10.14
Storage Driver: overlay2

-----ERROR------
like #1709
&&
(In computer shell)
[kubelet-check] It seems like the kubelet isn't running or healthy.
[kubelet-check] The HTTP call equal to 'curl -sSL http://localhost:10248/healthz' failed with error: Get http://localhost:10248/healthz: dial tcp [::1]:10248: connect: connection refused.

Unfortunately, an error has occurred:
timed out waiting for the condition

This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
- 'docker ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
fengzhijie@FengzhijiedeMacBook-Pro podAffinityProject % kind create cluster --help
Creates a local Kubernetes cluster using Docker container 'nodes'
&&
(In container shell)
root@kind-control-plane:/# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/kind/systemd/kubelet.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Active: activating (auto-restart) (Result: exit-code) since Wed 2024-03-13 09:16:08 UTC; 376ms ago
Docs: http://kubernetes.io/docs/
Process: 1355 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS (code=exited, status=255/EXCEPTION)
Main PID: 1355 (code=exited, status=255/EXCEPTION)
CPU: 1.199s

Mar 13 09:16:08 kind-control-plane systemd[1]: kubelet.service: Consumed 1.199s CPU time.

----my thoughts----
The process architecture of kubelet does not match the CPU architecture of my computer. Is there any parameter that can specify the process architecture of kubelet?

[stmcginnis]

1.15 is way too old at this point. I would recommend using something recent.

If you really need to run 1.15 you may need to downgrade the version of kind you are using to the version that was current at the time. I'm not sure if it will still work though given the world has changed a lot since then.

[fzj55]

已经收到了谢谢

[stmcginnis]

Running amd64 on an m2 is probably going to introduce some issues as well.

[fzj55]

@stmcginnis Are you saying that maybe I can solve this problem with a lower "kind" version?

[stmcginnis]

Support for 1.15 ended several years ago, so I would recommend upgrading Kubernetes if you have a choice. Otherwise, yes, you will need to run an older version of kind. There have been various changes like cgroupv2 support and probably a lot more that most likely make the current kind release incompatible with a release that old.

[BenTheElder]

kind v0.20.0 go1.20.4 darwin/amd64

You should be running arm64 on M2

Kubernetes 1.15 is way out of support, current support from the core project is 1.26+ and while kind tries to support more we can't realistically make guarantees about 11 versions back (there are about 3 a year in kubernetes) https://kubernetes.io/releases/

[BenTheElder]

#2718

[BenTheElder]

This is almost certainly attempting to use cross-architecture kind clusters which does not work and will not be supported. You could get it to work inside a VM, but the kind cluster must match the host (VM or bare metal) architecture, docker's cross-architecture container support is too limited to run something like kind.