Add Hostname to HealthCheckConfig

[tmc]

Right now the HealthCheckConfig can't/doesn't allow specification of the Host header to send with the health check.

[mark-church]

Hi @tmc thanks for your question. We have not implemented this yet as we focused on configurability of the path first. Can you detail a little more on the use case for the host header in a health check and what kind of systems require this? cc @bowei

[tmc]

A use case is as follows:
If you service a health check from within a cluster with a VirtualService say with a VS like so:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: healthcheck-virtualservice
spec:
 gateways:
   - foo-system/generic-gateway
 hosts:
   - healthcheck.foobar.com
 http:
   - match:
     - uri:
         exact: /
     rewrite:
       uri: /healthz/ready
     route:
     - destination:
         host: istio-ingressgateway.istio-system.svc.cluster.local
         port:
           number: 15020

If this healthcheck didn't have a specific hostname then the behavior of the cluster is surprising to developers/operators as the default request is then a content-free 200.

The hostname can be configured on the healthcheck but I'd prefer to hand this to a control plane as configuration rather than deal with additional configuration and state that might get removed or reset.

[mark-church]

Hi @tmc

Does configuring the path of the GCE health check also solve the problem? It would be configured in the BackendConfig which will be supported soon by #1040. Note that this PR does not support changing of the health check hostname, only path.

It could be done like this and referenced by the Service:

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    type: http
    requestPath: /healthz/ready

Then all hosts with /healthz/ready are matched and sent to the ingressgateway health check.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: healthcheck-virtualservice
spec:
 gateways:
   - foo-system/generic-gateway
 hosts:
   - *
 http:
   - match:
     - uri:
         exact: /healthz/ready
     route:
     - destination:
         host: istio-ingressgateway.istio-system.svc.cluster.local
         port:
           number: 15020

Let me know if this has the same effect for you as changing the health check hostname.

[anderspetersson]

Changing the path does not solve this issue for me.

My application checks for hostname and does custom logic (For example customer domain CNAME to my domain to show a customers page) based on requested hostname.

I have set the hostname in the console but would obviously prefer to have this in reproducible config files as well.

[mark-church]

Direct health check configuration is currently in development. It will roll out to GKE 1.17 and 1.16 likely within the next 1-2 months. Here are the fields that will be supported. Unfortunately hostname header did not make the cut because of some complications but we hope that these fields will at least make health checking somewhat easier and more predictable:

• checkIntervalSec: [int]
• timeoutSec: [int]
• healthyThreshold: [int]
• unhealthyThreshold: [int]
• type: [HTTP | HTTPS | HTTP2]
• port: [int]
• requestPath: [string]

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[rick-pri]

Direct health check configuration is currently in development. It will roll out to GKE 1.17 and 1.16 likely within the next 1-2 months. Here are the fields that will be supported. Unfortunately hostname header did not make the cut because of some complications but we hope that these fields will at least make health checking somewhat easier and more predictable:

That's unfortunate as Django has an ALLOWED_HOSTS setting which should be set specifically to the expected hosts for your app but this just returns a 400 for the healthcheck because the host is set to a subnet range IP address. Allow a custom request path doesn't help in that instance (although in some of our applications this is an additional complication.)

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dariemp]

I need a health check for my Django app that supports sending the HOST header so the app can match ALLOWED_HOSTS.

/reopen

[k8s-ci-robot]

@dariemp: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

I need a health check for my Django app that supports sending the HOST header so the app can match ALLOWED_HOSTS.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.