"Something went wrong: when trying to use B2K on AKS Http Application Routing cluster

[georgestevens99]

Describe the bug I am using an AKS cluster created with Http Application Routing enabled. This is a really quick, easy way to get code running on an AKS dev cluster. Behind the scenes Http Application Routing uses an Ingress controller. And during the cluster initialization process it produces an IP to connect to the cluster like > http://aks-webapi5a.1234567890123456789.eastus.aksapp.io. I have an ASP.Net core WebAPI at this address http://aks-webapi5a.1234567890123456789.eastus.aksapp.io./IntegrationTests/. And it works fine, plus my integration tests all work good with no errors. Thus I know my app is fully operational on this cluster.

When I try to use B2K on the WebAPI the form gets filled out automatically OK. The above URL appears (without IntegrationTests suffix) in the dialog when I select the AKS cluster. Then I manually select the K8s service webapi_avc (a ClusterIP with no external address) that fronts the WebAPI. Everything in the dialog looks good. I press Debug and Save and it says it is connecting to webapi_svc on the correctly named cluster. Then I get a "Something went wrong" error dialog. I look at the logs in TEMP and see nothing obvious.

Does B2K currently support using a cluster created with Http Application Routing? Or perhaps my webapi_svc needs to be something other than a ClusterIP, like a NodePort or LoadBalancer.

To Reproduce See above.

**Expected behavior** A clear and concise description of what you expected to happen. Note that the quickest and easiest way to get some code up and running on an AKS cluster is to use Http Application Routing to stand up a cluster. While this is definitely not suitable for production usage due to its security limitations, its main use is for dev and test. Therefore it is an ideal way to have "quick and easy" first few experiences (and maybe more) developing for AKS. Indeed that is what I did and was quite pleased with the minimum amount of details I had to deal with to get a running, standard K8s environment to work with in Azure. Note that AKS Http Application Routing uses an Ingress controller under the covers. Thus, it seems that providing the ability for Bridge to Kubernetes to work seamlessly both Http Application Routing and also separate Ingress controllers would support a wide number of potential users of the Bridge to Kubernetes simply because Http Application Routing is the "simplest thing that could possibly work" when developing for AKS in a dev cluster scenario. Please change Bridge to Kubernetes to support Http Application Routing and Ingress controllers, if it does not already do so. Thanks. **Logs** Attach logs from the following directory: For Windows: %TEMP%/Bridge to Kubernetes 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 (VS Code/Visual Studio): Visual Studio Version 16.10.3 Client's version: Operating System: Windows 10 **Additional context** Add any other outputs from the clients or context you would like to share. **See comment below.**

[georgestevens99]

I stopped Visual Studio and then restarted it and tried again and got some more dialogs that B2K presented, shown below, but still could not connect to my AKS cluster. I hope this more detailed info aids you in finding and fixing the problem. Thanks.

Can you tell me what I have to do to start using B2K with my services? Do I have to make a different AKS cluster that does not use Http Application Routing? If so, can you point me to an AKS document that demonstrates how to do what needs to be done to create a cluster useable with Bridge to Kubernetes.

[daniv-msft]

@georgestevens99 Thank you for logging this issue, and sorry you encounter it. I believe we tested Http Application Routing and that it worked, but I will double check with the rest of the team in case I'm thinking about another scenario.

I know you mentioned that you didn't see anything obvious in the logs, but would it be possible for you to send them to us, by attaching them to this issue or by email to BridgeToKubernetes@microsoft.com? Also, when you looked at the logs in your %TEMP% folder, did you look at the %TEMP%/Bridge to Kubernetes ones, the %temp%\Microsoft.VisualStudio.Kubernetes.Debugging ones, or both?

Regarding the issue with PID 4 binding on port 80 on all address, this is usually due to a Windows service that can be stopped/disabled, but is reported under PID 4. The typical example we see is BranchCache. Could you please open the Services app on your machine, and validate that the BranchCache service isn't running?

Alternatively, other services are known to block port 80:

• IIS
• w3svc (World Wide Web Publishing Service)
• MsDepSvc (Web Deployment Agent Service)

Is any of these running on your machine?

[georgestevens99]

@daniv-msft -- Thanks for your response.

First, I looked at what Windows Services I had running, and I did not have any of the services you listed running, including BranchCache.

However I did have the IIS Administration Service running. Is that what you mean by IIS? In a few minutes I will stop that service and see if it makes things work, then let you know later today.

AMENDMENT -- The below stuff is out of date. Please see the subsequent comment for the most recent logs. Thanks.

I have attached the log files as you requested.

First, from C:\Users\Geo\AppData\Local\Temp\Bridge To Kubernetes:

bridge-endpointmanager-2021-08-04-23-10-48-64696.txt bridge-library-2021-08-04-23-19-14-55412.txt bridge-mindarocli-2021-08-04-23-19-14-55412.txt bridge-library-2021-08-04-23-19-12-62156.txt bridge-mindarocli-2021-08-04-23-19-12-62156.txt

Next from C:\Users\Geo\AppData\Local\Temp\Microsoft.VisualStudio.Kubernetes.Debugging (which I did NOT inspect when debugging last week):

2021-08-04T21-46-54.9078270.log

Thanks for your assistance!

[georgestevens99]

Hello again. Please ignore the above logs. I did a run today and have better logs. I turned off all the services you listed (only IIS Admin Service was running) and still got the Pid4 blocked on port 80. The below logs came from that run:

C:\Users\Geo\AppData\Local\Temp\Microsoft.VisualStudio.Kubernetes.Debugging

2021-08-09T17-06-31.8854977.log

C:\Users\Geo\AppData\Local\Temp\Bridge To Kubernetes

bridge-mindarocli-2021-08-09-17-05-43-71368.txt bridge-library-2021-08-09-17-04-29-59736.txt bridge-mindarocli-2021-08-09-17-04-25-59736.txt bridge-endpointmanager-2021-08-09-17-06-08-61604.txt bridge-library-2021-08-09-17-05-43-71368.txt

Then I googled other apps that use port 80 and found that SQL Server Reporting Service uses it. Later today I will get a chance to stop that service and try again. Do you know of any other port 80 services?

Thanks, George.

[daniv-msft]

Thanks @georgestevens99 for your reply and trying to stop services. From the logs you shared and as you detected yourself, this looks indeed like the root cause of your issue.

I wasn't aware of SQL Server Reporting Service. I'm adding it to the list of the Windows services we know that can block port 80. Yes, if this one is running locally, stopping/disabling it should help.

FYI, if you choose to stop it rather than disable it (i.e. in the Services app, going to the service's Properties and setting the "Startup type" as "Disabled"), please note that some Windows service are super quick to come back. For example, even when stopped manually, BranchCache is restarted again after less than 1 minute. It might not be the case for SQL Server Reporting Service, but if you still get the same connection issue after stopping it, I'd suggest to double check that it didn't restart in the meantime.

[daniv-msft]

Also, from the logs, it looks like you're using an older version of the Bridge to Kubernetes Visual Studio extension. Even though I don't expect it would help much with the specific issue you have, please consider upgrading to get the latest bug fixes.

[georgestevens99]

OK! Got Bridge to Kubernetes running on my AKS cluster which uses Http Application Routing.

The culprit was indeed SQL Server Reporting Services (but not the Analysis Service). I googled around and found the following links that explain a surefire method for finding out what processes are using port 80. Perhaps someone will find them useful:

https://docs.microsoft.com/en-us/answers/questions/229871/pid4-system32ntoskrnlexe-blocking-the-port-80.html which references the below details

https://fujii.github.io/2019/07/12/windows-http-sys-port-80/

Thanks again for your assistance.

[daniv-msft]

Thanks @georgestevens99 for replying and sharing this link. We are using netstat as well on our side to determine processes blocking ports, but not with the -abo option here that requires elevated permissions. Good to know this allowed you to find the right service!

I'm closing this issue, but please feel free to reopen if the problem comes back.