BtK not forwarding ports exposed in cluster

[trenslow]

Describe the bug I'm not sure if this is a bug or design, but BtK no longer maps the ports of the other services in my cluster to my local machine. Instead, it chooses the port of the service I want to debug and additionally exposes two ports below that port, or simply exposes (debugging port - 2) for other services. For example, if I configure the service I want to debug to be exposed on port 9090, some services in the cluster are exposed on ports 9088, 9089 and 9090, while others are exposed simply on 9088.

To Reproduce Configure isolated service for debugging in a cluster where many services run and start the debugger.

**Expected behavior** When I first started using BtK, it would expose the services in my cluster on the same port as my local machine. For instance if I had a database listening on port 8080, the database service would be exposed on port 8080 on my local machine as well. Now the port is dependent on the port I configure for the service I'm debugging. I wouldn't expect this, as the whole point of BtK is to replicate the cluster environment on my machine as much as possible. Now, I would have to keep two environment configurations to know which ports to find my e.g. database service on; one for my local machine and one for the cluster. I also don't see what's to be gained from having three ports exposed per service, but more likely I'm not familiar with the use case. **Logs** [example.txt](https://github.com/microsoft/mindaro/files/6148080/example.txt) **Environment Details** Client used (VS Code/Visual Studio): VS Code Client's version: 1.54.3 Operating System: MacOS 11.2.3 BtK version: v1.0.120210310 **Additional context** I've tried other ports, removing the BtK-related resources in my cluster along with the extension and reinstalling/configuring, and tried restarting VS Code, my computer, etc. to see if that would jostle something, but unfortunately that didn't help me further.

[amsoedal]

Hi @trenslow, sorry to hear you're running into this issue. I don't think anything should have changed on our side with respect to the ports, but I will double check. In the meantime, could you please confirm that you you have "useKubernetesServiceEnvironmentVariables": false in your tasks.json file? And are you using a KubernetesLocalProcessConfig.yaml file?

[trenslow]

Hi @amsoedal, thanks for your support. I can confirm that I have "useKubernetesServiceEnvironmentVariables" set to false in tasks.json and I don't use a KubernetesLocalProcessConfig.yaml file.

[amsoedal]

@trenslow OK thanks for checking that. To clarify, are you seeing problems with the traffic getting routed to your pods (e.g. not being able to communicate with the services in your cluster)?

[trenslow]

Yeah exactly. The service I'm debugging on my machine is trying to talk to (among others) database pods running in the cluster. I can easily communicate with them if I choose the ports that BtK creates. However, it is not the same ports that my service would be communicating over with the database pods when running in the cluster.

[amsoedal]

@trenslow OK thanks for clarifying. I'll log a bug for this as it may be a regression on our side, we'll update this thread when we have more information.

[trenslow]

Great, thanks! Let me know if I can provide any other information.

[trenslow]

Hi @amsoedal I just wanted to add some more info. I no longer can communicate with the service running in the cluster on the incorrect ports that BtK exposes. So from my example above, communication over ports 9088, 9089, and 9090 also doesn't work. I even tried the pure IP address that BtK tells me the services are exposed on, and that's not working. Despite the fact that my /etc/hosts file is successfully filled out by BtK, neither the service name nor the raw IP address/port combos are not responding.

[amsoedal]

Hey @trenslow, thanks for adding these details. When you run "kubectl get po -n \<namespace>" do you see any pods crashing, etc? Also can you email me the logs in your temp folder at BridgeToKubernetes@microsoft.com ?

I don't know if this is the issue you're talking about or not, but I thought it was worth calling out that in the log file you've attached from a week ago, all the services are made available locally at \<IP>:55049 (give or take). This was an intentional decision to do on Mac, as we use pfctl to forward packets from 55049 to the correct port expected by the service. So you should never have to make any changes to the ports used by your services, you should simply be able to configure Bridge with the port that your currently debugged service listens on.

That being said, what you are describing does sound like a regression. I haven't had time to dig into it in detail yet, but getting all the log files (bridge-cli-*, bridge-library-* and bridge-endpointmanager-*) will help us diagnose what's going on!

[trenslow]

Hey @amsoedal, thanks for the quick response.

I don't see any crashing pods, everything looks good. The logs should be on the way to you.

I feel silly now, as when I was checking the communication this morning, I mistyped the ports. I go back to what I previously said before about communicating over port 55049, it works just fine. Sorry about the confusion!

That being said, I would still like to be able to configure the ports that expose the K8s services in my cluster, besides the one I'm debugging. Or at the very least to use the same ports. Are we now limited by pfctl here? When I first started using BtK, there were no restrictions on this; the ports that the services in the cluster were listening on were the same ports that were exposed on my local machine.

The reason for this is twofold; I would prefer not to maintain multiple environment configurations for the local and K8s environments. Also, the database service that service I'm debugging talks to requires that the network configuration where the client is running has the same topology as where the database is running.

[amsoedal]

@trenslow the fix should be out now in the 4/8 version! Let me know if it works for you :)