Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
• Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

Welcome @bysnupy!

It looks like this is your first PR to kubernetes/kubernetes 🎉. 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/kubernetes 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. 😃

Hi @bysnupy. 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.

I signed it

/kind bug

/assign @soltysh

Hi @bysnupy , a similiar PR to this #100222

@lauchokyip Great ! Thank you for your kind information. I didn't realized the previous one.
As far as I'm concerned, kubectl top node metrics are also used by autoscaler on k8s. Basically autoscaler and scheduler is the related each other, if it's design, it makes sense for me.
One more thing, does it mean that the 100+% result does not affect the autoscaler negatively ?

Even if it's no problem on other feature, 100+% is confused sometimes on usual users. If possible we should notify this value can be more than 100% in the docs, or if the metrics is more than 100%, it should set as 100% is, not 100+%. e.g.> If actual calculation result is 125%, it should show users as 100%. How about your thought ?

@bysnupy , I am not familiar with this area, this is what @soltysh responded and you might help it helpful
#99945 (comment). Sorry!

@lauchokyip No problem. I've also created other PR here #103253 to fix this issue which is based on another standpoint. Could please TAL ? @soltysh I'd appreciate any help you can offer. Thank you !

@soltysh in https://github.com/kubernetes/kubernetes/pull/100222/files/7b43880b4c95e2928c59a3c2b72382aec8894e25#diff-c3a7260dd14d315707b6043e9ed76a19bfcdd233f465d7cd5b95dd2aaadcec6f you explain that:

The reason we pick Allocatable over Capacity is because it represents the value available for scheduling, ie. for running pods. That's by design, not a bug.

If I've understood correctly, this PR claims the problem is that the numerator and the denominator in the calculation don't have the same logical basis: we're dividing a number that includes reserved capacity (actual usage) by a number that excludes it (allocatable), yielding a result that doesn't make sense. Is that true based on your knowledge of the underlying metrics? If it is, this PR's solution makes more sense to me than #103253, which essentially rounds down to hide the values when they're visibly incorrect but does not fix them otherwise. I'm going to change the reviewers on that PR to match this one, since they are alternatives.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

/hold cancel

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bysnupy, soltysh

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

The pull request process is described here

/sig cli

/retest

@bysnupy: You must be an org member to edit the release note.