Rancher Desktop 1.20.0 regression with KIND

[WiseOldManRS]

Actual Behavior

I have been working on rolling out Rancher Desktop for my organization. We did a test group in June and we had really good results, everything worked as a drop in replacement. Since then, it appears that 1.20.0 has introduced a bug that is preventing KIND clusters from resolving DNS. I have a reproduction case to attach in 🧵 . I tested 1.19.3 and it works, then immediately doesn’t work in 1.20.0.

I don’t know where exactly this bash script came from — probably from the KIND project itself, but it’s what we’ve been using for local KIND clusters for a while.

setup.sh

As with any random bash script on the internet, please review it throughly before running. (edited)

I went through research to understand where that IP comes from, I identified the Lima docoumentation that explains why it’s using 192.168.5… address: https://lima-vm.io/docs/config/network/user/ — but I haven’t found a workaround besides downgrading.

I have reproduced this on both a fresh install of macOS as well as my company laptop. I was worried that our DNS filtering was causing this, but can confirm that there should be no issue with that.

Steps to Reproduce

Run setup.sh on Rancher Desktop 1.20.0 on an Apple Silicon Macbook

Result

Expected Behavior

Images should pull successful with working DNS

Additional Information

No response

Rancher Desktop Version

1.20.0

Rancher Desktop K8s Version

n/a

Which container engine are you using?

moby (docker cli)

What operating system are you using?

macOS

Operating System / Build Version

Macbook Pro 14 inch, 2021 M1 Max, 64GB RAM, Sequoia 15.6.1

What CPU architecture are you using?

arm64 (Apple Silicon)

Linux only: what package format did you use to install Rancher Desktop?

None

Windows User Only

No response

[jandubois]

I cannot reproduce the issue; the script worked fine on 1.19.3.

I then did a factory reset and let Rancher Desktop upgrade itself to 1.20.0 and ran the script again, and it once more started all the pods without any errors.

I did yet another factory reset, restarted Rancher Desktop and then switched to the QEMU virtualization engine. It again didn't work without problems.

Unless we get a repro case, there is not a whole lot we can about it.

[WiseOldManRS]

I am able to reproduce on my personal mac, here is exactly what I did:

Hardware info:
MacBook Air M1, 2020 (Apple M1 chip)
16GB Memory
Sonoma 14.3
Golang 1.24.0

kubectl version
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.15", GitCommit:"2c67202dc0bb96a7a837cbfb8d72e1f34dfc2808", GitTreeState:"clean", BuildDate:"2023-06-14T09:56:11Z", GoVersion:"go1.19.10", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v4.5.4
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.15", GitCommit:"2c67202dc0bb96a7a837cbfb8d72e1f34dfc2808", GitTreeState:"clean", BuildDate:"2023-06-15T01:11:29Z", GoVersion:"go1.19.10", Compiler:"gc", Platform:"linux/arm64"}

kind version
kind v0.30.0 go1.24.0 darwin/arm64

Installed Rancher Desktop 1.20 via GitHub releases
(https://release-assets.githubusercontent.com/github-production-release-asset/306701996/19091a8f-43d2-41dd-b7f1-321b27299e17?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-09-08T20%3A06%3A50Z&rscd=attachment%3B+filename%3DRancher.Desktop-1.20.0.aarch64.dmg&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-09-08T19%3A06%3A13Z&ske=2025-09-08T20%3A06%3A50Z&sks=b&skv=2018-11-09&sig=JFLFIOs346pbC14lS7tbsQ06okMwc%2BPLitr47po2RdE%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc1NzM1OTM1MywibmJmIjoxNzU3MzU5MDUzLCJwYXRoIjoicmVsZWFzZWFzc2V0cHJvZHVjdGlvbi5ibG9iLmNvcmUud2luZG93cy5uZXQifQ.c_TT2mdRNFLg48L9dABY45-Ky5vDIxLbjihqVQg4_SE&response-content-disposition=attachment%3B%20filename%3DRancher.Desktop-1.20.0.aarch64.dmg&response-content-type=application%2Foctet-stream) — I have no clue why this link is so insane but it’s the exact URL I downloaded

On Welcome screen, I disable Kubernetes

Container Engine = dockers
Configure PATH = automatic
[ OK Pressed ]

Rancher Desktop VM starts

Preferences -> Virtual Machine -> Emulation

VZ + Rosetta Support checked

[ Apply pressed]

Rancher Desktop VM restarts

In a terminal window:

Install Kind:
go install [sigs.k8s.io/kind@v0.30.0](http://sigs.k8s.io/kind@v0.30.0)

Update path in ~/.zshrc:
PATH=$PATH:/Users/MY_USERNAME/go/bin

bash setup.sh

kubectl get pods -A

kubectl describe pod cert-manager-646dddd544-8hbp4 -n cert-manager

In the console output, notice this:
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  59s                default-scheduler  Successfully assigned cert-manager/cert-manager-646dddd544-8hbp4 to development-interlinked-worker3
  Normal   BackOff    42s                kubelet            Back-off pulling image "[quay.io/jetstack/cert-manager-controller:v1.10.0](http://quay.io/jetstack/cert-manager-controller:v1.10.0)"
  Warning  Failed     42s                kubelet            Error: ImagePullBackOff
  Normal   Pulling    28s (x2 over 59s)  kubelet            Pulling image "[quay.io/jetstack/cert-manager-controller:v1.10.0](http://quay.io/jetstack/cert-manager-controller:v1.10.0)"
  Warning  Failed     10s (x2 over 42s)  kubelet            Failed to pull image "[quay.io/jetstack/cert-manager-controller:v1.10.0](http://quay.io/jetstack/cert-manager-controller:v1.10.0)": rpc error: code = Unknown desc = failed to pull and unpack image "[quay.io/jetstack/cert-manager-controller:v1.10.0](http://quay.io/jetstack/cert-manager-controller:v1.10.0)": failed to resolve reference "[quay.io/jetstack/cert-manager-controller:v1.10.0](http://quay.io/jetstack/cert-manager-controller:v1.10.0)": failed to do request: Head "https://quay.io/v2/jetstack/cert-manager-controller/manifests/v1.10.0": dial tcp: lookup [quay.io](http://quay.io/) on [192.168.5.2:53](http://192.168.5.2:53/): server misbehaving
  Warning  Failed     10s (x2 over 42s)  kubelet            Error: ErrImagePull

[WiseOldManRS]

I hope this helps @jandubois -- let me know if your hardware or software differs. I seem to be able to reproduce this on any macbook with apple silicon I've had access to. (Not to say that it works on an Intel mac -- I just don't have access to one)

[jandubois]

It works for me with both 1.19.3 and 1.20.0 when using QEMU with reverse-sshfs mount type.

It fails for me with both 1.19.3 and 1.20.0 when using VZ with virtiofs mount type.

So it is not a regression per-se.

However, the first configuration was the default in 1.19.3, and the second one the default for new installation, or after a factory reset, in 1.20.0.

I thought I had tested on 1.20.0 on Friday after a factory reset, but I must have upgraded a 1.19.3 installation instead, so was still running QEMU with 1.20.0. Which is why both configurations worked for me.

Anyways, it is weird that it fails with VZ and looks like a network configuration issue. But you should be able to get it working for you by switching back to QEMU.

[Nino-K]

@WiseOldManRS Thanks for providing the detailed repro steps. I'm wondering if this issue is only reproducible on Apple Silicon, as I can't reproduce it using your steps on x86.

[WiseOldManRS]

I unfortunately don't have an x86 Mac to test with :/

[jandubois]

@WiseOldManRS I can no longer reproduce the issue on M1 either, so maybe the DNS response got fixed on the quay.io side (the "server misbehaving" means that DNS was sending a response with a status that was neither NoError nor NXDOMAIN). QEMU and VZ handle DNS differently, which is probably whey QEMU was not affected by it.

[skandragon]

I am having this exact problem today using Rancher desktop 1.20.0, but I also had it with 1.19.3.

[ERROR] plugin/errors: 2 6615177818170786315.8367706788777567653. HINFO: read udp 10.244.0.2:51418->192.168.5.2:53: i/o timeout

This is on an M1 studio, using "kind cluster create" and then trying to bring up a minio pod.

A factory reset of Rancher Desktop did not fix the issue:

[ERROR] plugin/errors: 2 7300570164169935584.8479660393547804673. HINFO: read udp 10.244.0.3:47090->192.168.5.2:53: i/o timeout
[ERROR] plugin/errors: 2 7300570164169935584.8479660393547804673. HINFO: read udp 10.244.0.3:42259->192.168.5.2:53: i/o timeout

[jandubois]

I can no longer reproduce the issue on M1 eithe

It seems like I was using a different Docker context when testing on Friday. The issue is still reproducible with Rancher Desktop, and I have now reproduced it on an x86 machine as well¹.

Footnotes

1. On x86 Rancher Desktop still seems to incorrectly default to using QEMU instead of VZ, so you need to explicitly switch to VZ to repro. ↩