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
node: Don't skip masquerading for External node IPs #18483
node: Don't skip masquerading for External node IPs #18483
Conversation
I think we should document this subtle difference in the masquerading.rst. |
Commit 49cb220 ("iptables: Don't masquerade traffic to cluster nodes") introduced ipsets in our iptables rules, to skip masquerading traffic to cluster nodes when iptables-based masquerading is used. BPF-based masquerading already implemented this logic. In practice, traffic to both Internal and External node IPs would skip masquerading. However, Kubernetes doesn't state that External Node IPs are routable within the cluster. Masquerading may thus be required for External Node IPs, as reported by several users. Hence, this commit changes the logic to only skip masquerading in iptables for Internal node IPs. This commit doesn't affect the BPF-based masquerading logic, as unfortunately we can't easily distinguish between Internal and External node IPs in our datapath today (both are identified as host or remote-node). Fixes: 49cb220 ("iptables: Don't masquerade traffic to cluster nodes") Signed-off-by: Paul Chaignon <paul@cilium.io>
This commit documents the difference in handling traffic to External IPs of cluster nodes between the BPF-based and iptables-based implementations of masquerading in Cilium. Suggested-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Paul Chaignon <paul@cilium.io>
@brb 👍 Done in the second commit. Please have a look. |
28a40dc
to
d3304c0
Compare
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!
Several tests failed with known flakes:
Reviews are in, except for the agent team, but I'm not sure why that team was requested in the first place. Marking ready to merge. |
See commits for details. The first has the fix, the second documents the different between our two implementations.
Fixes: #16603.
Related: #17177.