This message was deleted.

My Windows-based process is trying to access one of the pods at IP/port

192.168.127.2:7140

Windows `ipconfig`:

seese@Einstein MINGW64 ~
$ ipconfig

Windows IP Configuration


Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::4caf:e1fb:f212:75c5%4
   IPv4 Address. . . . . . . . . . . : 10.0.0.10
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.0.1

Unknown adapter OpenVPN Data Channel Offload for NordVPN:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Unknown adapter Local Area Connection 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter Bluetooth Network Connection 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter vEthernet (WSL (Hyper-V firewall)):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::a099:4218:32d6:1b97%42
   IPv4 Address. . . . . . . . . . . : 172.19.48.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

Ubuntu (not RD) `ifconfig`:

seese@Einstein:/mnt/c/Users/seese$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.19.61.52  netmask 255.255.240.0  broadcast 172.19.63.255
        inet6 fe80::215:5dff:feb3:5a54  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:b3:5a:54  txqueuelen 1000  (Ethernet)
        RX packets 6199  bytes 883457 (883.4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 2586 (2.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 733  bytes 60941 (60.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 733  bytes 60941 (60.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth-rd-wsl: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.143.2  netmask 255.255.255.0  broadcast 192.168.143.255
        inet6 fe80::8835:32ff:fead:d840  prefixlen 64  scopeid 0x20<link>
        ether 8a:35:32:ad:d8:40  txqueuelen 0  (Ethernet)
        RX packets 434  bytes 41725 (41.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 365  bytes 33642 (33.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Sorry, I can't tell; I hope @calm-sugar-3169 can take a look next week; he is out today.

👍 I appreciate you taking a look! Have a good weekend

@agreeable-xylophone-88850 can you give me some steps so I can repro this on my end?

@calm-sugar-3169 I believe these steps are proper repro steps (hard to know since I can't use them in a working setup): https://gist.github.com/mikeseese/cca62f2dba7a453ebe172031a9490760#file-reproduction-steps-md primarily note the lines 24-27 in the

echo-server.yaml

file which specifies to use a

hostPort

Let me take a look, I'll keep you posted

I tried downgrading to 1.14.2 (which I'm 95% sure I was working before), following the official downgrade instructions, but I'm still not getting it to work. If I understand correctly, running

wsl ~ -d rancher-desktop

gives me a terminal for the RD WSL image that's running

k3s

under the hood. Running

ps | grep k3s

there does show it running as a bare metal process. So I'd expect that specifying

hostPort

in a

Pod

spec would show the port

12345

up as listening in

netstat -peanut

:

~ # netstat -peanut
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:6443          0.0.0.0:*               LISTEN      753/wsl-proxy
udp        0      0 127.0.0.1:323           0.0.0.0:*                           -
udp        0      0 ::1:323                 :::*

am I correct that sans RD that running k3s would bind the port from the pod on the machine running k3s? I also tried downgrading to k8s v1.27.12 to see if that would help, but it didn't I'm starting to doubt my sanity haha. I stopped NordVPN services (which were running but not active) and I ensured I had nothing on my windows machine bound to ports 80/443

Please use

rdctl shell

to get a shell inside the "VM". We are running in a separate network namespace, and

wsl -d rancher-desktop

will not switch to that namespace. So various things won't work correctly.

Thanks, using

rdctl shell

I can confirm that port

12345

is being bound in the "VM"; this was ran from inside of

rdctl shell

where

192.168.127.2

is the

eth0

interface:

/ # curl 192.168.127.2:12345/param?query=demo
{"host":{"hostname":"192.168.127.2","ip":"::ffff:192.168.127.2","ips":[]},"http":{"method":"GET","baseUrl":"","originalUrl":"/param?query=demo","protocol":"http"},"request":{"params":{"0":"/param"},"query":{"query":"demo"},"cookies":{},"body":{},"headers":{"host":"192.168.127.2:12345","user-agent":"curl/8.5.0","accept":"*/*"}},"environment":{"PATH":"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","HOSTNAME":"echo-server","KUBERNETES_SERVICE_PORT":"443","KUBERNETES_SERVICE_PORT_HTTPS":"443","KUBERNETES_PORT":"<tcp://10.43.0.1:443>","KUBERNETES_PORT_443_TCP":"<tcp://10.43.0.1:443>","KUBERNETES_PORT_443_TCP_PROTO":"tcp","KUBERNETES_PORT_443_TCP_PORT":"443","KUBERNETES_PORT_443_TCP_ADDR":"10.43.0.1","KUBERNETES_SERVICE_HOST":"10.43.0.1","NODE_VERSION":"16.16.0","YARN_VERSION":"1.22.19","HOME":"/root"}}/

So this seems like a network routing issue from windows to the RD host, in which case I'd expect just

ping 192.168.127.2

from Windows to work. With that said, not sure if the network tunneling does anything special for pods vs any port on the "VM" FWIW, I'm running Windows 11 Pro 23H2, OS build

22631.4317

, Windows Feature Experience Pack

1000.22700.1041.0

@agreeable-xylophone-88850 I’m just looking at the gist you attached, and noticed that you are trying to access the pod on

192.168.127.2

from the windows host correct?

trying to access the pod on

192.168.127.2

from the windows host correct?

@calm-sugar-3169 Correct. My actual application is using Google's Agones K8s extensions which starts up game server pods, which the game client on Windows gets matched to and connects to. It doesn't make sense for me to make a service because these pods are ephemeral and there can be several of them, each with their own port assigned to the k3s host. I've been able to successfully do this application until some time this year (and for at least a year+ prior to that). I'm only recently discovering this because I've created a workflow without K8s that I use more often than K8s, but I used to only use K8s as almost a daily driver to do these kinds of game server hosting on my Windows machine

The use case makes sense to me, but I’m not sure how far back I can go to determine if this ever worked. However, one thing I can confidently say is that if there is no exposed port on the host, there wouldn’t be any way to access that pod. I say this because I ran the example you included in the gist, and when I tried to look up the host port using

netstat -ano | findstr "12345"

, I didn’t see anything exposed at all. That’s why I suggested exposing ports in my previous response. Furthermore, I can confirm that once you have your ports exposed on the host, you should have no problem accessing the pods via

localhost

or any of the network interfaces on the host.

The ports are exposed from the pod to the k3s host (never the Windows host), at least in this mythical universe I seem to have crafted and swear I lived in. so within

rdctl shell

I can do

curl 127.0.0.1:12345/param?query=demo

(

192.168.127.2

also works), but it's not showing up in

netstat -alt

for some reason as I'd expect Regardless, my product has a regression that needs to be fixed. The solutions I see going forward are: • Moving away from RD and to self-managed k3s on a traditional WSL distro where hostPort will be accessible via the WSL network interface that's shared with Windows • Creating an virtual network interface in windows that will route to the network namespace that k3s server is running in (either delivered via RD or 3rd party) • Figuring out if I can find away to expose the the ephemeral, likely many, ports over to Windows, like using a service(s) with NodePort as you mentioned The only solution that potentially involves feature dev for RD is the second bullet, but it seems like it might be the most difficult to implement, so I'll investigate the other 2 options first. The first option feels like the closest to a production environment, but I've otherwise been really enjoying having RD since onboarding is super simple I really appreciate your time!! I'll let you know if I get anywhere

I had put a reminder on this thread for me, but am not sure if this is going to be fixed for 1.17. @calm-sugar-3169 can you tell?

I was under the impression this was going to fall under

wont-fix

or a "nice to have, but not sure the technical feasibility for it". I've already started maintaining a fork and distributing that installer to my users (though haven't figured out signing or auto updating yet). Not sure if it's the easiest solution but adding back the legacy networking mode to allow me to opt in is one solution if upstream is to get it to work. My gut feeling (without the experience) is the other solution would require a new virtual network interface and some routing layer to the namespaced network of the new networking tunnel mode

I don't know; there are various changes in the Windows networking stack that will be in 1.17; I'm just not sure if your use-case is covered by it.

I can check when it goes out or with an RC commit hash

The legacy networking code will definitely not come back, but there should be no lost functionality. So if something used to work, but doesn't anymore, then we'll try to fix that, if reasonably possible.

cool, just let me know!

Hi Mike, I forgot to give you an update. I already went ahead and fixed this issue, and it should be part of 1.17

will do! It's a bit hectic for me these next 2 weeks but I'll see if I can squeeze some time in this week to test it from main

no worries, thanks for reporting this 😄