-
Notifications
You must be signed in to change notification settings - Fork 40.9k
Kube proxy node manager #130837
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
base: master
Are you sure you want to change the base?
Kube proxy node manager #130837
Conversation
Skipping CI for Draft Pull Request. |
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
/test pull-kubernetes-unit |
be7da13
to
a0c5cb5
Compare
/test pull-kubernetes-unit |
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 know this is WIP, but some initial comments...
a0c5cb5
to
2ccd845
Compare
/cc @aojea |
b28b193
to
7854882
Compare
pkg/proxy/topology.go
Outdated
@@ -191,15 +191,3 @@ func filterEndpoints(endpoints []Endpoint, predicate func(Endpoint) bool) []Endp | |||
|
|||
return filteredEndpoints | |||
} | |||
|
|||
// ExtractTopologyLabels consumes node labels and extract topology related labels if present. | |||
func ExtractTopologyLabels(nodeLabels map[string]string) map[string]string { |
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, but only notifying when there is change in proxy related labels made more sense to me.
Right, but can't NodeTopologyConfig
call ExtractTopologyLabels
?
How about master/pkg/proxy/apis/well_known_labels.go for a common place?
Hm... maybe rather than having it have to be in the same file as CategorizeEndpoints
, you could just add a comment to CategorizeEndpoints
pointing out that if you change the code to look at any other endpoints, you need to change ExtractTopologyLabels
(wherever that is) as well...
(Also, it would be best to have that code end up in the right place in the initial commit, rather than being added in one commit and then moved in the next commit. Or maybe that means swapping the order of the two commits?)
e5a7b94
to
39d7e6f
Compare
@danwinship I have squashed the two commits together, and added a comment in |
39d7e6f
to
000d9d2
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.
sorry for the delay. very close now.
} | ||
|
||
rawNodeIPs := s.NodeManager.NodeIPs() | ||
logger.Info("Successfully retrieved NodeIPs", "NodeIPs", rawNodeIPs) |
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.
rawNodeIPs
can be nil
/empty here if it timed out, right? We need to log an error somewhere if that happens; even if it's not fatal, it's unexpected and possibly bad, so we should warn the user.
One possibility would be to log it from within NewNodeManager
. Another would be to have s.NodeManager.NodeIPs()
return ([]net.IP, error)
, and we can log the error, but then keep going.
Also (and this is a problem with the existing code), it's weird that we log rawNodeIPs
but then we don't log anything if s.NodeIPs
ends up being different from that...
So:
- if we got no
rawNodeIPs
, log an error/warning - otherwise, log the
rawNodeIPs
(as above). - if
s.NodeIPs[s.PrimaryIPFamily].IsLoopback()
, log a warning about that (we do this indetectNodeIPs
) - otherwise, if we used
bindAddress
to overriderawNodeIPs
, log the resultingNodeIPs
and probably that should either all be done here, or else all be done in detectNodeIPs
, rather than splitting it up and making it hard to see for sure what gets logged
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.
rawNodeIPs can be nil/empty here if it timed out, right? We need to log an error somewhere if that happens;
rawNodeIPs will never be nil, assuming kubelet always sets some node IPs on the node when it first creates the Node object.
If the node manager times out waiting for existence of node object then it will throw an error that will cause kube-proxy to fail.
In the current code s.NodeManager.NodeIPs()
will never be called when node manager times out.
pkg/proxy/node.go
Outdated
@@ -208,3 +191,10 @@ func (n *NodeManager) OnNodeDelete(node *v1.Node) { | |||
|
|||
// OnNodeSynced is called after the cache is synced and all pre-existing Nodes have been reported | |||
func (n *NodeManager) OnNodeSynced() {} | |||
|
|||
// Node returns the latest copy of node object. |
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.
"You must not modify it"
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.
Is it fine if I skip this comment and return a deep copy instead?
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.
You could, but there are other places where we document that you're not supposed to modify a returned object (eg, Listers) so it's not bad to document that here.
000d9d2
to
7841a3e
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: aroradaman The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
you dropped half of the branch on re-push... |
This simplifies how the proxier receives update for change in node labels. Instead of passing the complete Node object we just pass the proxy relevant topology labels extracted from the complete list of labels, and the downstream event handlers will only be notified when there are changes in topology labels. Signed-off-by: Daman Arora <[email protected]>
NodeManager initialises node informers, waits for cache sync and polls for node object to retrieve NodeIPs, handle node events and crashes kube-proxy when change in NodeIPs is detected. Signed-off-by: Daman Arora <[email protected]>
NodeManager, if configured with to watch for PodCIDR watch, watches for changes in PodCIDRs and crashes kube-proxy if a change is detected in PodCIDRs. Signed-off-by: Daman Arora <[email protected]>
ProxyHealthServer now consumes NodeManager to get the latest updated node object for determining node eligibility. Signed-off-by: Daman Arora <[email protected]>
For kube-proxy, node addition and node update is semantically considered as similar event, we have exactly same handler logic for these two events resulting in duplicate code and unit tests. This merges the `NodeHandler` interface methods OnNodeAdd and OnNodeUpdate into OnNodeChange along with the implementation of the interface. Signed-off-by: Daman Arora <[email protected]>
7841a3e
to
26a42d6
Compare
damn I messed up my local branch 😓 |
/test pull-kubernetes-e2e-gce
|
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
This carries the work done in #125382 consolidates and simplifies how kube-proxy deals and watches over Node objects.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: