-
Notifications
You must be signed in to change notification settings - Fork 7.7k
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
envoy: use upstream http filter for metadata #51206
base: master
Are you sure you want to change the base?
Conversation
Change-Id: Idcc1f98fa1242d93fdb19c8c9838a7748856ebed Signed-off-by: Kuat Yessenov <[email protected]>
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.
Overall looks like a good direction, just not sure how/if it works as-is
cc @keithmattix
} | ||
metadata := base64.RawStdEncoding.EncodeToString(bytes) | ||
// Set metadata exchange environment variables | ||
_ = os.Setenv("ISTIO_PEER_METADATA_ID", node.ID) |
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.
should we set this on the envoy process call instead of in the ambient environment? This feels a bit sketchy
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.
Sure, I'm checking whether this is feasible - will clean up once it works.
@@ -321,6 +322,15 @@ func (a *Agent) initializeEnvoyAgent(_ context.Context) error { | |||
} | |||
a.envoyOpts.ConfigPath = out | |||
a.envoyOpts.ConfigCleanup = true | |||
|
|||
bytes, err := proto.Marshal(node.Metadata.ToStruct()) |
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.
I thought we used flatbuffers? does it encode to the same or am I just wrong about that?
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.
Flatbuffers is an internal representation, that we can remove without user facing changes.
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.
What about cross-version calls?
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.
We never send flatbuffer on the wire if that's the question.
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.
Why still use flat buffers then? Would be nice if we could standardize on proto if perf impact is minimal (not for this PR obviously)
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.
It was used because Wasm can't handle protos efficiently. Now that we don't recommend Wasm for telemetry, it could be a cleanup, although some users are probably still using internal flatbuffers and would be impacted - including our own SD extension.
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.
If we are going to be breaking the internal protocol between proxies this needs broad discussion around the cost vs benefits.
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.
@howardjohn There's no difference on the network between this and before. Flatbuffers were always internal to Istio and never sent on the wire. I don't think I understand the concern here.
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.
Oh so the wire format is the same?
We can do
meta := ...
roundtrip := flatbuffer_unmarshal(proto_marshal(meta))
meta == roundtrip
?
If so, no concern
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.
Yeah, flatbuffer is just a subset of struct metadata with 4-5 fields and converted internally in Envoy from proto to flatbuffers because Wasm. We can construct the subset here as well, and not even use flatbuffers to roundtrip.
@@ -443,9 +443,5 @@ func appendMxFilter(httpOpts *httpListenerOpts, filters []*hcm.HttpFilter) []*hc | |||
if httpOpts.class == istionetworking.ListenerClassSidecarInbound { | |||
return append(filters, xdsfilters.SidecarInboundMetadataFilter) | |||
} | |||
|
|||
if httpOpts.skipIstioMXHeaders { |
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.
we seem to lose this? skipIstioMXHeaders
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.
Yes, will add it later.
"istio_headers": map[string]any{}, | ||
}, | ||
map[string]any{ | ||
"workload_discovery": map[string]any{}, |
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.
How does workload_discovery
work now?
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.
It can be moved to network metadata exchange.
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.
I imagine that needs to be done in this PR, yes?
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.
No, this PR is about sending headers, not reading them.
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.
IIUC this removed code is what enabled workload discovery for waypoints. If so, how are we going to get that information now
"upstream_propagation": []any{ | ||
map[string]any{ | ||
"istio_headers": map[string]any{ | ||
"skip_external_clusters": true, |
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.
Did we lose this?
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.
This gets a lot easier actually because skipping is done per cluster.
SidecarOutboundMetadataFilterSkipHeaders = &hcm.HttpFilter{ | ||
Name: MxFilterName, | ||
|
||
InjectIstioHeaders = &hcm.HttpFilter{ |
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.
Any performance impact? I'd imagine not but would be good to check
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.
Don't think so, but we can check and probably need both ways temporarily.
Change-Id: If50ce31054b5cba895c95e7767cef3deec6a96c6 Signed-off-by: Kuat Yessenov <[email protected]>
Change-Id: I4875e1bcc373570ddf8ac5a45d292660b6bbb7cc Signed-off-by: Kuat Yessenov <[email protected]>
Change-Id: I5fd8be85a6650c233edb1ec28cd4e9e32a2d17e9 Signed-off-by: Kuat Yessenov <[email protected]>
Change-Id: I69f03d414658079bed72e1db7eee731352bccbe7 Signed-off-by: Kuat Yessenov <[email protected]>
Change-Id: Ie041c77f420927d9071755d4b413946fb98c9b2d Signed-off-by: Kuat Yessenov <[email protected]>
Is this changing HTTP MX to use upstream filters? I was wondering if using upstream filters could allow us to only send headers on the first request within a connection as an optimization to prevent sending MX headers on every request. |
@sschepens Yeah, but I think it would be better to use METADATA frames. |
Cool, using METADATA frames would be nice, but only be supported for h2, I guess that's fine though. Were you planning on taking this changes as well? |
@sschepens First thing first, let's start using upstream HTTP filters for metadata, because there seems to be some bugs based on the results of the PR here. |
Change-Id: Iab97c7e2ce047c4543501c322fa0c58cb3e2ab3a Signed-off-by: Kuat Yessenov <[email protected]>
Change-Id: Ib28f1400c41f46d98bf93a4c0261f20667ca7224 Signed-off-by: Kuat Yessenov <[email protected]>
@kyessenov: The following tests failed, say
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Not stale |
@kyessenov do you need some help picking this back up? |
@keithmattix Maybe, or we can skip this iteration and try to use "header operations" directly in the upstream HTTP filter. |
Change-Id: Idcc1f98fa1242d93fdb19c8c9838a7748856ebed
Please provide a description of this PR: