-
Notifications
You must be signed in to change notification settings - Fork 576
Add Ratelimit API #1767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Ratelimit API #1767
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,6 +14,7 @@ | |
|
||
syntax = "proto3"; | ||
|
||
import "google/api/field_behavior.proto"; | ||
import "google/protobuf/duration.proto"; | ||
import "google/protobuf/wrappers.proto"; | ||
import "mesh/v1alpha1/proxy.proto"; | ||
|
@@ -536,8 +537,11 @@ message MeshConfig { | |
// Note, currently at most 1 extension provider is allowed. | ||
repeated ExtensionProvider extension_providers = 57; | ||
|
||
// Configuration for an external rate limit service. | ||
RateLimitService service = 58; | ||
|
||
// $hide_from_docs | ||
// Next available field number: 58 | ||
// Next available field number: 59 | ||
reserved 1; | ||
reserved "mixer_check_server"; | ||
reserved 2; | ||
|
@@ -631,3 +635,27 @@ message Certificate { | |
// multiple DNS names. | ||
repeated string dns_names = 2; | ||
} | ||
|
||
// RateLimitService describes the configuration for an external rate limit service provider. | ||
message RateLimitService { | ||
// REQUIRED. Specifies the service that implements rate limit service. | ||
// The format is "[<Namespace>/]<Hostname>". The <Hostname> is the full qualified host name in the Istio service | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I know we use this pattern in some configs, like Gateway, for a specific purpose ( delegation ). Do we need this here ? If there is a strong use cases - I will request any implementation before we unhide this API will have test cases for each option. Maybe start with the simple solution first, of using a ServiceEntry/DestinationRule/etc in istio-system and not provide too much complexity of allowing arbitrary namespace. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should not enforce it has to be in |
||
// registry defined by the Kubernetes service or ServiceEntry. The <Namespace> is the namespace of the Kubernetes | ||
// service or ServiceEntry object, and can be omitted if the <Hostname> alone can decide the service unambiguously | ||
// (normally this means there is only 1 such host name in the service registry). | ||
// | ||
// Example: "rls.foo.svc.cluster.local" or "bar/rls.example.com". | ||
string host = 1 [(google.api.field_behavior) = REQUIRED]; | ||
|
||
// REQUIRED. Specifies the port of the service. | ||
uint32 port = 2 [(google.api.field_behavior) = REQUIRED]; | ||
|
||
// The filter’s behaviour in case the rate limiting service does not respond back. | ||
// When it is set to true, Envoy will allow traffic in case of communication failure | ||
// between rate limiting service and the proxy. | ||
bool fail_open = 3; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Default bool value is false - i.e. fail close. I don't think that's correct for a rate service - I would rather have the setting be 'fail_closed', so the user needs to explicitly add it if he wants this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, this is the behavior of the legacy mixer. |
||
|
||
// The timeout for the rate limit service RPC. | ||
// If not set, this defaults to 20ms. | ||
google.protobuf.Duration timeout = 4; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For all services we use in Istio, we need to document how auth is going to be performed. Are all rate services using standard Istio mTLS or do we need to support other mechanisms ? Also, is this service subject to normal Istio APIs - DestinationRule for example ? If yes ( and I assume it should ), do we want to duplicate timeout here ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The timeout here is from the application view(envoy->rls). DR can be used, but it will require an additional config |
||
} |
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As usual: do we expect the rate limit service to be the same in all namespaces and pods ? No possible use case where different namespaces would use different rate services ?
Why not add it to ProxyConfig instead, and use the existing pattern of RemoteService ?
If you want to keep it in MeshConfig - maybe the ExtensionProvider (which was just added) would be needed, but I don't think we have an approved design on using ExtensionProvider.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, i think this should be global. It is easy to operate. I understand ProxyConfig is used to generate configs for proxy in proxy side. But rls is used in istiod. As
ExtensionProvider
, it is only for external authz.