BtK doesn't create correct aliases in hosts file

[dmikov]

Describe the bug When trying to forward api pod, all related services are getting mapped in the hosts. Unfortunately for some reason the MongoDb pods from replicaset getting wrong aliases, so api pod crashes with time out. Here is hosts file:

# Added by Bridge To Kubernetes
127.1.1.8 swimlane-sw-mongo swimlane-sw-mongo.default swimlane-sw-mongo.default.svc swimlane-sw-mongo.default.svc.cluster.local
127.1.1.7 swimlane-sw-mongo-1.swimlane-sw-mongo swimlane-sw-mongo-1.swimlane-sw-mongo.svc swimlane-sw-mongo-1.swimlane-sw-mongo.svc.cluster.local
127.1.1.6 swimlane-sw-mongo-0.swimlane-sw-mongo swimlane-sw-mongo-0.swimlane-sw-mongo.svc swimlane-sw-mongo-0.swimlane-sw-mongo.svc.cluster.local
127.1.1.5 swimlane-sw-mongo-2.swimlane-sw-mongo swimlane-sw-mongo-2.swimlane-sw-mongo.svc swimlane-sw-mongo-2.swimlane-sw-mongo.svc.cluster.local
127.1.1.4 sw-api sw-api.default sw-api.default.svc sw-api.default.svc.cluster.local
127.1.1.3 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local
127.1.1.2 sw-reports sw-reports.default sw-reports.default.svc sw-reports.default.svc.cluster.local
127.1.1.1 sw-web sw-web.default sw-web.default.svc sw-web.default.svc.cluster.local
# End of section

Notice that other services have domain part .default.svc.cluster.local, but mongo pods .svc.cluster.local, so when driver tries to talk to swimlane-sw-mongo-2.swimlane-sw-mongo.default.svc.cluster.local it cannot find it. Unfortunately this is what replica set recognizes itself as internally.

To Reproduce Steps to follow to reproduce this issue.

**Expected behavior** Expect BtK create a resolvable paths, the ones that are active inside the k8 **Logs** Attach logs from the following directory: For Windows: %TEMP%/Bridge to [Kubernetes]([url](url)) For OSX/Linux: $TMPDIR/Bridge to Kubernetes If you are a Visual Studio user, - Set the environment variable MS_VS_AZUREDEVSPACES_TOOLS_LOGGING_ENABLED=true - Open Visual Studio and run your scenario - Provide logs from: %temp%\Microsoft.VisualStudio.Kubernetes.Debugging **Environment Details** Client used VSCode Client's version: Insiders Operating System: Ubuntu 20.04 **Additional context** Add any other outputs from the clients or context you would like to share.

[dmikov]

bridge-endpointmanager-2021-07-15-11-55-36-674137.txt

[lolodi]

@dmikov Thanks for reporting this issue! We just discovered the problem fixed it. The fix is going to be part of the next release probably next week.

[dmikov]

Any update on release?

[lolodi]

Hi @dmikov, we had some slow down in in this latest release so it should be out in a week or so. Thanks for your patience! If you'd like, you can use our staging bits in the mean time following these instructions: https://github.com/microsoft/mindaro/issues/195#issuecomment-872663727

[dmikov]

I downloaded new version, but the problem still there.

[daniv-msft]

@dmikov Yes, the new VS Code version released recently only makes our new changes available to ~10% of the customers, so that we can detect issues without pushing the new release to 100% immediately. We did detect an issue with these 10% (binaries signing issue for some Mac customers), and so we are fixing this before pushing to more customers. If you want to try the fix @lolodi mentioned above, please feel free to try our staging bits as he suggests: it's quite easy to do, and you will get our latest version there.

[jhubsharp]

Hi Daniv, is this release still only in staging? I'm seeing the same issue trying to access a Mongo service from an app when I connect using BtK.

[daniv-msft]

@jhubsharp Thanks for your message. This was released already, so it looks like what you see is either a regression, either a case that we didn't handle properly. Would it be possible for you to share your hosts file after you're connected with Bridge? Could you please also reproduce the issue, and attach the latest bridge-library-*.txt log from:

• For Windows: %TEMP%/Bridge to Kubernetes
• For OSX/Linux: $TMPDIR/Bridge to Kubernetes

[jhubsharp]

Let me ask a question first. I was able to get this to work by providing command-line arguments to services that swap the service name in k8s with the correct resolving URL. In my case, this is all local development, so I'm having to change the mongo connection string from something like mongodb://user:password@mongo-service to something like mongodb://user:password@localhost:31999. It makes sense to me that when connecting outside of the cluster I can't use cluster URLs. Maybe what I'm seeing (and my workaround) is expected? Or is it expected that Bridge can change the environment variables?

[daniv-msft]

Hi @jhubsharp, The way Bridge works doesn't rely on changing the environment variables used by each local process (unless you're using our Kubernetes Service Environment Variables feature to bypass administrator requirements: https://docs.microsoft.com/visualstudio/bridge/kubernetes-environment-variables).

What we do is that we:

• Allocate local IPs and instantiate TCP listeners to collect any traffic sent to them.
• Update the OS hosts file to map the cluster's service name to one of this local IP.
• All traffic received on one of these TCP listeners is forwarded to our remote agent in the cluster (the pod we run in place of your service's pod), that takes care of replicating this same call, from inside the cluster this time.
• Similarly, when we get a response to our requests, we send them back to the debugged process. At this point, from the debugged process' perspective, it was able to send a call to the other service in cluster and get a response as if it was running in the cluster itself.

Now, for the things that we should check here:

• When Bridge is connected, if you open your hosts file, do you see the Bridge to Kubernetes hosts file updates?
• Do you communicate with some of your services in cluster using an IP, rather than a domain name? We cannot technically intercept calls made to an IP, because the hosts file doesn't allow us to. Domain names should work fine though, so the example above (mongodb) shouldn't be a problem.
• Did you enable the Kubernetes Service Environment Variable in your tasks.json, if you're using VS Code? This changes a couple of things, and could explain what you see.