0
votes
  1. There is a hello world service run in Azure Container Service, its address is http://52.168.172.165, can access this address and get response successfully in browser.
  2. Create an Azure Application Gateway using default setting and public IP
HTTP Setting: HTTP 80 <appGatewayBackendHttpSettings>
Listeners: HTTP 80 <appGatewayHttpListener>
Rules: 
     rule1: < appGatewayHttpListener> - <appGatewayBackendHttpSettings> -<appGatewayBackendPool>
Backend pools: 
appGatewayBackendPool
    Associated Rule: <rule1>
    Targets: 52.168.172.165

The issue is in the backend health, the status is unhealthy of 52.168.172.165:80. Since no backend service works, when I access address of Application Gateway, it shows 502 error.

But actually I can access the service http:// 52.168.172.165:80 in browser, my question is why the status is unhealthy in Application Gateway and how to correct it?

BTW, I had done some research for the issue, like following article https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-troubleshooting-502

For my backend service:

  1. A browser request to the backend service is serviceable.
  2. No timeout.
  3. 30 seconds is enough for the probe interval.

So what the issue is that show unhealthy?

1
If I take a look at the (IP) address you posted, I only get Welcome Your ASP.NET Core application has been successfully started. But there doesn't seem to be an actual application - rickvdbosch
it is just hello world test application. the welcome page is what we want. The expected result is, when I access to the application gateway, should return the welcome page - Lakin Lu
I expect Azure to be smart enough to see there is no application running, that's the reason you're getting the error. Try deploying a real application. - rickvdbosch
I have API Management instances as backends in Application Gateway and I had to use IP address for the backend pool but FQDN for the health checks. Health check with IP address did not work - same problem as you stated. - Kai Walter

1 Answers

0
votes

Configuring the backend pool to use the IP address and FQDN for health check worked great for me. Not sure why it wasn't entered as an answer.