Creating cluster fails in M2 Macbook

[jonsnowseven]

What happened:

kind create cluster fails in an M2 Macbook. See logs.

What you expected to happen:

Kind cluster correctly created.

How to reproduce it (as minimally and precisely as possible):

kind create cluster

Anything else we need to know?:

Environment:

• kind version: (use kind version): kind v0.23.0 go1.22.3 darwin/arm64
• Runtime info: (use docker info, podman info or nerdctl info):

Client:
 Version:    26.1.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0-desktop.1
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.0-desktop.2
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.29
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-debug
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.23
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-extension
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.4
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-feedback
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.1.0
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.8.0
    Path:     /Users/joao.neves/.docker/cli-plugins/docker-scout

Server:
 Containers: 226
  Running: 35
  Paused: 0
  Stopped: 191
 Images: 190
 Server Version: 26.1.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e377cd56a71523140ca6ae87e30244719194a521
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.6.26-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 8
 Total Memory: 7.657GiB
 Name: docker-desktop
 ID: 6fa8c797-48ab-472c-8c98-6d2254957831
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/joao.neves/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

• OS (e.g. from /etc/os-release):

ProductName:            macOS
ProductVersion:         14.4.1
BuildVersion:           23E224

• Kubernetes version: (use kubectl version):

Client Version: v1.29.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.1

• Any proxies or other special environment settings?

[stmcginnis]

I hadn't noticed the kubelet log entry before:

"command failed" err="failed to run Kubelet: could not detect clock speed from output

That seems very odd.

But looking at the docker info output, there are a lot of stopped containers. I have seen strange behavior with consumed resources and other crud left after running a lot of different things. The first thing I would try would be to run docker systme prune -a --volumes to clean up your runtime environment a little. Then try kind create cluster again and see if there is any change.

[jonsnowseven]

Thanks @stmcginnis!
It still happens 😢

logs

[BenTheElder]

google/cadvisor#2237 (comment)

Is there any chance you have DOCKER_DEFAULT_PLATFORM set? #2718

[BenTheElder]

Based on the logs tarball I see AMD64 images, so I'm assuming this is a duplicate of #2718

Docker's "cross platform images" only use partial emulation that cannot run a workload like Kubernetes.

We can only run an arm64 kind cluster on an arm64 VM/host. (In theory a full AMD64 VM should be able to run AMD64 nodes).

#2718 for discussing thoughts on what we might do to warn or block this setting.

[jonsnowseven]

Hello @BenTheElder.

Yes, I have DOCKER_DEFAULT_PLATFORM set to linux/amd64. Should I unset it?

[BenTheElder]

Yes, or only set it when running certain other commands, or set it to linux/arm64 when using kind.

See more discussion in #2718

/triage duplicate
/close

[k8s-ci-robot]

@BenTheElder: Closing this issue.

In response to this:

Yes, or only set it when running certain other commands, or set it to linux/arm64 when using kind.

See more discussion in #2718

/triage duplicate
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.