feat(outbound): Use the policy API for opaq routing #3306
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Zahari Dichev <[email protected]>
olix0r
reviewed
Oct 30, 2024
Signed-off-by: Zahari Dichev <[email protected]>
Signed-off-by: Zahari Dichev <[email protected]>
Signed-off-by: Zahari Dichev <[email protected]>
olix0r
reviewed
Nov 4, 2024
olix0r
reviewed
Nov 4, 2024
olix0r
reviewed
Nov 5, 2024
olix0r
reviewed
Nov 5, 2024
Because the opaq route mocks its selection logic, the first route returned by the API will always be used. This means that all subsequent routes are incoherent and cannot be selected. There's no value in preserving incoherent states in the proxy, so it's preferable to initially require that the control plane only returns one opaq route. This change removes some of the unused matching types and simplifies the opaq router to only handle one route.
Signed-off-by: Zahari Dichev <[email protected]>
Signed-off-by: Zahari Dichev <[email protected]>
olix0r
reviewed
Nov 7, 2024
Signed-off-by: Zahari Dichev <[email protected]>
Signed-off-by: Zahari Dichev <[email protected]>
…tor/gw suggestions on correct address types
olix0r
approved these changes
Nov 7, 2024
When synthesizing outbound routes from a service profile, we need to set the route metadata. We currently use the parent reference. This change updates these route reference to use a 'serviceprofile' default route to indicate that it is synthesized. In a followup change, we should correct this to prefer serviceprofile metadata returned via the API.
The OutboundPolicy API is able to express configuration for opaq routing, but the proxy only currently uses the ServiceProfile to configure routing. To support configuring routing via the Gateway API's TCPRoute, we need to begin using the OutboundPolicy API to configure opaq routing without breaking existing configurations that use profiles. With this change, the outbound proxy is updated so that route configurations are required for the proxy to handle outbound opaq traffic. Route configurations may be provided by: * The Profile API, when it returns an Endpoint, so that the proxy synthesizes a route configuration that forwards traffic to the endpoint. * The Profile API, when it returns a traffic split configuration, so that the proxy synthesizes a route configuration that forwards traffic over backend services. * The OutboundPolicy API when it returns opaq routes. When no routes are returned by the API, the proxy fails to route the connections. Follow up changes will enhance this functionality with metrics and improved metadata.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This work (based on the early sketch seen here) changes the
opaqrouting stack to use not only profiles routing but to consider client policy responses as well. The way this is done is that we use theopaq:Routestype to express the routing information our stack contains. This type is geared towards the client-policy API. Whenever we need to use the profiles response, we simply translate its contents to a client-policy one.Notable changes in this PR are:
OpaqSidecartype that holdsopaq::Routesobjects which are routes that have been constructed from eitherprofilesorpolicyresponseOpaqSidecarwe consider profiles responses only if there are extra targets in the response (in order to supportTrafficSplitfunctionality). In any other case we prefer the policy response.Signed-off-by: Zahari Dichev [email protected]