kind: DOCKER_DEFAULT_PLATFORM breaks kind if it does not match the dockerd host platform

When running kind create cluster it fails with the following log message:

$ kind create cluster
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.23.4) 🖼
 ✗ Preparing nodes 📦
ERROR: failed to create cluster: could not find a log line that matches "Reached target .*Multi-User System.*|detected cgroup v1"

Environment:

kind version:

$ kind version
kind v0.12.0 go1.17.8 darwin/arm64

Kubernetes version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:31:32Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"darwin/arm64"}

Docker version: (use docker info):

$ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.2)
  compose: Docker Compose (Docker Inc., v2.4.1)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 10
 Server Version: 20.10.14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  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 logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.104-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 5
 Total Memory: 7.765GiB
 Name: docker-desktop
 ID: LZ6O:NZMG:OHAC:45JC:ED7V:RX4B:O3X5:ENMG:CQ76:QAKS:S2UV:HWHJ
 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
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

macOS Monterey (v12.0) on Apple M1 Pro.

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 10
Comments: 30 (20 by maintainers)

Most upvoted comments

I had the same problem, but I then remembered I had added DOCKER_DEFAULT_PLATFORM=linux/amd64 to my ~/.zshrc. After unsetting the env-var it would still throw the same error. Only after removing the images completely (docker image rm ...) Docker would pull the correct image and the problem was gone.

svmaris on May 3, 2022

I was experiencing the same issue Fixed for me by creating an architecture-specific image

Dockerfile

FROM --platform=arm64 kindest/node:v1.23.4
RUN arch

Built as

docker build -t tempkind .

Then

kind create cluster --image tempkind

lukevs on Apr 18, 2022

@svmaris thank you! This was exactly my problem. I removed the environment variable, deleted the Docker images, and now it works like a charm.

subnetmarco on May 3, 2022

This is a fair point, though kind being implemented by way of exec(docker, ...) is a current leaky implementation detail FWIW, the client library wouldn’t respect all these env AFAIK.

I overlooked this, then maybe it’s better to completely sanitize the environment and let only the explicitly configured variables.

cavokz on May 31, 2022

Originally reported issue doesn’t appear to be related to availability of an image for arm64:

ERROR: failed to create cluster: could not find a log line that matches "Reached target .*Multi-User System.*|detected cgroup v1"

I have also created kind clusters on an M1 Mac successfully. I don’t think this specific version, but normal creation works fine. Marco’s issue appears to be something triggering a failure during the use of that image.

stmcginnis on Apr 18, 2022