-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Use KubeletServer.NodeIP instead of KubeletServer.HostnameOverride to set node IP #6310
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
Use KubeletServer.NodeIP instead of KubeletServer.HostnameOverride to set node IP #6310
Conversation
Depends on kubernetes/kubernetes#18541 |
Changing back could trigger more attempts by the node to delete and recreate its API object (which prevents the node from starting) |
Need to resolve kubernetes/kubernetes#17731 before this can merge |
f705544
to
1b3c2d9
Compare
[test] |
51167af
to
2b425d8
Compare
change |
can you outline the ways you tested this? Off the top of my head, I'd expect:
|
For the part that I wrote: Before my patch:
After my patch:
|
…vider Previously, if the kubelet tried to register itself with the API server, and was rejected due to the external ID changing, it would delete the node object and recreate it. This commit causes it to tolerate a change in ExternalID when the ExternalID is not being provided by a cloud provider, assuming the new ExternalID is either the node's (metadata) name, or one of node's addresses.
2b425d8
to
7da6989
Compare
Updated the PR: For tolerating node externalID to have hostname or node IP in case of non-cloud provider, we just need to look at the currentNode.Spec.ExternalID (instead of node.Spec.ExternalID). Tested various combinations from v1.0.8 to v1.1.1 without fix and with fix. I think, I covered all the test cases mentioned by @liggitt and @DirectXMan12 |
@pravisankar LGTM. The logic you removed was for the "hostname -> nodeIP" case, but that should be solved by your other changes, correct? |
LGTM |
LGTM who is going to click the button? |
|
||
if kl.cloud == nil { | ||
// In the case where we're not using a cloud provider, the ExternalID could either have | ||
// been the NodeIP, or the actual hostname. If we switch between the two, consider 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.
Do we want a link back to the PR that introduced the nodeIP issue?
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 in the code, fine to link from this PR, which is reachable from the commit breadcrumb
[merge] |
LGTM |
1 similar comment
LGTM |
https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/8529/
|
[test] |
Opened an issue for the test problem
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/4628/) (Image: devenv-rhel7_3144) |
URI.js issue resolved in https://ci.openshift.redhat.com/jenkins/job/devenv_ami/3143/ |
Evaluated for origin test up to 7da6989 |
Evaluated for origin merge up to 7da6989 |
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/8543/) |
Merged by openshift-bot
Did this ever get moved upstream? |
the toleration to avoid deleting/recreating? no, though I doubt upstream cares... the node just deletes itself there |
No description provided.