Skip to content
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

[POC] Introduce XdsPreprocessor #6096

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jrhee17
Copy link
Contributor

@jrhee17 jrhee17 commented Feb 14, 2025

Motivation:

Explain why you're making this change and what problem you're trying to solve.

Modifications:

  • List the modifications you've made in detail.

Result:

  • Closes #. (If this resolves the issue.)
  • Describe the consequences that a user will face after this PR is merged.

@github-actions github-actions bot added the Stale label Mar 17, 2025
jrhee17 added a commit that referenced this pull request Mar 27, 2025
Motivation:

We are planning on deprecating `XdsEndpointGroup` and introducing
`XdsPreprocessor` at #6096.

Previously, `XdsEndpointGroup` created sub-`EndpointGroup`s which
consume resources. (e.g. `HealthCheckedEndpointGroup`,
`DnsEndpointGroup`, etc..) assuming that all xDS clients will share a
common `EndpointGroup`.

However, `XdsPreprocessor` cannot be shared among all client types.
For instance, thrift clients will need to use `RpcPreprocessor` whereas
web clients will need to use normal `Preprocessor`s.

I propose that `XdsBootstrap` contains a single `ClusterManager` which
caches all `EndpointGroup`s derived from `Cluster`s. This
`ClusterManager` is aligned with the xDS API
[cluster_manager](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/bootstrap/v3/bootstrap.proto#envoy-v3-api-msg-config-bootstrap-v3-clustermanager)
and is aligned with the [upstream
implementation](https://github.com/envoyproxy/envoy/blob/e3a97f1a81a65b168c5cf822d4a0861958f94162/source/common/upstream/cluster_manager_impl.h#L243)
as well.

One prerequisite for the introduction of `ClusterManager` is the ability
to cache `Cluster`s. This is difficult since the current implementation
of `ClusterSnapshot` also contains a reference to the containing
`Route`.


https://github.com/line/armeria/blob/533f798efdf827326c3a8d70ce21d13f20245c20/xds/src/main/java/com/linecorp/armeria/xds/ClusterSnapshot.java#L82

I propose that `VirtualHostSnapshot` and `RouteEntry` is introduced, and
snapshot mappings are unidirectional. This direction aligns with a
possible future implementation of
[VHDS](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/vhds)
as well.

As this is a refactor of the previous implementation, there is no
expected change in behavior except for subset load balancing (which
actually matches upstream now)

Modifications:

- Introduced `VirtualHostSnapshot` which is equivalent to `VirtualHost`,
and `RouteEntry` which is equivalent to `Route`.
- Refactored `ClusterManager` and `SubsetLoadBalancer` to not use
`ClusterSnapshot#route`
- `SubsetLoadBalancer` now is aligned with the upstream implementation
([ref](https://github.com/envoyproxy/envoy/blob/e3a97f1a81a65b168c5cf822d4a0861958f94162/source/extensions/load_balancing_policies/subset/subset_lb.cc#L478))
- The previous test case for skipping failure on empty metadata is
removed as it does not match the upstream implementation.
- (Misc) Cleaned up the `ConfigSourceMapper` implementation by removing
unused fields and the corresponding logic.

Result:

- The `ClusterSnapshot` API is prepared for the introduction of a
central `ClusterManager` maintained by `XdsBootstrapImpl`

<!--
Visit this URL to learn more about how to write a pull request
description:

https://armeria.dev/community/developer-guide#how-to-write-pull-request-description
-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant