Repository navigation
Kubernetes stuck on "Starting: waiting for node to be ready" after upgrading to Docker Desktop 4.47.0 #7771
Description
Description
After upgrading Docker Desktop to version 4.47.0, Kubernetes does not start properly. It remains stuck in the "Starting: waiting for node to be ready" state indefinitely. Resetting Kubernetes or restarting or Uninstall and Reinstalling Docker Desktop does not resolve the issue.
OS: Apple M3 Pro-Sequoia 15.7
Reproduce
Install/Upgrade Docker Desktop to version 4.47.0.
Enable Kubernetes in settings (if not already enabled).
Wait for Kubernetes to start.
Observe status: "Starting: waiting for node to be ready" (never completes).
Expected behavior
Kubernetes should start successfully and show status as "Running", with the node ready and workloads schedulable.
docker version
Client:
Version: 28.4.0
API version: 1.51
Go version: go1.24.7
Git commit: d8eb465
Built: Wed Sep 3 20:56:26 2025
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.47.0 (206054)
Engine:
Version: 28.4.0
API version: 1.51 (minimum version 1.24)
Go version: go1.24.7
Git commit: 249d679
Built: Wed Sep 3 20:58:53 2025
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.7.27
GitCommit: 05044ec0a9a75232cad458027ca83437aae3f4da
runc:
Version: 1.2.5
GitCommit: v1.2.5-0-g59923ef
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
Client:
Version: 28.4.0
Context: desktop-linux
Debug Mode: false
Plugins:
ai: Docker AI Agent - Ask Gordon (Docker Inc.)
Version: v1.9.11
Path: /Users/rameshreddy/.docker/cli-plugins/docker-ai
buildx: Docker Buildx (Docker Inc.)
Version: v0.28.0-desktop.1
Path: /Users/rameshreddy/.docker/cli-plugins/docker-buildx
cloud: Docker Cloud (Docker Inc.)
Version: v0.4.29
Path: /Users/rameshreddy/.docker/cli-plugins/docker-cloud
compose: Docker Compose (Docker Inc.)
Version: v2.39.4-desktop.1
Path: /Users/rameshreddy/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.42
Path: /Users/rameshreddy/.docker/cli-plugins/docker-debug
desktop: Docker Desktop commands (Docker Inc.)
Version: v0.2.0
Path: /Users/rameshreddy/.docker/cli-plugins/docker-desktop
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.31
Path: /Users/rameshreddy/.docker/cli-plugins/docker-extension
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.4.0
Path: /Users/rameshreddy/.docker/cli-plugins/docker-init
mcp: Docker MCP Plugin (Docker Inc.)
Version: v0.20.0
Path: /Users/rameshreddy/.docker/cli-plugins/docker-mcp
model: Docker Model Runner (Docker Inc.)
Version: v0.1.41
Path: /Users/rameshreddy/.docker/cli-plugins/docker-model
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /Users/rameshreddy/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.18.3
Path: /Users/rameshreddy/.docker/cli-plugins/docker-scout
Server:
Containers: 18
Running: 18
Paused: 0
Stopped: 0
Images: 11
Server Version: 28.4.0
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
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
CDI spec directories:
/etc/cdi
/var/run/cdi
Discovered Devices:
cdi: docker.com/gpu=webgpu
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
runc version: v1.2.5-0-g59923ef
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.10.14-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 12
Total Memory: 7.653GiB
Name: docker-desktop
ID: ececf23d-5e8c-44da-bf3f-e3fedc227d77
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/rameshreddy/Library/Containers/com.docker.docker/Data/docker-cli.sock
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
::1/128
127.0.0.0/8
Live Restore Enabled: falseDiagnostics ID
C42B0E74-CE36-4470-92B8-166A8535B9B2/20250930063608
Additional Info
No response
Reacted by Krittin Phornsiricharoenphant, Robert Oliveira, Diego Rodriguez and Marc Demierre
Activity
eevlogiev commentedon Oct 1, 2025
Same here on my side:
Docker Desktop version: 4.47.0 (206054)
MacOS: Tahoe 26.0
nausikt commentedon Oct 1, 2025
Me too, please help!
Docker Desktop version: Version 4.47.0 (206054)
MacOS: Sonoma 14.6
voonyee commentedon Oct 2, 2025
hi @nagarameshreddy, thanks for reporting this.
As a workaround, can you:
Disable k8s, shut down DD, switch the default context to docker-desktop (
kubectl config use-context docker-desktop), start up DD, enable K8s. Then, see if Kubernetes is still stuck on"Starting: waiting for node to be ready"?nausikt commentedon Oct 2, 2025
Thank you! @voonyee. That's works for me too.
Edited:
It does related to default context, either we already set it in existing
.kube/configorKUBECONFIGin our env. Therefore, we need to changed it.nagarameshreddy commentedon Oct 2, 2025
Its worked Thanks
ranophoenix commentedon Oct 2, 2025
Hi! Unfortunately, this workaround didn't work for me:
MacOS: 26.0.1 (M1 Max)
nausikt commentedon Oct 2, 2025
You probably have existing
~/.kube/config. you guys can clear the way for DD to generate~/.kube/configthen merge your config later.Just let DD produce default
docker-desktopcontext first. once we skipped "Starting: waiting for node to be ready", we can handle context ourself later.This workaround, works for other folks because they might already have
docker-desktopcontext around.ranophoenix commentedon Oct 2, 2025
Thanks, @nausikt! It did work.
ranophoenix commentedon Oct 2, 2025
I already had the docker-desktop context around, but the initial workaround didn't work.
nausikt commentedon Oct 2, 2025
Ouchh, Thanks for pointed out!, then my another guess might be something went wrong with how they patch default context in our existing
~/.kube/config.nausikt commentedon Oct 2, 2025
Or may be it just have to be default context.
voonyee commentedon Oct 3, 2025
Thanks, everyone, for the input and feedback. Good to hear that it works now!
MrMYHuang commentedon Oct 9, 2025
Thank you. It works.
My case is a new install of Kubernetes. I just switched the default context from microk8s to docker-desktop and reset the cluster. Then, it worked.
bsousaa commentedon Oct 24, 2025
This issue has been fixed with Docker Desktop 4.49.0. I'll close the issue for now and will re-open if needed.