-
Notifications
You must be signed in to change notification settings - Fork 363
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
Cleanup: remove send_redirects sysctl configuration #1364
Conversation
Thanks for your PR. The following commands are available:
|
/test-all |
Codecov Report
@@ Coverage Diff @@
## master #1364 +/- ##
==========================================
+ Coverage 64.36% 64.46% +0.10%
==========================================
Files 159 159
Lines 12674 12654 -20
==========================================
Hits 8157 8157
+ Misses 3665 3648 -17
+ Partials 852 849 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
|
/test-windows-conformance |
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.
Question - but when AntreaProxy is not enabled, do we still need send_redirect for Service traffic?
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.
Thanks for taking care of this, LGTM
@tnqn nit: in the commit message / PR description: you wrote "capacities" instead of "capabilities" |
@jianjuns No, I have verified no redirect packets are generated for such traffic. It should make sense that a DNATed packet may be sent out from the interface which it comes in so linux must have handled it. I could also try to confirm from code.
Thanks @antoninbas, corrected. |
/test-all |
/test-whole-conformance |
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.
Ok. Let us remove it then.
/test-conformance |
@@ -350,16 +335,6 @@ func writeLine(buf *bytes.Buffer, words ...string) { | |||
} | |||
} | |||
|
|||
func disableICMPSendRedirects(intfName string) error { | |||
cmdStr := fmt.Sprintf("echo 0 > /proc/sys/net/ipv4/conf/%s/send_redirects", intfName) |
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.
@tnqn As part of the flow exporter, we make sure a couple of netfilter/conntrack parameters to be set.
https://github.com/vmware-tanzu/antrea/blob/5f65bba1b771b6fd1f1b548a3458bd3647c74489/pkg/agent/flowexporter/connections/conntrack_linux.go#L151
I think the change of privileges for the antrea-agent container will affect those checks, right?
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.
thanks @srikartati for raising this, I didn't know we have other places to perform sysctl. Is the conntrack configuration must-have to make flow exporter work? If so, I'm thinking two approaches:
- Keep privilege in the upstream yaml and use customized manifest for clusters that do not allow privileged pod (but flow exporter and other features that require sysctl configuration won't be available in these clusters).
- Try performing sysctl in antrea-agent and if it fails, logging a warning but do not exit the program if an env variable like IGNORE_SYSCTL_ERR is set. This means user doesn't give antrea-agent pod privilege, assuming sysctl will be configured out-of-band.
@antoninbas @jianjuns @srikartati any idea?
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.
Thanks for catching this @srikartati
- these parameters are not must-have, but they do provide additional information. The code already does not fail and exit if the kernel parameters cannot be set, so maybe
IGNORE_SYSCTL_ERR
is not required if we go with Quan's idea. Although the problem with always ignoring it is we do not catch issues when testing, as was the case here. - a possibility is to use an initContainer that's privileged in order to set these kernel parameters; and run the Agent as unprivileged. The initContainer can easily be removed from the manifest when needed.
- could we consider setting the sysctls in the Pod spec as that doesn't require privileged mode (https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/#setting-sysctls-for-a-pod)? That relies on container runtime support to set the kernel parameters.
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.
@tnqn Setting up the conntrack parameters is not a must per say for Flow Exporter, but the flow visibility would not be complete especially because of the lack of flow stats. Currently, if there is no write access to sysctl parameters and the values are not desired, then we just log an error and continue. In this case, we just provide flow records without stats and timestamps.
Since having no privileges doesn't break functionality, IMO we can go for option 2 to configure them out-of-band and describe the importance of setting required sysctl parameters in the flow exporter documentation.
I would like to hear others opinion.
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.
The 3rd option doesn't work as setting unsafe-sysctls need extra argument --allowed-unsafe-sysctls
set to kubelet and it's not allowed to set net namespace related kernel parameter for a host network Pod: https://github.com/kubernetes/kubernetes/blob/2046f4212a355a3381da20c4d800283b98e9a081/pkg/kubelet/sysctl/whitelist.go#L89-L91.
I think the initContainer approach is feasible, we may need to measure how long would it add to the start time if having another initContainer. Anyway I could reduce the scope of this PR to remove send_redirects configuration only first.
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 I like about the initContainer approach is we can group all operations that require privileged mode and we ensure that the antrea-agent container itself can run without privileged mode since the default YAML itself will not include privileged: true
. But yes, that's a separate question that can be resolved in a future PR. After merging this PR, one can already edit the manifest and remove privileged: true
, which will cause a warning to be logged if FlowExporter is enabled, but will not terminate the agent.
@jianjuns @antoninbas I have confirmed from code that redirect packets for a NATed connection is not allowed for Linux, it's dropped by a NAT hook: |
With L3 flows, Pod-to-Pod traffic will no longer go through gateway interfaces. For Pod-to-Service traffic, Linux doesn't allow sending redirect packets for NAT'd connections. Therefore, configuring send_redirects is no longer needed.
/test-all |
With L3 flows, Pod-to-Pod traffic will no longer go through gateway interfaces. For Pod-to-Service traffic, Linux doesn't allow sending redirect packets for NAT'd connections. Therefore, setting send_redirects is no longer needed.
For #1363