Change:
}, health: probe.Failure, }, <ins> { handler: redirectHandler(http.StatusMovedPermanently, false), // 301 health:  probe.Success, }, { handler: redirectHandler(http.StatusMovedPermanently, true), // 301 health:  probe.Failure, }, { handler: redirectHandler(http.StatusFound, false), // 302 health:  probe.Success, }, { handler: redirectHandler(http.StatusFound, true), // 302 health:  probe.Failure, }, { handler: redirectHandler(http.StatusTemporaryRedirect, false), // 307 health:  probe.Success, }, { handler: redirectHandler(http.StatusTemporaryRedirect, true), // 307 health:  probe.Failure, }, { handler: redirectHandler(http.StatusPermanentRedirect, false), // 308 health:  probe.Success, }, { handler: redirectHandler(http.StatusPermanentRedirect, true), // 308 health:  probe.Failure, }, </ins> } for i, test := range testCases { func() {

Discussion:
It seems the http liveness probe will not follow a 302 redirect and instead reports a failure. I found this in some testing on 1.0.6 and have not yet verified the same behavior on latest. Do you agree that it should check the redirected path on a 302? If so, where would be the best place to check the response code and handle this?
Why would you set your health-check URL to a redirect? , Dan Wilson wrote:
In this case it was a versioned health check where /v1/health or /v2/health is the correct check and /health directs to the correct one.
hmm, I could buy following redirects, I guess. It's a little weird if it redirects off-host, but who am I to say it is wrong? , Dan Wilson wrote:
Following redirects for a health check seems weird to me as well... I definitely wouldn't expect it to by default.
Seems like it would be cleaner to make respond the same as instead of making all health consumers follow redirects.
I agree that it's cleaner to call /health and make that route the same as /<latest/health but due to the framework used for this project it's not handled that way. Following the HTTP standards is important as well, right? curl handles this with an additional option (-L), could we do the same by adding a parameter?
I think it should follow local redirects without complaining (can well differentiate local vs non?). The real question is non-local redirects - should it a) work, b) not work, c) work iff a flag-field in the probe , Dan Wilson wrote:
old thread here... I agree with non-local redirects not being allowed, just doesn't seem to make sense. If we get a 301 perhaps we could get the value of the redirect ( it looks like there is a Location header with the new full path ) and then do something like the following: the root URL of the redirect location. it's a DNS name attempt to resolve it to an IP. If that fails, just bail. the IP to make sure it's in the cluster. If it's not in our CIDR block bail. the redirect. thoughts?

/sig node /sig network
Adding to 1.8 milestone
Is it not possible and easier to simply empower the user by adding an option for "unexceptional" status codes? They could declare 200-only (default) or all-but-errors.
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.9 milestone for more than 3 days: priority: Must specify exactly one of , or . <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
This contradicts docs , opened