-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
KEP: kube-proxy detect "local" traffic w/o cluster CIDR #1354
KEP: kube-proxy detect "local" traffic w/o cluster CIDR #1354
Conversation
Initial KEP to enhance iptables rules so that we don't depend on cluster CIDR as part of the rules, allowing for implementations to have more flexibility on how they manage POD IPs.
Welcome @satyasm! |
Hi @satyasm. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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/test-infra repository. |
@thockin @caseydavenport @MikeSpreitzer the KEP we briefly referred to during last weeks sig-network meetings. Can you please review? Needs ok-to-test :-) Thanks! |
ping @thockin , @caseydavenport , @MikeSpreitzer |
/ok-to-test |
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 @satyasm
Includes clarifications from comment discussions.
Updated KEP with comment feedback and added more details in terms of flags etc in the design details section. Please take a look. Thanks! |
/retest |
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 I like this
kube-proxy considers traffic as local if originating from a bridge within the node. | ||
``` | ||
|
||
Only one of `--cluster-cidr`, `--detect-local-with-node-cidr`, `--detect-local-with-pod-interface` or |
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 was thinking something like:
--detect-local={cluster-cidr | node-cidr | pod-interface-prefix | bridge}
defaulting to cluster-cidr for compat
- if cluster-cidr, look at the --cluster-cidr flag
- if node-cidr, look at the node PodCIDR field
- if interface-prefix, look at the --pod-interface-prefix flag
- if bridge, use physdev
This could extend to "cidr", with a list of specific CIDRs, "mark" with a specific mark value/mask, etc. This seems less ambiguous to me, but I am not wedded to it, either.
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 this. I really like this because if we default --detect-local=cluster-cidr, then the current behavior becomes the automatic default when not using any new flags. The only change I would make to this would be to adding an optional --node-cidr flag to go along with the node-cidr choice to handle cases where node CIDR(s) are not tracked as part of the node.podCIDR field. If --node-cidr is not specified, we default to node.podCIDR field.
Will update the kep with the new flag format.
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.
Not to bikeshed, but --detect-reachable
, since this isn't really about locality, but reachability?
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 put in my perspective on the following comment. I think "--detect-local" does capture the intent better? I don't think it's about reachability.
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.
Have updated this implementation section with the new flags. Can this be resolved?
some notion of node local pod traffic. | ||
|
||
The core logic in these cases is “how to determine” cluster originated traffic from non-cluster originated ones. | ||
The proposal is that tracking pod traffic generated from within the node is sufficient to determine cluster originated |
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 think you're making two assumptions here that don't hold for all clusters. The first is that all non-cluster-originated traffic cannot reach the cluster - this is often false, especially for Calico (cc @caseydavenport). The second one is that node-originated traffic is the complete set of traffic that does not need masquerading.
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 don't think this is about reachability. The more I think about it, I think it's about making sure that the return path from the backend pod hits the node where the DNAT happened so that the reverse DNAT can happen on the way back. Without this the end-to-end connection breaks. Using cluster pod-cidr to do this work today because we do the DNAT on every node boundary, and so the return path will hit that node. In case we don't do the DNAT on every node boundary, then we have to SNAT all traffic that did not originate from the node (even if part of the cluster pod-cidr) as otherwise the return path will not hit that node. I think that is what we are trying to reason through. And from that perspective, it seems to make more and more sense to write the rule as "locally generated from the node - no masquerad" vs "not locally generated from the node - so masquerade". 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.
@squeed based on this understanding, can we mark this as resolved?
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.
@squeed I think your first point is wrong (that this assumes ll non-cluster-originated traffic cannot reach the cluster). That is certainly possible in GCP, for example, and I don't see how this proposal changes that.
I think your second point is correct (that this assumes that node-originated traffic is the complete set of traffic that does not need masquerading). Can you expand on 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.
@thockin (sorry, k/enhancements mentions got blackholed). Argh, I forgot about NAT + return path. Ignore the noise, sorry.
updated implementation notes to the new mode flags. |
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.
Resolved code links to stable tags.
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.
LGTM. Some comments on flags which can be in followup discussion.
Thanks!
/lgtm
/approve
some notion of node local pod traffic. | ||
|
||
The core logic in these cases is “how to determine” cluster originated traffic from non-cluster originated ones. | ||
The proposal is that tracking pod traffic generated from within the node is sufficient to determine cluster originated |
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.
@squeed I think your first point is wrong (that this assumes ll non-cluster-originated traffic cannot reach the cluster). That is certainly possible in GCP, for example, and I don't see how this proposal changes that.
I think your second point is correct (that this assumes that node-originated traffic is the complete set of traffic that does not need masquerading). Can you expand on that?
|
||
the mode to use for detection local traffic. The default is cluster-cidr (current behavior) | ||
|
||
--cluster-cidr="cidr[,cidr,..]" |
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'd like to propose that we shelve this change until we know we need it. Rather than make this more robust, let's encourage people to not use it. If people scream and shout, we can add it back.
That said, if it turns out to be trivial to implement and test, OK.
than one can be specified if necessary. kube-proxy considers traffic as local if source is one | ||
of the CIDR values. This is only used if `--detect-local=cluster-cidr` . | ||
|
||
--node-cidr[="cidr[,cidr,..]"] |
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.
Do we really need this flag?
kube-proxy considers traffic as local if originating from an interface which matches one of given | ||
prefixes. string argument is a comma separated list of interface prefix names, without the ending '+'. | ||
This is only used if `--detect-local=pod-interface-prefix` or `--detect-local=bridge`. In the case of | ||
latter, the prefix is used as option to `--physdev-in name` match instead of just `--physdev-in` 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.
Do we really want a prefix? I think this would be cleaner as a flag of its own.
--pod-bridge-name
Then, like above, we can document it as a trailing '+' meaning prefix.
of the CIDR values. If value is not specified, or flag is omitted, defaults to node.podCIDR property on the node. | ||
This is only used if `--detect-local=node-cidr` . | ||
|
||
--pod-interface-prefix="prefix[,prefix,..]" |
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.
Do we really need multiple prefixes?
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 if we called this --pod-interface-name
and documented the trailing '+' as a prefix?
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: satyasm, thockin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
KEP to update iptables to have alternate ways of detecting cluster originated traffic instead of using the cluster cidr.