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

feat(translator): xds route and vhost metadata #3602

Merged
merged 18 commits into from
Jul 3, 2024

Conversation

guydc
Copy link
Contributor

@guydc guydc commented Jun 12, 2024

What this PR does / why we need it:

  • Design doc for metadata propagation
  • Implement propagation of HTTPRoute/GRPCRoute metadata to envoy route resources
  • Implement propagation of Gateway and Listener to Virtual Host metadata
  • e2e test based on access logs - verifying that metadata is printed to the log. If injection of METADATA-based header is supported (Support METADATA operator in header mutation envoy#34671), this test can be simplified to make an assertion on generated headers.

Which issue(s) this PR fixes:
Relates to #3318

@guydc guydc requested a review from a team as a code owner June 12, 2024 23:44
@guydc guydc marked this pull request as draft June 12, 2024 23:44
Copy link

codecov bot commented Jun 12, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.97%. Comparing base (ec9945a) to head (e54b00f).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3602      +/-   ##
==========================================
+ Coverage   68.81%   68.97%   +0.16%     
==========================================
  Files         175      176       +1     
  Lines       21524    21610      +86     
==========================================
+ Hits        14811    14906      +95     
+ Misses       5636     5628       -8     
+ Partials     1077     1076       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Signed-off-by: Guy Daich <[email protected]>
@guydc
Copy link
Contributor Author

guydc commented Jun 17, 2024

/retest

@guydc guydc marked this pull request as ready for review June 17, 2024 12:34
@@ -1082,6 +1082,13 @@ xds:
routes:
- match:
prefix: /
metadata:
filterMetadata:
io.envoyproxy.gateway.metadata:
Copy link
Member

@zhaohuabing zhaohuabing Jun 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would we need to add other metadata in the future? If so, we might need another level within the metadata structure to accommodate them.

This may look like:

io.envoyproxy.gateway.metadata:
  HTTPRoute:
    name: backend
    namespace: default
  Gateway:
    name: foo
    namespace: bar
  xxxx:
     .....     

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the field to be a list of resources for future proofing.

Copy link
Contributor Author

@guydc guydc Jun 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I'm having second thoughts about a list here. It's not so easy to address metadata in a list. So, I think that I'll go with your approach, but maybe slightly generalize to Gateway, Route and Backend top-level resources, which can then be GW/GWC, HTTP/GRPCRoute, Service/ServiceImport/Backend.

Copy link
Member

@zhaohuabing zhaohuabing Jun 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just thought the metadata structure should be able to accommodate multiple resources, but I don't know how exactly the structure should look like either. Let's brainstorm in the next meeting?

@@ -1082,6 +1082,13 @@ xds:
routes:
- match:
prefix: /
metadata:
filterMetadata:
io.envoyproxy.gateway.metadata:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

metadata.filterMetadata.io.envoyproxy.gateway.metadata seems a bit redundant, maybe just useio.envoyproxy.gateway as the key?

- [TCP/UDPRoute][tcpr] and [TLSRoute][tlsr] resource attributes are not propagated. These resources are translated to envoy filter chains, which do not currently support static metadata.
- [Service][svc], [ServiceImport][svci] and [Backend][] metadata and port name are propagated to envoy [cluster] metadata.

## Usage
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@guydc
Copy link
Contributor Author

guydc commented Jun 20, 2024

/retest

1 similar comment
@guydc
Copy link
Contributor Author

guydc commented Jun 21, 2024

/retest


// ResourceMetadata is metadata from the provider resource that is translated to an envoy resource
// +k8s:deepcopy-gen=true
type ResourceMetadata struct {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thoughts on leaving out SectionName and GroupVersion in the first iteration ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will remove GroupVersion. I'll add VHost to this PR in a bit, and it'll include a useful SectionName, so prefer to keep it.

retryDefaultRetryOn = "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes"
retryDefaultRetriableStatusCode = 503
retryDefaultNumRetries = 2
envoyGatewayMetadataNamespace = "io.envoyproxy.gateway"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be envoy-gateway instead ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Several parts of Envoy configuration (e.g. listeners, routes, clusters) contain a metadata where arbitrary key-value pairs can be encoded. The typical pattern is to use the filter names in reverse DNS format as the key and encode filter specific configuration metadata in the value.

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/data_sharing_between_filters#metadata

However, I agree that:

  • There is no filter in this case, so, we're not bound by these conventions. Istio uses a namespace called istio (and not io.istio) for similar purposes.
  • the long name is not convenient for access log formatters accessing the relevant keys.

envoyGatewayMetadataKeyNamespace = "namespace"
envoyGatewayMetadataKeyAnnotations = "annotations"
envoyGatewayMetadataKeySectionName = "sectionName"
envoyGatewayMetadataKeyRoute = "route"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to which resource are we building this key off ? input gateway api, IR or xds filter ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will change to envoyGatewayXds* to make it clear that this is a const used in generated XDS.

@arkodg
Copy link
Contributor

arkodg commented Jun 25, 2024

@zirain @guydc thoughts on adding this metadata by default to our default access log definition ?

@guydc guydc changed the title feat(translator): xds route metadata feat(translator): xds route and vhost metadata Jun 25, 2024
@guydc
Copy link
Contributor Author

guydc commented Jun 25, 2024

/retest

2 similar comments
@guydc
Copy link
Contributor Author

guydc commented Jun 25, 2024

/retest

@guydc
Copy link
Contributor Author

guydc commented Jun 26, 2024

/retest

@zirain
Copy link
Contributor

zirain commented Jun 26, 2024

@zirain @guydc thoughts on adding this metadata by default to our default access log definition ?

I don't think we should add them by default, users who want can add the command.

@guydc
Copy link
Contributor Author

guydc commented Jun 26, 2024

Also fine with allowing users to add this if needed.

@guydc guydc requested a review from arkodg June 26, 2024 19:12
@guydc
Copy link
Contributor Author

guydc commented Jun 27, 2024

/retest

1 similar comment
@zirain
Copy link
Contributor

zirain commented Jun 28, 2024

/retest

@zhaohuabing
Copy link
Member

zhaohuabing commented Jun 28, 2024

@zirain @guydc thoughts on adding this metadata by default to our default access log definition ?

IMO, adding them to the default access log format would be a pleasant surprise to EG users. I would recommend adding it unless we have strong reasons against it.

zhaohuabing
zhaohuabing previously approved these changes Jun 29, 2024
Copy link
Member

@zhaohuabing zhaohuabing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. This can be extremely helpful for EG users when debugging. I strongly suggest adding the metadata to the default log format - hiding this information by default is a huge waste.

@@ -31,6 +31,8 @@ const (
// Request timeout, which is defined as Duration, specifies the upstream timeout for the route
// If not specified, the default is 15s
HTTPRequestTimeout = "15s"
// egPrefix is a prefix of annotation keys that are processed by Envoy Gateway
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unused ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

used in filterEGPrefix to filter the annotations that should be picked up for metadata.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how do we document this opt in behavior ? user guide ?

envoyGatewayXdsMetadataKeyNamespace = "namespace"
envoyGatewayXdsMetadataKeyAnnotations = "annotations"
envoyGatewayXdsMetadataKeySectionName = "sectionName"
envoyGatewayXdsMetadataKeyRoute = "route"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are these keys needed ?
as a consumer I may want to access the envoy-gateway metadata, but I may not know if the xds resource maps to a gateway or route or both

guydc added 2 commits July 1, 2024 17:10
Signed-off-by: Guy Daich <[email protected]>
Signed-off-by: Guy Daich <[email protected]>
@guydc
Copy link
Contributor Author

guydc commented Jul 1, 2024

Sorry for force-push, I messed up the recent commit.

We will go with the list approach, since it's most future proof, considering situations where multiple resources of the same kind (e.g. policy and overriding policy) can contribute metadata.

Since there's currently no convenient way to reference a specific member of a list in envoy formatter at the moment, I prefer to leave metadata out of the default access log format, and not log all metadata by default.

out := map[string]string{}
for k, v := range in {
if strings.HasPrefix(k, egPrefix) {
out[strings.TrimPrefix(k, egPrefix)] = v
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we trim the prefix or let it be ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels a bit redundant to me, since only annotations with this prefix will be included.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool, lets leave as is

@guydc guydc requested review from zhaohuabing and arkodg July 2, 2024 12:39
Copy link
Contributor

@arkodg arkodg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks !
super excited to use this feature

@zirain zirain merged commit acce649 into envoyproxy:main Jul 3, 2024
27 checks passed
Copy link
Member

@zhaohuabing zhaohuabing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants