feat: add admission control functionality - #7529
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #7529 +/- ##
==========================================
+ Coverage 74.39% 74.47% +0.07%
==========================================
Files 246 247 +1
Lines 39221 39314 +93
==========================================
+ Hits 29180 29280 +100
+ Misses 8017 8009 -8
- Partials 2024 2025 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
hey @aburan28 you've also raised #7016 for adding adaptive concurrency control support, these are similar options to throttle clients based on server characteristics ( latency, load), would help if you can outline your use case first, so we can prioritize one or the other, and document the reasons for adding support for it |
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions! |
✅ Deploy Preview for cerulean-figolla-1f9435 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
674710b to
9e8be42
Compare
IMO, Admission Control and Adaptive Concurrency are complementary, not competing strategies. They address different failure signals and protect backends in different ways. I believe it is useful to include both within Envoy Gateway. Admission control does have a simpler operational overhead compared to adaptive concurrency. It deals with error rates which users can reason about easily. So for now my focus is on admission control although I do have a PR for adaptive concurrency open as well. Use cases I have are really to emulate a dynamic circuit breaker that is based off of success/error rate and to protect backends from overload. |
sure +1 for Admission Control to solve the dynamic circuit breaker issue going forward lets start with a GH issue, an API PR and then an implementation PR for this feature, lets use this PR |
b26aea7 to
aeb7925
Compare
|
hey @aburan28 can you resolve the mere conflicts |
|
|
- Remove Enabled field (presence of admissionControl implies enabled) - Switch SuccessRateThreshold, Aggression, MaxRejectionProbability from float64 to uint32 to avoid floats in the API layer - Register envoy.filters.http.admission_control in the EnvoyFilter enum - Fix example manifest (srThreshold -> successRateThreshold, integer values) - Regenerate CRDs, deepcopy, docs, and xds translator testdata Signed-off-by: Adam Buran <aburan28@gmail.com>
Remove stale lbPolicy field from cluster output after main merge. Signed-off-by: Adam Buran <aburan28@gmail.com>
Regenerates test/helm/gateway-crds-helm/*.out.yaml and site/content/en/latest/api/extension_types.md to match the current admission control API (int32 percentages, enabled field removed) and pick up envoy.filters.http.admission_control in the filter order enum. Signed-off-by: Adam Buran <aburan28@gmail.com>
…-control Signed-off-by: Adam Buran <aburan28@gmail.com>
3bd62c4 to
2a8a41a
Compare
…igo lint Signed-off-by: Adam Buran <aburan28@gmail.com>
|
Please add a testdata example under internal/gatewayapi/ |
…map, add gatewayapi testdata - Revert the HCM HTTP filter ordering shifts in newOrderedHTTPFilter; the admission_control filter is registered as an upstream cluster filter, so it does not need a slot in the downstream HCM ordering. - Move the gRPC status-code lookup map to a package-level var so it is not rebuilt on every translation cycle. - Add backendtrafficpolicy-admission-control gatewayapi testdata covering both gateway-targeted (gRPC success criteria, all knobs set) and route-targeted (HTTP success criteria, minimal config) policies. Signed-off-by: Adam Buran <adam.buran@gmail.com> Signed-off-by: Adam Buran <aburan28@gmail.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a98b9e2213
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: Adam Buran <aburan28@gmail.com>
|
@codex review |
|
Codex Review: Didn't find any major issues. Chef's kiss. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
Thanks for working on this @aburan28. A few nits to fix but besides that LGTM. |
Signed-off-by: Adam Buran <aburan28@gmail.com>
|
LGTM thanks! |
|
@aburan28 can you fix the conflicts from main and add a release note? |
What type of PR is this?
feature
What this PR does / why we need it
This PR adds support for Envoy's Admission Control filter to Envoy Gateway by exposing it through
BackendTrafficPolicy.Admission control probabilistically rejects requests based on the historical success rate of upstream requests within a configurable sliding time window. This provides client-side load shedding for overloaded or degraded backends and complements circuit breaking and retry policies.
Changes include
AdmissionControlwith configurablesamplingWindow,successRateThreshold,aggression,rpsThreshold,maxRejectionProbability, and success criteria for HTTP and gRPC.admissionControlfield.envoy.filters.http.admission_controlas an upstream HTTP filter on generated clusters.envoy.filters.http.admission_controlas a known Envoy filter.Which issue(s) this PR fixes
None linked.
Release Notes
Added admission control support to BackendTrafficPolicy, enabling client-side load shedding based on historical upstream success rates using Envoy's admission control filter.