envoyproxy/envoy

Overload manager doesn't exclude probes from stop_accepting_* actions

Open

#23,843 opened on Nov 4, 2022

View on GitHub
 (12 comments) (0 reactions) (1 assignee)C++ (5,373 forks)batch import
area/health_checkingarea/overload_managerenhancementhelp wanted

Repository metrics

Stars
 (27,997 stars)
PR merge metrics
 (Avg merge 8d) (378 merged PRs in 30d)

Description

Title: Overload manager should exclude probes from stop_accept_ actions*

Description: We are recently testing overload manager with istio. Our scenario is to overload the ingressgateway heap_size configured via sending requests from large number of concurrent connections, then we see stop_accepting_connections/requests actions triggered and new requests will fail. But we found stop_accepting_connections(also stop_accepting_requests) stops the internal probes like liveness probe and readiness probe, which leads to the restart of the ingressgateway pod, which will causes issue for us.

We think it's reasonable to exclude the probes like liveness/readiness probe from overload manager stop_accepting_* actions, because new traffic will still fail and return users error 503 to indicate the overload, there seems to be no need to also stop internal probes.

Or we would like to know if it's intentionally to include probes into stop_accepting_* actions, if so, why?

related topic https://github.com/envoyproxy/envoy/issues/21923

Contributor guide

Research direction
Investigate the overload manager code in Envoy to understand how stop accepting connections and stop accepting requests are triggered. Identify health probe requests (e.g., by examining request path or headers like 'User Agent' or 'X Forwarded For'). Determine a method to exclude these probes from the stop actions, such as adding a configuration option or a filter to bypass the stop logic for health checks.
Tech stack
cpp
Domain
backendinfrastructure
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
C++Envoy architecture
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30