Support multi tenant route configuration selection based on HTTP attributes #4704
Comments
|
This has +1 from me and other Googlers, so looking for community input. |
|
+1. I had one question about SRDS vs. building directly into RDS, and it seems to me the real problem is incremental delivery. There was discussion in the doc about field deprecation for this approach which I didn't fully understand and might be clarified a bit. |
|
@htuch @mattklein123 thanks for the reviews and feedback. I responded to comments in the doc and made some adjustments based on the feedback. I have been tied up with other work, but will be starting with implementation work on this shortly. |
|
LGTM, anyone else wants to weigh in before we move forward? CC @envoyproxy/maintainers |
|
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions. |
stale
bot
added
the
stale
|
Implementation work is ongoing. I am working on tests for the first PR which I am targeting for next week, although US holidays and a higher priority task are likely to delay this until the week after. |
stale
bot
removed
the
stale
This commit introduces a framework for implementing configuration providers by generalizing the
RouteConfigProvider{,Manager} which currently implement HttpConnectionManager routing configuration
and the RDS API.
This is the first deliverable (out of a planned 4 or 5 PRs) of the Scoped RDS implementation (envoyproxy#4704).
Signed-off-by: Andres Guedez <aguedez@google.com>
…er framework (#5243) This PR introduces a framework for creating static, inline and dynamic (xDS) config providers. The intent is to create a shared foundation that simplifies implementation of Envoy configuration, in particular xDS config handlers with shared ownership semantics such that the underlying subscription, config proto and config implementation (i.e., the resulting data structures and business logic) are shared across providers and Envoy worker threads. This PR generalizes the RouteConfigProvider, RouteConfigProviderManager and associated *Impls currently used for implementing HTTP route configuration and the RDS API. Note that static route configuration and RDS are not being transitioned to the generalized framework as part of this PR (see note below for details). NOTE: This is PR 1 (out of 4) to implement the scoped HTTP routing design introduced in #4704. The planned PR chain is as follows: 1. Introduce generalized config provider framework 2. Implement static and dynamic scoped routing configuration based on framework introduced in PR 1; the scoped routing business logic will _not_ be part of PR 2 3. Implement scoped routing business logic 4. Refactor RDS to use generalized config provider *Risk Level*: Low (this code is not yet in use; it will be enabled in a follow up PR) *Testing*: New tests added. *Docs Changes*: N/A *Release Notes*: N/A Signed-off-by: Andres Guedez <aguedez@google.com>
|
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions. |
stale
bot
added
the
stale
htuch
added
no stalebot
This commit introduces: - Support for scoped routing configuration parsing. - Inline and dynamic config providers using the ConfigProvider framework. - Unit and integration testing scaffolding. This is the second step in the PR chain for envoyproxy#4704. Signed-off-by: Andres Guedez <aguedez@google.com>
…er framework (envoyproxy#5243) This PR introduces a framework for creating static, inline and dynamic (xDS) config providers. The intent is to create a shared foundation that simplifies implementation of Envoy configuration, in particular xDS config handlers with shared ownership semantics such that the underlying subscription, config proto and config implementation (i.e., the resulting data structures and business logic) are shared across providers and Envoy worker threads. This PR generalizes the RouteConfigProvider, RouteConfigProviderManager and associated *Impls currently used for implementing HTTP route configuration and the RDS API. Note that static route configuration and RDS are not being transitioned to the generalized framework as part of this PR (see note below for details). NOTE: This is PR 1 (out of 4) to implement the scoped HTTP routing design introduced in envoyproxy#4704. The planned PR chain is as follows: 1. Introduce generalized config provider framework 2. Implement static and dynamic scoped routing configuration based on framework introduced in PR 1; the scoped routing business logic will _not_ be part of PR 2 3. Implement scoped routing business logic 4. Refactor RDS to use generalized config provider *Risk Level*: Low (this code is not yet in use; it will be enabled in a follow up PR) *Testing*: New tests added. *Docs Changes*: N/A *Release Notes*: N/A Signed-off-by: Andres Guedez <aguedez@google.com> Signed-off-by: Fred Douglas <fredlas@google.com>
…rk (#6781) Add support for "delta" APIs to the ConfigProvider framework in preparation for scoped RDS (see #4704). A delta API receives a subset of the configuration set through each resource distributed via the *DiscoveryResponse messages. While this PR is not directly related to the ongoing incremental xDS effort, it creates the foundation in the ConfigProvider framework to support Delta xDS updates for APIs implemented on top of the framework. Risk Level: Low (there is no DS API yet using this framework) Testing: Unit tests added, all existing tests passing. Signed-off-by: Andres Guedez <aguedez@google.com>
Implement the scoped RDS (SRDS) API config subscription and provider based on the config protos introduced in #6675 and the ConfigProvider framework introduced in #5243 and #6781. NOTES: See parent PR #5839 for full context into these changes. PRs 2a (#6675) and 2b (#6781) have already been merged. The API is not yet fully implemented. This PR introduces static and dynamic (xDS config subscription) handling of scoped routing configuration, but the new L7 multi tenant routing logic (see #4704) has not yet been introduced. The API is not yet plumbed into the HttpConnectionManager, that will be done in the next PR. This PR includes unit tests only; integration tests will follow in the next PR. Risk Level: Low (this DS API is not yet integrated into the HCM and can not be enabled via config). Testing: Unit tests added. Docs Changes: N/A. Signed-off-by: Andres Guedez <aguedez@google.com>
|
@AndresGuedez is this issue done or is there further work to do? |
|
@stevenzzzz is working on two more PRs for this. #7451 is out for review now. |
|
Although this scheme can well classify route configurations based on HTTP attributes, I am a bit skeptical about whether it really works for multi-tenant scenarios. For example, if I have five hundred tenants, different tenants have only one plugin with different configurations, and all other configurations are the same. So based on this solution, I need to create five hundred scopes, copy all the configurations to five hundred copies, and only one plugin configuration is different in all copies. @mattklein123 @AndresGuedez |
|
@wbpcode this is probably a distinct problem to what SRDS wants to solve. I think you're interested in deduplication of shared configuration across distinct |
|
I think this is done so closing this and we can track other improvements in new issues. |
Problem Statement
Envoy currently supports route configuration isolation in multi tenant environments by allowing a Listener FilterChain to specify a FilterChainMatch based on IP, TCP and TLS layer attributes.
When tenancy can be determined via these types of attributes, a FilterChain can be instantiated with a corresponding HttpConnectionManager RouteConfiguration proto (via static config or RDS) that corresponds to the tenant.
This issue tracks a design proposal to also support tenant differentiation via HTTP layer attributes, such that a single Listener -> HttpConnectionManager filter can be used to process requests for multiple tenants, each of which must be assigned its own RouteConfiguration.
Design Proposal
The design proposal extends Envoy with a Scoped Route Discovery Service API, which supports creating route configuration "scopes" indexed via a dynamically generated key extracted from HTTP layer attributes.
The proposed enhancement can be used to satisfy other use cases as well, such as #4690.
The text was updated successfully, but these errors were encountered: