https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rancher-desktop
a
This message was deleted.
f
Is there a reason you are not using network tunneling? I'm asking because we intend to make it the default in 1.14, and probably remove the legacy networking support in 1.15. So if there is any use case that works on the legacy stack, but not on the tunneling one, then we need to know about this before we remove the legacy stack.
Implied by this is that we are not going to look into any issues with the legacy stack anymore; any further fixes will exclusively go to the tunneling support.
We are aware that the tunneling stack does not forward all the ports to other distros in WSL (because it runs inside its own network namespace). This will be fixed in 1.14 (and is the reason it isn't yet the default).
w
Hi @fast-garage-66093, thank you for the answer. Yes, I am indeed not using network tunneling because then neither docker not kubectl can be used from the WSL. So are you saying that network tunneling will be the way to move forward in this case?
f
Assuming you are using Rancher Desktop 1.13.1, you should be able to use docker and kubectl from other distros. What doesn't work yet is accessing other ports of the cluster from the distros; they are only forwarded to the host.
It works for the legacy networking stack because all distros run in the same networking namespace (which is also the cause of many problems, as they share iptables etc)
w
so the next step would be to integrate with my Ubuntu WSL distro and enable network tunelling?
or should the WSL integration in that case be turned off?
f
No, it has to be turned on
w
i just reached out to a colleague who assured me that he has already tried that exact constellation: WSL integration and network tunneling enabled and the issue remains the same
at this time, it is more about figuring out a way to isolate the issue and investigate further. Do you have any suggestions as to how we can go about this?
f
I just tested it, and everything worked for me. I did have to delete an old 
~/.kube/config
file inside the Ubuntu distro so that Rancher Desktop could create the symlink.
Untitled
Copy code
suse@rd-w11-test-1:~$ rdctl.exe list-settings | jq .WSL
{
  "integrations": {
    "Ubuntu-22.04": true
  }
}
suse@rd-w11-test-1:~$ rdctl.exe list-settings | jq .experimental.virtualMachine.networkingTunnel
true
w
i see. does Rancher create such a symlink for the docker config file as well? should i delete that one too?
f
(You need to use 
rdctl.exe
from WSL; the Linux version doesn't work correctly with WSL)
👍 1
Doesn't create a symlink, but does seem to create the file:
Copy code
suse@rd-w11-test-1:~$ cat ~/.docker/config.json
{
        "auths": {
                "<https://index.docker.io/v1/>": {}
        },
        "credsStore": "wincred.exe"
}
w
ok.
f
You must restart Rancher Desktop after deleting 
~/.kube/config
for it to create the symlink
👍 1
w
but even so, the issue that a docker container cannot reach another container's port using the host machine's ip or host name is not going to be affected by this, right?
or should that be resolved when using the tunnel?
f
I don't know the latest state of this; @calm-sugar-3169 can you chime in?
w
okay. but just to be clear: I would even appreciate some advice as to how i can locate the problem. My guess right now is that the issue lies with accessing a port of a different container using the host ip. It also appears that when i use the 
IPAM.Config.Gateway
returned by 
docker network inspect <my-network>
instead of my host IP, it works? It also seems to work when I use the IP of the docker container directly (which is somewhat to be expected as the call "stays in the network" so to speak). At this point, I admit I'm just very confused. 🙂
c
@white-bear-30365 we are addressing this in 1.14
w
@calm-sugar-3169, i see. this exact issue? wow. do you (without making promises) have a rough plan when 1.14 will be released?
yeah i would try out a CI build
c
For this work, there are a few PRs that are under review and maybe a few more PRs to bump dependencies. But, I can certainly keep you in the loop
🙏 1
f
We don't have a plan for a release date yet, but generally speaking releases are supposed to be at least every 2 months, so end of May would not be an unreasonable expectation.
But getting validation before the release that everything works for you with the tunneling stack would be very helpful
w
ok, thanks to both of you. that is something i can work with. we can use the 
Config.Gateway
workaround for now. I really appreciate your support. I will see that I can get the tunneling stack to work.
But for now I'm gonna call it a night. it has to wait until tomorrow
f
👋
w
bye
4 Views
Open in Slack
PreviousNext
Powered by