feat(nodeScaleDownTime): add a new metric to track unprocessed nodes during scaleDown #8614

shaikenov · 2025-10-05T19:17:13Z

What type of PR is this?

/kind feature

What this PR does / why we need it:

This PR adds a new metric to the exported prometheus metrics list: LongestNodeScaleDownTime

We want to track all the nodes that were marked as unneeded, but were unprocessed during the ScaleDown. If a node was unneeded, but unprocessed multiple times consecutively, we store only the earliest time it happened. The difference between the current time and the earliest time among all unprocessed nodes will give the longest time. This time can give us an indication of possible throttling and helps to better monitor what happens during ScaleDown.

Which issue(s) this PR fixes:

None

Special notes for your reviewer: this is a draft PR, work is still in progress

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

None

k8s-ci-robot · 2025-10-05T19:17:16Z

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

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.

linux-foundation-easycla · 2025-10-05T19:17:20Z

The committers listed above are authorized under a signed CLA.

✅ login: shaikenov / name: Olzhas Shaikenov (a279f58)

k8s-ci-robot · 2025-10-05T19:17:22Z

Welcome @shaikenov!

It looks like this is your first PR to kubernetes/autoscaler 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/autoscaler has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

k8s-ci-robot · 2025-10-05T19:17:23Z

Hi @shaikenov. 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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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-sigs/prow repository.

kada2004

very good

k8s-ci-robot · 2025-10-06T06:57:05Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kada2004, shaikenov
Once this PR has been reviewed and has the lgtm label, please assign aleksandra-malinowska for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

cluster-autoscaler/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

cluster-autoscaler/core/scaledown/planner/planner.go

cluster-autoscaler/core/scaledown/planner/planner_test.go

cluster-autoscaler/core/scaledown/planner/planner.go

cluster-autoscaler/metrics/metrics.go

cluster-autoscaler/core/scaledown/planner/planner.go

cluster-autoscaler/core/scaledown/planner/planner_test.go

cluster-autoscaler/metrics/metrics.go

MartynaGrotek · 2025-10-09T16:22:13Z

cluster-autoscaler/config/autoscaling_options.go

+	// We want to track all the nodes that were marked as unneeded, but were unprocessed during the ScaleDown.
+	// If a node was unneeded, but unprocessed multiple times consecutively, we store only the earliest time it happened.
+	// The difference between the current time and the earliest time among all unprocessed nodes will give the longest time
+	LongestNodeScaleDownTimeTrackerEnabled bool


This sounds a bit like a node has been deleted...

pointed that nodes are unprocessed and not deleted

cluster-autoscaler/core/scaledown/planner/planner.go

MartynaGrotek · 2025-10-09T17:05:47Z

cluster-autoscaler/core/scaledown/planner/planner.go

+		// if l.minimumTime is 0, then in previous iteration we also processed all the nodes, so the longest time is 0
+		// otherwise -> report the longest time from previous iteration and reset the minimumTime
+		if l.minimumTime.IsZero() {
+			longestTime = 0
+		} else {
+			longestTime = currentTime.Sub(l.minimumTime)
+			l.minimumTime = time.Time{}
+		}
+		l.nodeNamesWithTimeStamps = make(map[string]time.Time)


Seems like this will never be called, because you check for null in handleUnprocessedNodes and return early in that case. I would also add unit test covering this path.

in handleUnprocessedNodes() I do check the p.longestNodeScaleDownT for being null and not nodeNames. It is needed for the case when flag is disabled and longestNodeScaleDownT is not instantiated.
We will end up in this part of code if we have processed all the nodes.
About the unit tests I already check this behavior in "Test the functionality of longestNodeScaleDownT with all nodes processed in the first iteration" and "LongestLastScaleDownEvalDuration flag is disabled"

MartynaGrotek · 2025-10-09T17:33:18Z

cluster-autoscaler/core/scaledown/planner/planner_test.go

+func TestLongestNodeScaleDownTime(t *testing.T) {
+	testCases := []struct {
+		name                        string
+		nodes                       []*apiv1.Node


Seems unused

MartynaGrotek · 2025-10-09T17:36:06Z

cluster-autoscaler/core/scaledown/planner/planner_test.go

+					assert.Equal(t, val, start)
+				}
+			}
+			tc.unprocessedNodes = []string{"n2", "n3"}


This is not very readable, I mean updating test case params here.

introduced 2d array for unprocessedNodes

MartynaGrotek · 2025-10-09T17:42:35Z

cluster-autoscaler/core/scaledown/planner/planner_test.go

+	testCases := []struct {
+		name                        string
+		nodes                       []*apiv1.Node
+		unprocessedNodesInFirstIter []string


I am wandering if having 2 dim array where each row reflects one iteration wouldn't be more flexible? You could also then get rid of run param.

MartynaGrotek · 2025-10-09T17:47:42Z

cluster-autoscaler/core/scaledown/planner/planner_test.go

+			registry := kube_util.NewListerRegistry(nil, nil, nil, nil, nil, nil, nil, nil, nil)
+			provider := testprovider.NewTestCloudProviderBuilder().Build()
+			provider.AddNodeGroup("ng1", 0, 0, 0)
+			for _, node := range tc.nodes {
+				provider.AddNode("ng1", node)
+			}
+			autoscalingCtx, err := NewScaleTestAutoscalingContext(config.AutoscalingOptions{
+				NodeGroupDefaults: config.NodeGroupAutoscalingOptions{
+					ScaleDownUnneededTime: 10 * time.Minute,
+				},
+				ScaleDownSimulationTimeout:             1 * time.Second,
+				MaxScaleDownParallelism:                tc.maxParallel,
+				LongestNodeScaleDownTimeTrackerEnabled: tc.isFlagEnabled,
+			}, &fake.Clientset{}, registry, provider, nil, nil)


Seems like setup. Do we need to recreate it for each test case?

I think before autoscalingCtx instantiation - yes, we can put it as part of setup. autoscalingCtx has MaxScaleDownParallelism and LongestNodeScaleDownTimeTrackerEnabled which I alternate in different test cases, so I would prefer to have it recreated

… nodes during scaleDown

k8s-ci-robot added the do-not-merge/needs-area label Oct 5, 2025

k8s-ci-robot added cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Oct 5, 2025

k8s-ci-robot added area/cluster-autoscaler and removed do-not-merge/needs-area labels Oct 5, 2025

k8s-ci-robot requested review from feiskyer and vadasambar October 5, 2025 19:17

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Oct 5, 2025

kada2004 approved these changes Oct 6, 2025

View reviewed changes

shaikenov force-pushed the shaikenov-scaledown-unprocessed-node-tracking branch from b9e7969 to 86a98d1 Compare October 6, 2025 11:40

MartynaGrotek reviewed Oct 7, 2025

View reviewed changes

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 7, 2025

jackfrancis reviewed Oct 7, 2025

View reviewed changes

cluster-autoscaler/core/scaledown/planner/planner.go Outdated Show resolved Hide resolved

jackfrancis reviewed Oct 7, 2025

View reviewed changes

cluster-autoscaler/core/scaledown/planner/planner_test.go Outdated Show resolved Hide resolved

jackfrancis reviewed Oct 7, 2025

View reviewed changes

cluster-autoscaler/core/scaledown/planner/planner_test.go Outdated Show resolved Hide resolved

shaikenov force-pushed the shaikenov-scaledown-unprocessed-node-tracking branch from 86a98d1 to 0457f73 Compare October 8, 2025 08:56

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 8, 2025

shaikenov force-pushed the shaikenov-scaledown-unprocessed-node-tracking branch from 0457f73 to c2756ca Compare October 8, 2025 15:22

MartynaGrotek reviewed Oct 9, 2025

View reviewed changes

cluster-autoscaler/metrics/metrics.go Outdated Show resolved Hide resolved

MartynaGrotek reviewed Oct 9, 2025

View reviewed changes

feat(nodeScaleDownTimeTracker): add a new metric to track unprocessed…

a279f58

… nodes during scaleDown

shaikenov force-pushed the shaikenov-scaledown-unprocessed-node-tracking branch from c2756ca to a279f58 Compare October 10, 2025 12:00

feat(nodeScaleDownTime): add a new metric to track unprocessed nodes during scaleDown #8614

Are you sure you want to change the base?

feat(nodeScaleDownTime): add a new metric to track unprocessed nodes during scaleDown #8614

Conversation

shaikenov commented Oct 5, 2025

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Special notes for your reviewer: this is a draft PR, work is still in progress

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

Uh oh!

k8s-ci-robot commented Oct 5, 2025

Uh oh!

linux-foundation-easycla bot commented Oct 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k8s-ci-robot commented Oct 5, 2025

Uh oh!

k8s-ci-robot commented Oct 5, 2025

Uh oh!

kada2004 left a comment

Choose a reason for hiding this comment

Uh oh!

k8s-ci-robot commented Oct 6, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

linux-foundation-easycla bot commented Oct 5, 2025 •

edited

Loading