https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
f
Windows, macOS, or Linux? If macOS, using admin mode to get bridged network? What is the conflicting subnet range?
f
Windows 10 Pro
f
@calm-sugar-3169 Any idea?
f
basically the network guys said we have to narrow down the ip addresses to this subnet - 172.31.0.0/16
f
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
172.30.186.63
this was the conflicting ip address
f
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
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
@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
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
Yeah, there is not much we can do unless we know what the address was used for
f
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
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.
53 Views
Open in Slack
PreviousNext
Powered by