Dynamically Return 204 in Nginx Ingress When Backend Returns 500, and Resume Normal Behavior When Backend Recover #12004
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
lifecycle/frozen
Indicates that an issue or PR should not be auto-closed due to staleness.
needs-priority
needs-triage
Indicates an issue or PR lacks a `triage/foo` label and requires one.
Problem
We are facing an issue where our backend service, behind an Nginx Ingress Controller, occasionally starts returning HTTP 500 errors. When this happens, we notice that our Nginx Ingress Controller (configured with hostNetwork: true) consumes an excessive amount of CPU and memory, often reaching 100%.
To mitigate the load during these failure scenarios, we want Nginx Ingress Controller to automatically return an HTTP 204 status code whenever the backend starts returning 500 errors. The goal is to avoid sending traffic to the backend when it's in a failing state. Once the backend recovers and starts returning HTTP 200, we want Nginx to stop returning 204 and resume forwarding traffic to the backend normally.
Proposed Solution
We are looking for a way to implement dynamic behavior in the Nginx Ingress Controller:
When the backend starts returning 500: Nginx should immediately start responding with 204 for all incoming requests to a specific path (e.g., /bid) without forwarding these requests to the backend.
When the backend recovers and returns 200: Nginx should remove the 204 rule and resume forwarding traffic to the backend normally.
We attempted to find a solution within the current Nginx Ingress annotations but couldn’t find a dynamic mechanism to implement this. A possible solution could be to use Lua scripting in Nginx to track backend responses and adjust the behavior accordingly, but this is not something that can be done with existing Ingress annotations. Is there some solutions?
The text was updated successfully, but these errors were encountered: