Support Hostname in HTTP Active Healthcheck

[guydc]

Description: Currently, only method and path can be specified in Active Health Checks, added in #2244.

By default, envoy uses the cluster name/authority for active HTTP healthcheck hostname, https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/health_check.proto#envoy-v3-api-field-config-core-v3-healthcheck-httphealthcheck-host:

host (string) The value of the host header in the HTTP health check request. If left empty (default value), the name of the cluster this health check is associated with will be used. The host header can be customized for a specific endpoint by setting the hostname field.

Envoy Gateway auto-generates the hostname value in case it's absent and uses the route's virtual host hostname:

https://github.com/envoyproxy/gateway/blob/3014795f0ce318f36d7dd740296f2784fee907d5/internal/gatewayapi/backendtrafficpolicy.go#L518

However, the end user currently has no way to specify the hostname through configuration:

https://github.com/envoyproxy/gateway/blob/3014795f0ce318f36d7dd740296f2784fee907d5/api/v1alpha1/healthcheck_types.go#L151

In some cases, the hostname must be rewritten to the target server's name or a different name altogether. EG can support this by explicitly exposing hostname for configuration in the active http healthcheck API.

[optional Relevant Links:]

Any extra documentation required to understand the issue.

[arkodg]

hey @guydc can you elaborate on use cases where the upstream hostname and health check server hostname differ ?

[guydc]

hey @guydc can you elaborate on use cases where the upstream hostname and health check server hostname differ ?

1. A backend may serve multiple virtual hosts representing different business micro services, and expose a dedicated hostname for healthchecking purposes that is not tied to a specific microservice. I agree that in general, it makes most sense for users to use path-based HC APIs rather than host-based ones.
2. In some cases, the upstream hostname may be a technical one including information about locality, priority, etc, e.g. svc-primary.com and svc-secondary.com are both upstream DNS hostnames, but the applicative hostname recognized by the system is svc.com.

I thought about limiting this API to only support auto-rewrite to the backend hostname. It's tricky to implement, since:

1. There's no support for auto-rewrite in Envoy for HCs (unlike regular traffic where the router can rewrite the host just-in-time after target selection), and
2. Our clusters may represent multiple backendsRefs with multiple backend FQDNs, possibly leading to ambiguous definition, if we rely on that as the source of the hostname.

[AlexKrudu]

Maybe it'd be reasonable to support full Envoy's health_check_config ?

{
  "port_value": ...,
  "hostname": ...,
  "address": {...},
  "disable_active_health_check": ...
}

I can't really think of use-cases for overriding address, but port_value and disable_active_health_check could be useful IMO