The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

unstaling, this one seems worthwhile to keep around to consider properly

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

xref #5771

The HealthCheck filter (proto) can send response that mimics the behavior of /ready endpoint in admin interface, when used with "no passthrough" option

No pass through: In this mode, the health check request is never passed to the local service. Envoy will respond with a 200 or a 503 depending on the current draining state of the server.

It is not exactly the same though, since the success response from admin interface is

HTTP/1.1 200 OK
cache-control: no-cache, max-age=0
content-type: text/plain; charset=UTF-8
date: Mon, 07 Apr 2025 10:20:03 GMT
server: envoy
transfer-encoding: chunked
x-content-type-options: nosniff
x-envoy-upstream-service-time: 0

LIVE

while from HealthCheck filter it is

HTTP/1.1 200 OK
content-length: 0
date: Mon, 07 Apr 2025 10:24:15 GMT
server: envoy
x-envoy-upstream-healthchecked-cluster: projectcontour

During draining the admin interface responds:

HTTP/1.1 503 Service Unavailable
cache-control: no-cache, max-age=0
connection: close
content-type: text/plain; charset=UTF-8
date: Mon, 07 Apr 2025 10:36:57 GMT
server: envoy
transfer-encoding: chunked
x-content-type-options: nosniff
x-envoy-upstream-service-time: 0

DRAINING

and HealthCheck responds

HTTP/1.1 503 Service Unavailable
connection: close
content-length: 0
date: Mon, 07 Apr 2025 10:30:58 GMT
server: envoy
x-envoy-immediate-health-check-fail: true
x-envoy-upstream-healthchecked-cluster: projectcontour

The behavior and status codes are the same but response body and headers are not.