https://rancher.com/ logo
#rancher-desktop
Title
# rancher-desktop
a

adamant-kite-43734

05/16/2023, 7:39 PM
This message was deleted.
f

fast-garage-66093

05/16/2023, 8:00 PM
Windows, macOS, or Linux? If macOS, using admin mode to get bridged network? What is the conflicting subnet range?
f

freezing-action-16232

05/16/2023, 8:00 PM
Windows 10 Pro
f

fast-garage-66093

05/16/2023, 8:01 PM
@calm-sugar-3169 Any idea?
f

freezing-action-16232

05/16/2023, 8:02 PM
basically the network guys said we have to narrow down the ip addresses to this subnet - 172.31.0.0/16
f

fast-garage-66093

05/16/2023, 8:12 PM
Ok, this is going to be a bit tricky, and I don't have time today to test it, but basic idea is to set the network ranges with "k3s server" parameters via
K3S_EXEC
in
/etc/environment
inside the VM. I don't know if this will work after k3s has already been initialized, so getting the value in there may be complicated. It should work via provisioning script, but it may need to be put in place directly after doing a factory reset.
The options can be found at https://docs.k3s.io/cli/server#networking
So you will need something like
Copy code
K3S_EXEC=--cluster-cidr "172.31.0.0/24" --service-cidr "172.31.1.0/24" --cluster-dns "172.31.1.10"
Or split the available network space into larger subnets if you expect to have mode pod/service, but I guess that is unlikely in a desktop setup 🙂
Anyways, I expect this will require a fair amount of experimentation to get it to work. Maybe @curved-zebra-30454 will be able to help with it
Please confirm that the conflicting IP address was in the
10.42.0.0/16
or
10.43.0.0/16
subnets. If it wasn't, then I'm looking at the wrong settings...
f

freezing-action-16232

05/16/2023, 8:19 PM
172.30.186.63
this was the conflicting ip address
f

fast-garage-66093

05/16/2023, 8:25 PM
Ok, so then it is not the cluster or server subnets that are the problem. Let's wait until @calm-sugar-3169 is back and see if he has suggestions
c

calm-sugar-3169

05/16/2023, 10:13 PM
As per Jan’s suggestion up above, looking at here: https://github.com/rancher-sandbox/rancher-desktop/blob/main/pkg/rancher-desktop/assets/scripts/service-k3s.initd#L62 it looks like you can provide the
--cluster-cidr
via provisioning scripts to define the cluster subnet you are looking for. Could the conflicting ip address come from a service/cluster (definition manifest)?
f

fast-garage-66093

05/16/2023, 10:23 PM
@calm-sugar-3169 I think
172.30.186.63
is more likely the WSL ethernet address than something inside the cluster
@freezing-action-16232 Where did this address come from?
What was it used for?
c

calm-sugar-3169

05/16/2023, 10:32 PM
It’s highly possible that is an IP address that belongs to the wsl network, I just don’t have enough context on what is the user experiencing and what kind of errors are they seeing. If the wsl address is in conflict with “one of the machine in our network” I don’t think they can even get to deploying a cluster.
f

fast-garage-66093

05/16/2023, 10:33 PM
Yeah, there is not much we can do unless we know what the address was used for
f

freezing-action-16232

05/17/2023, 6:32 AM
This address is the kubernetes server address, the one that sits in the .kube/config
So yes, this is all related with the subnet that the WSL gets configured
I was able to solve the problem by editing two values in the registry which essentially configure the subnet for the WSL
w

wide-mechanic-33041

05/17/2023, 11:20 AM
yeah thats the odd part for me. the cluster shouldn’t be exposed to the host. The WSL elected subnet is, but it is supposed to test the routeability of the subnet it chooses which it sounds like it did a poor job with.
48 Views