-
Notifications
You must be signed in to change notification settings - Fork 682
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
Added config for socket options for listeners #5352
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #5352 +/- ##
==========================================
+ Coverage 78.56% 78.59% +0.03%
==========================================
Files 138 138
Lines 19101 19150 +49
==========================================
+ Hits 15006 15051 +45
- Misses 3809 3812 +3
- Partials 286 287 +1
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
I've now resolved merge conflicts that had appeared during recent changes in |
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
Catching up with some more merge conflicts. These changes seem to be on a path that is bit prone to merge conflicts over the time, so reviews would be appreciated! 😄 🙏 |
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 correct from a quick pass over the code, seems straightforward enough to set some socket options on the Envoy Listeners
should maybe add a featuretest in lieu of an e2e test to make sure config gets plumbed all the way through correctly
this looks like it will intersect a bit with #5523 but I can sort that out if this merges first 👍🏽
} | ||
|
||
// SocketOptions defines configurable socket options for Envoy listeners. | ||
type SocketOptions struct { |
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.
(w/o knowing the details of TOS vs. Traffic Class) is it valid to auto detect the Listener ip family to be able to collapse these two into one field?
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.
Reliably auto-detecting could be challenging when listener address is set as ::
. We use Ipv4Compat: true
so Envoy accepts also IPv4 clients - unless IPv4 is disabled on the host where Envoy is running, I think.
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.
ah fair point, if we wanted to be clever could we maybe do something like "only have one new API field and if listen address == :: then set the ipv4 and ipv6 option with that value, otherwise set the appropriate option for the address family"?
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 in practice users may want to set different values between ipv4 and ipv6 seems more correct to keep these options/configurable values separate
Thank You for review @sunjayBhatia!
So far, I've checked the values manually from IP header using Wireshark. It would be great to have e2e test, but I think it would require a test client that processes HTTP responses at IP packet level. Normally the values are processed only by the routers & host IP stacks, but the receiving application is unaware of the values. Did you have some other approach in mind for e2e? |
yeah totally agree, I think just an additional explicit test in internal/featuretest (unless I missed it is already there) for the new socket options added in this PR to make sure the config is generated properly when all the different internal components are hooked up should be sufficient on top of that validation you've done |
Sorry @sunjayBhatia, somehow, I've accidentally managed to edit your reply instead of replying to you. Maybe I picked "edit" inadvertently, instead of "quote reply" 😵💫 Well, regardless of that confusion, I've now added test in |
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.
Looks like some conflicts to resolve and just to close out this thread #5352 (comment)
Otherwise 👍🏽
New config field was added to support DSCP marking for outbound traffic, for both IPv4 (TOS field) and IPv6 (Traffic Class field). Signed-off-by: Tero Saarni <[email protected]>
Signed-off-by: Tero Saarni <[email protected]>
This PR adds new optional config field to support DSCP marking for outbound IP packets, for both IPv4 (TOS field) and IPv6 (Traffic Class field).
Fixes #4605
Signed-off-by: Tero Saarni [email protected]
Detailed description
The new configuration is added to existing
listener
stanza:Example config file:
Example ContourConfiguration CR
The DSCP field is the 6 most significant bits of the exposed fields. However, the PR proposes exposing the socket options as they are exposed in Envoy and the socket API (complete TOS and TrafficClass bytes). For example, to set DSCP value
16
user needs to bit shift the value to 6 most significant bits of the byte and set thetos
and/ortrafficClass
to value64
.The PR proposes moving the existing TCP keepalive options into a generic socket option file. If more socket options are added in the future, the new file would be the place to add them - regardless of being TCP or IP level options.
Limitations
Since the two new socket options depend on IP version, the user needs to know in advance which one they want to set.
For example, if the worker nodes where Envoy runs have IPv6 support enabled in the kernel, and Envoy was configured to listen to IPv6 address, then
traffic-class
can be set. If not, settingtraffic-class
will cause failure to configure listeners to Envoy. Envoy will callsetsockopt()
to set IPv6 socket option on a socket that does not support IPv6, the syscall returns error and Envoy rejects the whole listener configuration. Contour cannot validate in advance if this syscall will succeed on the nodes where Envoy runs, so unfortunately it will be runtime failure.The documentation for the config has a note about this limitation.