feat(infra): Add rateLimitHpa support in EnvoyGateway API#4983
feat(infra): Add rateLimitHpa support in EnvoyGateway API#4983arkodg merged 4 commits intoenvoyproxy:mainfrom
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4983 +/- ##
==========================================
+ Coverage 66.75% 66.77% +0.02%
==========================================
Files 209 209
Lines 32058 32101 +43
==========================================
+ Hits 21399 21435 +36
- Misses 9381 9385 +4
- Partials 1278 1281 +3 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
imo we shouldnt do this, its bad practice to set replicas and hpa, but we shouldnt override a user setting, and instead recommend a user to leave replicas unset when using hpa
There was a problem hiding this comment.
oh nvm youre following
There was a problem hiding this comment.
yeah, honestly I kind of agree, but I just went for consistency between this and the EnvoyProxy API. If we choose not to override a user setting here, we should probably have similar behavior in the EnvoyProxy HPA case as well.
There was a problem hiding this comment.
yeah, lets wait for ardikabs' response, else keep it as is for now
There was a problem hiding this comment.
It primarily prevents unwanted values from being set during HPA configuration, with the Envoy Gateway proactively ensuring such scenarios are avoided. This condition is already documented in the EG API Reference, highlighting when Replicas and HPA are being set.
gateway/api/v1alpha1/envoyproxy_types.go
Lines 312 to 316 in 10a31f1
Historically, this behavior was implemented because EG previously set default replicas. As a result, even if users left the field empty (as recommended when using HPA), a default value of 1 was still applied.
But after this PR #2816, I think we can remove it, wdyt @arkodg?
There was a problem hiding this comment.
ah thanks for adding clarity here @ardikabs, this extra step can be cleaned up in a follow up commit
internal/infrastructure/kubernetes/ratelimit/resource_provider.go
Outdated
Show resolved
Hide resolved
|
thanks @keithfz, this PR looks great ! added some minor non blocking comments |
api/v1alpha1/envoygateway_types.go
Outdated
There was a problem hiding this comment.
this' fine now, if we bring more fields in the future, pefer to something like:
ratelimit:
deployment:
...
hpa:
...There was a problem hiding this comment.
would we want to consider the same for other APIs in the future as well? e.g. EnvoyProxy:
gateway/api/v1alpha1/envoyproxy_types.go
Lines 291 to 328 in 7952936
There was a problem hiding this comment.
Both are making a good point, the extra hierarchy hides the component specific details, but the current style is envoyHpa which is probably why the same style was adopted for rateLimitDeployment
Signed-off-by: keithfz <[email protected]>
Signed-off-by: keithfz <[email protected]>
Signed-off-by: keithfz <[email protected]>
Signed-off-by: keithfz <[email protected]>
This is no longer needed after envoyproxy#2816 was merged Relates to envoyproxy#4983 (comment) Signed-off-by: Arko Dasgupta <[email protected]>
dont reset deployment replicas when hpa is set This is no longer needed after #2816 was merged Relates to #4983 (comment) Signed-off-by: Arko Dasgupta <[email protected]>
What type of PR is this?
Adds HPA support for rate limit deployment under the EnvoyGateway API
What this PR does / why we need it:
Allows autoscaling of the rate limit deployment similar to what is done today for the envoy proxy deployment.
Which issue(s) this PR fixes:
Fixes #4930
Release Notes: Yes