<p><em>Note: I do not believe the issue I am experiencing is specific to Azure AKS or Application Gateway (AGIC), but it is the environment we are currently working in on the off chance that it impacts responses.</em></p>
<p>We have an AKS cluster leveraging a namespace-by-app model and managed identity.  All apps except for one have static hosts (i.e., <code>api.mydomain.com</code>) and one app, which is tenantized, utilizes a per-customer subdomain host model (i.e., <code>customer1.mypayquicker.com</code>).</p>
<p>When initially configuring the cluster, which implements E2E SSL, the health probes were configured with both a host and host header value in the health probes. For most apps the value was simply their publicly accessible address and for the tenantized app, a single subdomain was selected (<em>k8probes</em>). An example of what one of the probes looked like is provided below. This configuration resulted in the expected listeners, including <code>*.mydomain.com</code> for the tenantized app.</p>
<p><strong>Probe Config</strong></p>
<pre><code>livenessProbe:
    failureThreshold: 3
    httpGet:
      host: app1.mydomain.com
      httpHeaders:
      - name: Host
        value: app1.mydomain.com
      path: /healthz
      port: 443
      scheme: HTTPS
    periodSeconds: 30
    successThreshold: 1
    timeoutSeconds: 5
</code></pre>
<p>The <code>host</code> value being populated was an artifact of working through the E2E SSL configuration. An unintended side effect of the <code>host</code> value being populated was it was discovered that the probe traffic was being routed out of the cluster (dns resolution of the <code>host</code> address) and back in, which then was defeating the purpose of the probe and the pod answering the probe was not necessarily the one being tested.</p>
<p>We then removed the <code>host</code> value from the probes, only providing the path, port and scheme and host header to satisfy the wildcard SSL certificate and all probes were seemingly working as expected. When inspecting the Health Probes in the Application Gateway, all apps but the wildcard app, had a host listed that was equal to the value in the host ingress definition (below) and the wildcard app was listing <code>localhost</code>.</p>
<p><strong>Ingress Snippet</strong></p>
<pre><code>spec:
  tls:
  - hosts:
    - {{ .Values.application.ingressEndpoint | quote }}
</code></pre>
<p>The host value being reported for the probes aside, the probes were all succeeding, apps were online, none of the traffic was being routed out of the cluster and back in (traffic staying in the cluster as expected). However, even though the apps were online and probes succeeding, no traffic is routing to the wildcard app.</p>
<p>In this scenario, the ingress defintion has not changed, the static host apps all list a single host (app1.mydomain.com ...) and the wildcard app has its wildcard host (*.mydomain.com). The only difference was the removal of a static host in the probe defintions for all apps, which in the case of the wildcard app was <code>k8probes.mydomain.com</code>.</p>
<p>Reinstating the <code>host</code> value in the probe for the wildcard app allows traffic to once again flow to the app, which means it is also routing traffic out of the cluster once again to resolve the probe which is not workable.</p>
<p>I found this article which has a section for wildcard/multiple host names in listeners: <a href="https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview" rel="nofollow noreferrer">https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview</a> which states:</p>
<p><strong>Conditions for using wildcard characters and multiple host names in a listener</strong></p>
<pre><code>- You can only mention up to 5 host names in a single listener
- Asterisk * can be mentioned only once in a component of a domain style name or host name. For example, component1*.component2*.component3. (*.contoso-*.com) is valid.
- There can only be up to two asterisks * in a host name. For example, *.contoso.* is valid and *.contoso.*.*.com is invalid.
- There can only be a maximum of 4 wildcard characters in a host name. For example, ????.contoso.com, w??.contoso*.edu.* are valid, but ????.contoso.* is invalid.
- Using asterisk * and question mark ? together in a component of a host name (*? or ?* or **) is invalid. For example, *?.contoso.com and **.contoso.com are invalid.
</code></pre>
<p>Does anyone have any insight on how to correctly configure an E2E SSL host, with a wildcard host listener and with health probes which do not require traffic to be routed out of the cluster and back in again?</p>

James Legan
<p>The health probe behavior looks expected due to the limitation of listener.</p>
<p>For backend health check, you can't associate multiple custom probes per HTTP settings. Instead, you can probe one of the websites at the backend or use &quot;127.0.0.1&quot; to probe the localhost of the backend server. However, when you're using wildcard or multiple host names in a listener, the requests for all the specified domain patterns will be routed to the backend pool depending on the rule type (basic or path-based).</p>
<p>If you don't want the name resolution traffic sent out of the cluster, a workaround would be to add a <a href="https://learn.microsoft.com/en-us/azure/aks/coredns-custom#hosts-plugin" rel="nofollow noreferrer">coredns custom entry</a> so that it is locally resolved within the cluster.</p>
<p>Additional reference :
<a href="https://learn.microsoft.com/en-us/azure/aks/ingress-tls?tabs=azure-cli" rel="nofollow noreferrer">Use TLS with an ingress controller on Azure Kubernetes Service</a></p>
