-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
✨Support draining unready nodes #2165
✨Support draining unready nodes #2165
Conversation
Hi @hypnoglow. Thanks for your PR. I'm waiting for a kubernetes-sigs 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. |
/ok-to-test FYI @michaelgugino |
@michaelgugino @ncdc Does this PR covers the issue? Is anything missing? |
1dc0442
to
57813cf
Compare
/retest |
@hypnoglow: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
controllers/machine_controller.go
Outdated
@@ -348,6 +349,12 @@ func (r *MachineReconciler) drainNode(cluster *clusterv1.Cluster, nodeName strin | |||
DryRun: false, | |||
} | |||
|
|||
if !noderefutil.IsNodeReady(node) { |
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.
shouldn't this be checking the node is unreachable 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.
Could you please elaborate? The issue stated about "unready" node. How do we want to check if the node is unreachable?
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 believe there is any way for Cluster API to evaluate a node's reachability other than by looking at the conditions of the node in the workload cluster. Or am I missing something?
@michaelgugino @vincepri would we want to always set drainer.SkipWaitForDeleteTimeoutSeconds
, or only if certain node conditions are set?
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.
This feature comes in handy when the node is unreachable, see https://kubernetes.io/docs/concepts/architecture/nodes/.
In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the apiserver is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
#1870 (comment)
I believe we can assume this when the nodeReady status [1] is unknown [2].
[1] https://github.com/kubernetes-sigs/cluster-api/blob/master/controllers/noderefutil/util.go#L62-L67
[2] https://github.com/kubernetes/api/blob/master/core/v1/types.go#L2318
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.
100% agree with what you wrote, but I'm not clear if this is something we should always set, or only when the ready status is unknown?
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.
@enxebre did you see my last question?
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 I'd be in favour of setting the flag only when the kubelet status is unknown as we deliberately want to let draining move forward in such scenario. It seems safe to let any other unknown scenario where this might happen be visible by blocking draining for now.
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've updated the PR to check if node ready status is "Unknown
" instead of "not True
". Please check if this matches what we have discussed.
/test pull-cluster-api-capd-e2e |
57813cf
to
ec648ec
Compare
// IsNodeUnreachable returns true if a node is unreachable. | ||
// Node is considered unreachable when its ready status is "Unknown". | ||
func IsNodeUnreachable(node *corev1.Node) bool { | ||
if node == nil { |
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'm not sure we need this check. It should only ever be called with a valid node.
/assign @enxebre @michaelgugino |
@ncdc: GitHub didn't allow me to assign the following users: enxebre. Note that only kubernetes-sigs members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. In response to this:
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. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hypnoglow, ncdc 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 |
@@ -348,6 +349,11 @@ func (r *MachineReconciler) drainNode(cluster *clusterv1.Cluster, nodeName strin | |||
DryRun: false, | |||
} | |||
|
|||
if noderefutil.IsNodeUnreachable(node) { | |||
// When the node is unreachable and some pods are not evicted for as long as this timeout, we ignore them. |
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.
We should probably include a logging message here e.g "This node is unreachable, draining will wait for pod deletion during skipWaitForDeleteTimeoutSeconds
after the request and will skip otherwise." cc @ncdc @alexander-demichev @hypnoglow
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 can open a PR if everyone is ok with the change.
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 this to be something end users are aware of? If so, I would suggest an Event in addition to the log message.
The shouldSkipPod function doesn't seem like it takes into account nodes that come back or become unhealthy during the drain. Additionally, I'm pretty sure that kubelet updates the DeletionTimestamp multiple times while evicting a pod. |
What this PR does / why we need it:
Adds support for draining unready nodes.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #1870