Stuck at `Waiting for Kubernetes API` with WSL `networkingMode=mirrored`

[oidualc]

Actual Behavior

When WSL is configured to use networkingMode=mirrored, Kubernetes doesn't start, and is instead stuck at the stage Waiting for Kubernetes API.

Steps to Reproduce

• Set the following option in %USERPROFILE%/.wslconfig

[wsl2]
networkingMode=mirrored

• Open Rancher Desktop
• Enable Kubernetes

Result

Kubernetes doesn't start, and is instead stuck at the stage Waiting for Kubernetes API.

Expected Behavior

Kubernetes starts

Additional Information

This is very similar to #6517, but this issue is not resolved in Rancher Desktop 1.13.1.

Rancher Desktop Version

1.13.1

Rancher Desktop K8s Version

1.29.3

Which container engine are you using?

moby (docker cli)

What operating system are you using?

Windows

Operating System / Build Version

Windows 11 Pro 23H2

What CPU architecture are you using?

x64

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

None

Windows User Only

No response

[evilhamsterman]

Yep it was not resolved in 1.13 apparently I had turned off mirrored mode at some point.

It appears that k3s does start, it is accessible within in the wsl rancher-desktop, and if you copy the kubeconfig out from the rancher-desktop image it works. The problem seems to be that Rancher Desktop is trying to check the wrong IP. With networkingMode=mirrored the cluster is accessible from the host Windows on localhost/127.0.0.1 rather than whatever IP Rancher Desktop is trying to check.

This needs to be resolved because mirrored networking is due to become the default for WSL in the nearish future.

[evilhamsterman]

Even more information. When you enable networkingMode=mirrored the VM gets that same IP as the host computer. So I thought maybe it's trying to use that to test the api. The kubeconfig that works as above on 127.0.0.1 still doesn't work with VM/Host IP.

However if you have Windows 11 22H2 or higher you can also enable the experimental setting hostAddressLoopback=true If you do that and restart WSL I assumed that I would be able to access the cluster as above on the 127.0.0.1 and my host computer address. I can access the cluster via 127.0.0.1 as before, but I still can't access it via VM IP address.

You recently enabled your own Network Tunnel by default and that also appeared to causing issues. When I turned that back off now I was able to access the cluster via 127.0.0.1 and via my host IP address but Rancher Desktop still doesn't think the cluster is running.

At this point I'm not sure what IP Rancher Desktop is trying to access since both the localhost and the host IPs can access the cluster. However it seems to be that Rancher Desktop should be checking the .wslconfig to see if networkingMode=mirrored is enabled, if it is then rather than trying to use some IP in the VM you should just be using 127.0.0.1. It appears you do this on MacOS with your Lima backend

[pelifix]

Same problem on 1.14.1

[DmytroYanchuk-tomtom]

Same problem on 1.15.0