Unable to resolve DNS names for certain Cluster-IP services

[d6teo]

Describe the bug
Issue started after Visual Studio's extension upgrade to version 3.1.20230118.1.
Debugged services are not able to resolve DNS names to IP addresses for deployments that expose both a headless service and a Cluster-IP service.
(does not seem to occur when a deployment exposes a single Cluster-IP service)

Examples:
Redis (bitnami's Redis chart, StackExchangeRedis package used in debugged service): No such host is known
RabbitMQ (bitnami's RebbitMQ chart, RabbitMQ.Client package used in debugged service): No ip address could be resolved for (DNS name of service)
Also occurs when trying to follow the todoapi tutorial (as described in #150)

Mention the platform you are using
Microsoft Visual Studio Professional 2022, Version 17.4.3
Bridge to Kubernetes 2022 Version 3.1.20230118.1
Minikube Version: v1.23.2 running on HyperV

Expected behavior
Debugged services should be able to resolve DNS names to IP addresses for all deployed services.

Screenshots
Deployed services:

BTK8s setup for service 'activityapi':

Exception when debugged 'activityapi' services tries to resolve IP for service 'eventbus-development-rabbitmq' (it is however able to resolve other services whose deployments do not expose a headless service, e.g. 'periodicdataapi'):

Desktop (please complete the following information):

• OS: Windows 10 Enterprise Build 19045.2486

[elenavillamil]

@d6teo thank you for raising this issue. You mentioned "Also occurs when trying to follow the todoapi tutorial (as described in #150)", but todo app tutorial doesnt have any headless service. Do you have a sample application we could use to debug/reproduce on our end? Its okay if you dont, but it would help if you do. Does your headless service endpoint subset not include any address? Or does it have empty subsets?

Dev notes: I think it may be related to this PR: https://github.com/Azure/Bridge-To-Kubernetes/pull/78/files#diff-e56da5fef4dfa1b7746514ca010dc019e9cd7dea08c0cd6cea0e30d0a5d00d8b

[d6teo]

@elenavillamil Thanks for investigating.
Just re-tried the todo-app tutorial, now everything seems to work (no "socket hang-up" errors).
Not sure if this helps, when debugging database-api the app works as expected but the app's output shows some exceptions (see below):
Microsoft.Hosting.Lifetime: Information: Now listening on: http://[::]:5000
Microsoft.Hosting.Lifetime: Information: Application started. Press Ctrl+C to shut down.
Microsoft.Hosting.Lifetime: Information: Hosting environment: Development
...
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request starting HTTP/1.1 POST http://10.97.238.125/todos application/json -
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request finished HTTP/1.1 POST http://10.97.238.125/todos application/json - - 200 - application/json;+charset=utf-8 125.8295ms
Exception thrown: 'System.Net.Sockets.SocketException' in Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.dll
Exception thrown: 'System.Net.Sockets.SocketException' in System.Private.CoreLib.dll
`

Exception details:
System.Net.Sockets.SocketException
Message=The I/O operation has been aborted because of either a thread exit or an application request.
Source=Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets
StackTrace:
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.<GetResult>g__ThrowSocketException|7_0(SocketError e)
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult()
at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.<ProcessReceives>d__28.MoveNext()
This exception was originally thrown at this call stack: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult.__ThrowSocketException|7_0(System.Net.Sockets.SocketError)
Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketAwaitableEventArgs.GetResult()
Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal.SocketConnection.ProcessReceives()

In regards to the issue with deployments that expose headless services, i have noticed similar behavior; the debugged app is able to connect to these services however the output will occasionally show exceptions (SockerExceptions, RabbitMQ.ConnectionFailureExceptions - for RabbitMQ deployment, my guess is that these wrap networking exceptions)

The deployments/services exposed are the same as the ones illustrated in the original comment; however if I can provide any other info that can help with the issue, feel free to send over the commands that will get the required info (not really familiar with k8s concepts)

[elenavillamil]

Hi @d6teo the issue you saw with databaseapi was a bad image uploaded to public docker for the sample todo app. If you retry now it should work fine.

Regarding the headless service, fix for this got deployed today. Please feel free to re-open if you still see the issues after upgrading to latest version.