Implementable RateLimitPolicy proposal #4346
Conversation
github-actions
bot
added
the
documentation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4346 +/- ##
==========================================
+ Coverage 86.10% 86.29% +0.18%
==========================================
Files 132 132
Lines 14342 14859 +517
Branches 35 35
==========================================
+ Hits 12349 12822 +473
- Misses 1790 1816 +26
- Partials 203 221 +18 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
|
Update: going to be scaling back this design to match more closely whats described in the story. Global rate limiting and Conditional rate limiting will be future work. |
| - `Accepted`: Indicates whether the policy has been accepted by the controller. This condition uses the reasons defined in the [PolicyCondition API](https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/policy_types.go). | ||
| - `Programmed`: Indicates whether the policy configuration has been propagated to the data plane. This helps users understand if their policy changes are active. | ||
|
|
||
| Note: The `Programmed` condition is part of the updated GEP-713 specification and should be implemented for this policy. Existing policies (ClientSettingsPolicy, UpstreamSettingsPolicy, ObservabilityPolicy) may not have implemented this condition yet and should be updated in future work. |
There was a problem hiding this comment.
If we don't yet have an issue to track this for our existing policies, lets make one now while we're thinking about it. I can see us forgetting about this in the future.
| - When a `RateLimitPolicy` is attached to a Gateway, generate a singular `limit_req_zone` directive, unique to that policy and Gateway, at the `http` block, and a `limit_req` directive at each of the `location` blocks generated by Routes attached to the Gateway. | ||
| - When a `RateLimitPolicy` is attached to an HTTPRoute or GRPCRoute, generate a singular `limit_req_zone`, unique to that policy and Route, directive at the `http` block, and a `limit_req` directive at each of the `location` blocks generated for the Route. | ||
| - When multiple `RateLimitPolicies` are attached to a Gateway, generate a unique `limit_req_zone` for each policy-gateway pair. | ||
| - When a `RateLimitPolicy` is attached to a Gateway, and there exists a Route which is attached to that Gateway which also has a `RateLimitPolicy` attached to it, the `location` blocks generated for that Route will have the `limit_req` directive with the Gateway `RateLimitPolicy` zone, and whatever `limit_req` directives generated by the `RateLimitPolicy` attached to the Route. |
There was a problem hiding this comment.
I don't quite understand this point
It reads it like this for me:
"If a Route has its won RL policy, with its own RL Rate, that is different to the RL rate defined in the RL policy attached to the gateway, the limit_req directives for the location block will use the zone generated by the Gateway's RL policy"
If that's true, that doesn't make sense. It feels like it defeats the purpose of having a custom RL policy at the Route level.
There was a problem hiding this comment.
Yea the wording is kind of confusing here, but there will be two limit_req_zones made and two limit_req directives used.
There was a problem hiding this comment.
Also sort of related, but a reason why we don't overwrite a Gateway level policy by attaching a policy at the Route level is related to the gateway api personas. The cluster operator (gateway level) should know their nginx loadbalancer capabilities better than an application developer, meaning the gateway level policy shouldn't be overwritten by one from the route level. And there shouldn't be a way for a route level policy to "cancel" a Gateway level one.
| - `Accepted`: Indicates whether the policy has been accepted by the controller. This condition uses the reasons defined in the [PolicyCondition API](https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/policy_types.go). | ||
| - `Programmed`: Indicates whether the policy configuration has been propagated to the data plane. This helps users understand if their policy changes are active. | ||
|
|
||
| Note: The `Programmed` condition is part of the updated GEP-713 specification and should be implemented for this policy. Existing policies (ClientSettingsPolicy, UpstreamSettingsPolicy, ObservabilityPolicy) may not have implemented this condition yet and should be updated in future work. |
Proposed changes
Problem: A design is needed for the RateLimitPolicy.
Solution: Create an implementable RateLimitPolicy enhancement proposal.
Closes #4059
Checklist
Before creating a PR, run through this checklist and mark each as complete.
Release notes
If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.