-
Notifications
You must be signed in to change notification settings - Fork 4.2k
update node info processors to include unschedulable nodes #8520
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
Open
elmiko
wants to merge
1
commit into
kubernetes:master
Choose a base branch
from
elmiko:unschedulable-nodes-fix
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Two things:
Isn't
readyNodes
a subset ofallNodes
? In which case this will range over the nodes inreadyNodes
twice.Also, how do we know the diff of
allNodes
-readyNodes
are nodes of typeReady
+Unschedulable
? Aren't there going to be other types of nodes not classified asreadyNodes
in that set (for example, various flavors ofNotReady
nodes)?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.
readyNodes
is not a pure subset ofallNodes
, there is some filtering that occurs to remove some of the nodes inreadyNodes
fromallNodes
.if you change this line to only use
allNodes
you will see some unit tests fail.i did look at how
readyNodes
andallNodes
are created, there is filtering that happens in this function https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/core/static_autoscaler.go#L993i have run a series of tests using
allNodes
and also using a version of this patch that specifically creates areadyUnschedulableNodes
list. after running both tests, and putting them through CI, i am more convinced that usingallNodes
here is the appropriate thing to do. adding a new lister for "ready unschedulable" nodes did not change the results of my testing, and it makes the code more complicated. this is why i went to using theallNodes
approach.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.
one more point about this, looking at the function in the mixed node info processor, we can see that there are other conditions than just "ready unschedulable" that are checked for. i think the original intent of this function was to look at all nodes.
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/processors/nodeinfosprovider/mixed_nodeinfos_processor.go#L181
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.
@towca does this seem like the right path forward to you as well?
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.
Should we be more precise about how we append
allNodes
toreadyNodes
to avoid duplicates? Or are we confident that the effort to de-dup is equivalent or more costly than duplicate processing?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 attempted a bit of archaeology and found the PR that added the filtering by readiness to this logic: #72. This is pretty bizarre, because even way back then it seems that this logic would only see Ready Nodes:
ScaleUp()
gets passedreadyNodes
:autoscaler/cluster-autoscaler/core/static_autoscaler.go
Line 230 in ea7bd81
autoscaler/cluster-autoscaler/core/scale_up.go
Line 49 in ea7bd81
In any case, IMO the most readable change would be to:
allNodes
instead ofreadyNodes
toTemplateNodeInfoProvider.Process()
without changing the signature. This is what the interface definition suggests anyway.MixedTemplateNodeInfoProvider.Process()
, group the passedallNodes
into good and bad candidates utilizingisNodeGoodTemplateCandidate()
. Then iterate over the good ones in the first loop, and over the bad ones in the last loop.This should work because:
readyNodes
should be a subset ofallNodes
. So the logic should see all the same Nodes as before + additional ones. This is a bit murky because the Node lists are modified byCustomResourcesProcessor
after being listed.CustomResourcesProcessor
implementations should only remove Nodes fromreadyNodes
and hack their Ready condition inallNodes
. This is what the in-tree implementations do, if an out-of-tree implementations breaks the assumption they might not be subsets but IMO this isn't a supported case and such implementations should be ready for things breaking.isNodeGoodTemplateCandidate()
(ready && stable && schedulable && !toBeDeleted) is a superset of conditions by whichreadyNodes
are filtered fromallNodes
(ready && schedulable). Both places use the samekube_util.GetReadinessState()
function for determining theready
part, the schedulable part is just checking the same field on the Node.allNodes
, but notreadyNodes
,isNodeGoodTemplateCandidate()
should always returnfalse
for it. So all the Nodes fromallNodes - readyNodes
should be categorized as bad candidates like we want.readyNodes
, it should also be inallNodes
and the result ofisNodeGoodTemplateCandidate()
should be identical for both versions. So the good candidates determined fromallNodes
viaisNodeGoodTemplateCandidate()
should be exactly the same as determined fromreadyNodes
like we do now.Does that make sense? @x13n could you double-check my logic here?
@elmiko IIUC you attempted something like this and got unit test failures? Could you describe what kind? I could definitely see the tests just being too coupled to the current implementation.
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.
at this point in the processing, i don't think the duplicates is an 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.
i will need to run the unit tests again, but essentially, if only
allNodes
is used in the final clause of the mixed node infos processor'sProcess
function, then a few tests fail. my impression is that the filtering occurring with the custom node processor or the processor that filters out nodes with startup taints is causing the issues.i can certainly take another look at passing only
allNodes
toProcess
. i didn't want to break anything else though XDThere 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 is one of the main failures i see when changing to use only
allNodes
:generated by running
go test ./...
in thecluster-autoscaler/core
directory.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.
actually, looking at this failure again. i think it's due to my change in the test.