My application gateway is not exposing the service endpoints hosted on my private AKS cluster

Question

My application gateway is not exposing the service endpoints hosted on my private AKS cluster

cargobuddy 20

Perhaps I am missing something in the listener and backend configuration, but not sure. I am not able to configure the endpoints, and the backend always results into 502 error.

Vallepu Venkateswarlu 7,075 Reputation points Microsoft External Staff Moderator

2026-03-17T10:35:16.8166667+00:00
Hi @ cargobuddy,

Welcome to Microsoft Q&A Platform.

A 502 error encountered in Application Gateway can occur due to the following reasons:

502 errors are often an indication that the default health probe is unable to reach the backend VMs.

If access to the backend is blocked due to an NSG, UDR, or custom DNS configuration, the Application Gateway instances cannot reach the backend pool. This results in probe failures, which in turn cause 502 errors.

Follow the Troubleshooting bad gateway 502 errors in Application Gateway

Follow the link to Expose an AKS service over HTTP or HTTPS by using Application Gateway.

Also share the requested details in a private message for further troubleshooting.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Praveen Kumar Gudipudi 2,280 Reputation points Microsoft External Staff Moderator

2026-03-25T16:34:09.8+00:00
Hi @ cargobuddy,

Thank you for reaching out regarding the 502 errors from your Application Gateway when accessing services hosted on a private AKS cluster.

Based on the scenario, a 502 Bad Gateway from Azure Application Gateway indicates that the gateway is unable to establish a successful connection with the backend service. In private AKS setups, this is typically related to backend health, networking, or service exposure.

Key Areas to Validate

Backend Service Exposure in AKS

Since your AKS cluster is private, ensure that your application is exposed correctly:

Use ClusterIP with Ingress (recommended), or an Internal LoadBalancer

If using ingress, we recommend leveraging Application Gateway Ingress Controller (AGIC)

Validate:

kubectl get pods

kubectl get svc

kubectl get ingress

Ensure pods are running and the service port matches your application.

Backend Pool Configuration

In Application Gateway:

Verify that the backend pool points to the correct private IP or ingress endpoint

Ensure the backend port matches the service port exposed in AKS

Misaligned ports (e.g., 80 vs 8080) are a common cause of 502 errors.

Health Probe Configuration

A failed health probe will mark the backend as unhealthy, resulting in 502 responses.

Please check:

Backend Health status in Application Gateway

Probe settings:

Correct path (e.g., / or /health)

Matching protocol and port

Network Connectivity

Ensure proper network communication between Application Gateway and AKS:

Both resources are in:

The same VNet, or

Peered VNets with proper routing

Network Security Groups (NSGs) allow traffic:

From Application Gateway subnet → AKS node subnet

No User Defined Routes (UDRs) blocking traffic

DNS Resolution (if using FQDN)

If your backend is configured using a DNS name:

Ensure Application Gateway can resolve it via Private DNS Zone

Otherwise, consider using the private IP address

If Using AGIC

If you are using Application Gateway Ingress Controller:

Verify the controller is running and healthy

Check logs for sync issues:

kubectl logs -n kube-system <agic-pod>

Ensure proper permissions are assigned to the managed identity

Most Common Causes

Incorrect backend port configuration

Health probe path mismatch

NSG or routing blocking traffic

Backend service not reachable internally

DNS resolution issues for private endpoints
Praveen Kumar Gudipudi 2,280 Reputation points Microsoft External Staff Moderator

2026-03-26T11:44:27.12+00:00

Hi @ cargobuddy,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
cargobuddy 20 Reputation points

2026-03-27T07:59:13.0333333+00:00

Hi Praveen,We are still facing the issue with Azure application gateway. What is irritating is that the gateway creates a listener with default 80 port with backend set. On top of that, I have to manually create a listener with 443 port and valid certificate from key-vault store. I think this happens whenever AGIC pod gets restarted. This is unexpected and unwanted behavior. If I am missing anything in my ingress configuration, let me know.
cargobuddy 20 Reputation points

2026-03-27T08:05:00.4466667+00:00

Kindly arrange a meeting. I would like to show this behaviour.
Praveen Kumar Gudipudi 2,280 Reputation points Microsoft External Staff Moderator

2026-03-27T09:34:55.2466667+00:00

Hi @ cargobuddy,

Could you please check the private message and provide the required details for troubleshooting the issue further.

Here is the reference link on how to access & data retention policy of private messages in Microsoft Q&A.
cargobuddy 20 Reputation points

2026-03-30T12:00:40.73+00:00

Hello,

Not sure whether I could explain you the original problem. Let me explain that again:

As shown in the image above, the Ingress controller somehow deletes my manually created listener, and adds the above listener. However, that listener uses the HTTP protocol and port 80, despite of the fact that my ingress already specifies the TLS name, which is the same as the certificate name I have uploaded on my key-vault. Then after knowing this, again I had to manually create the listener with port 443 and HTTPS protocol, and delete the automatically created listener. Do I miss anything in my cluster or the ingress ? Kindly let me know as it is a production deployment. My root question is, why is my listener deleted. At least the AGIC should not delete any manually created configurations. That's a bug.

2 answers

Your answer

Vallepu Venkateswarlu 7,075 Reputation points Microsoft External Staff Moderator

2026-03-17T10:35:16.8166667+00:00

Hi @ cargobuddy,

Welcome to Microsoft Q&A Platform.

A 502 error encountered in Application Gateway can occur due to the following reasons:

502 errors are often an indication that the default health probe is unable to reach the backend VMs.

If access to the backend is blocked due to an NSG, UDR, or custom DNS configuration, the Application Gateway instances cannot reach the backend pool. This results in probe failures, which in turn cause 502 errors.

Follow the Troubleshooting bad gateway 502 errors in Application Gateway

Follow the link to Expose an AKS service over HTTP or HTTPS by using Application Gateway.

Also share the requested details in a private message for further troubleshooting.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Praveen Kumar Gudipudi 2,280 Reputation points Microsoft External Staff Moderator

2026-03-26T11:44:27.12+00:00

Hi @ cargobuddy,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
cargobuddy 20 Reputation points

2026-03-27T07:59:13.0333333+00:00

Hi Praveen,We are still facing the issue with Azure application gateway. What is irritating is that the gateway creates a listener with default 80 port with backend set. On top of that, I have to manually create a listener with 443 port and valid certificate from key-vault store. I think this happens whenever AGIC pod gets restarted. This is unexpected and unwanted behavior. If I am missing anything in my ingress configuration, let me know.
cargobuddy 20 Reputation points

2026-03-27T08:05:00.4466667+00:00

Kindly arrange a meeting. I would like to show this behaviour.
Praveen Kumar Gudipudi 2,280 Reputation points Microsoft External Staff Moderator

2026-03-27T09:34:55.2466667+00:00

Hi @ cargobuddy,

Could you please check the private message and provide the required details for troubleshooting the issue further.

Here is the reference link on how to access & data retention policy of private messages in Microsoft Q&A.
cargobuddy 20 Reputation points

2026-03-30T12:00:40.73+00:00

Hello,

Not sure whether I could explain you the original problem. Let me explain that again:

As shown in the image above, the Ingress controller somehow deletes my manually created listener, and adds the above listener. However, that listener uses the HTTP protocol and port 80, despite of the fact that my ingress already specifies the TLS name, which is the same as the certificate name I have uploaded on my key-vault. Then after knowing this, again I had to manually create the listener with port 443 and HTTPS protocol, and delete the automatically created listener. Do I miss anything in my cluster or the ingress ? Kindly let me know as it is a production deployment. My root question is, why is my listener deleted. At least the AGIC should not delete any manually created configurations. That's a bug.

Answer 1

Hello @cargobuddy ,

Apologies for the delayed response.

The path is reverting to the default routing because the Application Gateway Ingress Controller (AGIC) continuously enforces the configuration defined in the Kubernetes Ingress resources.

When application changes are deployed through the Azure DevOps pipeline, the pipeline reapplies or updates the Kubernetes Ingress configuration. AGIC then reconciles the Application Gateway to ensure it exactly matches the state defined in the Ingress manifest.

If the updated deployment:

Does not include the same path-based routing rules, or
Recreates or modifies the Ingress resource,

AGIC removes the existing path rules and falls back to the default backend configuration. As a result, traffic may be routed incorrectly, leading to HTTP 502 errors.

This behavior is expected and is by design when using AGIC.

This happens specifically during pipeline deployments:

AGIC treats Kubernetes as the single source of truth.
Any manual changes made directly on the Application Gateway are overwritten.
Each pipeline run reapplies and enforces the Ingress YAML configuration.
Missing or modified path-based rules during deployment cause AGIC to reset routing to the default configuration.

To prevent this from occurring:

Ensure all required path-based routing rules are explicitly defined in the Kubernetes Ingress YAML.
Maintain a consistent Ingress resource name across deployments.
Avoid making manual changes directly to the Application Gateway.
Verify that health probe paths align with the application endpoints.

If these conditions are met, routing will remain stable across deployments.

Traffic routing continues to work during application changes as long as the Kubernetes Ingress always defines the full path‑based routing configuration. Any routing reset happens because routing rules were not included in the deployment, not because deployments themselves are unsupported.

Always deploy a complete Ingress definition
Keep the Ingress name unchanged

AGIC does not retain or preserve previously configured routing rules. Instead, it reconstructs the routing configuration strictly based on the current Kubernetes Ingress YAML.

If all required paths are defined in the Ingress YAML, routing functions as expected.
If any paths are missing, AGIC defaults to the fallback backend configuration, which can result in HTTP 502 errors.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Answer 2

Hello cargobuddy,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your application gateway is not exposing the service endpoints hosted on my private AKS cluster.

The issue is not that Application Gateway “fails to expose endpoints”, but that it cannot reach or validate your AKS backend, usually because of failed health probes or network connectivity, resulting in HTTP 502 errors.

Follow the below steps to resolve it:

Verify your workload returns 200 OK within the cluster using: kubectl port-forward svc/<service> 8080:<port> curl `http://localhost:8080` If the app fails internally, fix it first – https://learn.microsoft.com/azure/aks/troubleshooting.
Check that the service exposes the expected pod IPs and ports: kubectl describe svc <service> kubectl describe endpoints <service> You must see healthy endpoints mapped to pods.
If your application does not respond on /, configure the correct probe path: annotations: appgw.ingress.kubernetes.io/health-probe-path: "/health" Any exposed path must return HTTP 200, as required by App Gateway health probes -https://learn.microsoft.com/azure/application-gateway/application-gateway-probe-overview.
Ensure the Ingress is correctly bound to Application Gateway: annotations: kubernetes.io/ingress.class: azure/application-gateway Also confirm that your service ports match the backend container target ports.
Review AGIC logs for configuration sync or backend pool errors: kubectl logs -n kube-system -l app=ingress-appgw The controller should continuously update listeners, rules, and backend pools -https://learn.microsoft.com/azure/application-gateway/ingress-controller-overview.
Check the backend addresses from Application Gateway: az network application-gateway show  --name <appgw>  --resource-group <rg>  --query backendAddressPools Compare with: kubectl get Both must contain the same pod IPs, as documented in Azure Backend Pool requirements.
Ensure the App Gateway subnet can reach pod CIDR and node subnet by checking NSGs, UDRs, and bidirectional VNet peering - https://learn.microsoft.com/azure/aks/upgrade-cluster#validate-networking.
Verify that the gateway itself is healthy: az network application-gateway show  --name <appgw>  --resource-group <rg>  --query operationalState It must show Running before traffic can be routed correctly.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

cargobuddy 20 Reputation points

2026-03-30T12:16:02.06+00:00

As soon as I create the listener again, and configure with the SSL certificate from key-vault store, all the things start working as before. That means, the problem is not with my backend. Rather, the AGIC forcefully deletes the manually created listener, but does not configure the new listener well, resulting in the false backend outage. It is not a backend outage, but misconfigured listener by AGIC done automatically.
Sina Salam 28,361 Reputation points Volunteer Moderator

2026-03-30T14:55:03.72+00:00

@cargobuddy

That automatically configuration is strange in your tenant.

I will advise you to raise a support ticket via your Azure portal if could not do the above. Also, you can contact Priority Customer Support (PCS) to resolve your issue faster.

Cheers.

Share via

My application gateway is not exposing the service endpoints hosted on my private AKS cluster

2 answers

Your answer