[UX] Improve the "memory utilization too big" message

[shapirus]

Which component are you using?:

cluster-autoscaler

Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:

On seeing the following message in the log:

Node <node_name> is not suitable for removal - memory utilization too big (0.664205)

one can naturally think that it happens because it's the actual memory usage that is too high and become confused on checking it with kubectl top node and seeing very low reported usage, e.g.:

NAME                  CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
<node_name>           47m          1%     3794Mi          24%       

...whereas the real reason is that it's the total memory requested, rather than used, by pods, that is too high for considering the node for removal.

A proof that it's a UX issue is that this confusion lead to opening issues in the past, e.g., #2303 (and we don't know how many people just ignored it as a weird quirk and didn't care to open an issue).

Describe the solution you'd like.:

Change the message to get rid of any chance of it being misinterpreted and make it easy to understand how this aspect of CA works without even looking in the docs, e.g.:

Node %s is not suitable for removal - memory requests allocation too high (%.2f)

There is quite possibly a similar situation with the CPU-related message. If that's the case, it would benefit from such a change too.

[shapirus]

Created a PR with a suggested change: #6223

I used the terminology along the lines of the kubectl describe node output:

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests       Limits
  --------           --------       ------
  cpu                125m (3%)      0 (0%)
  memory             10373Mi (66%)  66660Mi (426%)

did not replace %f with %.2f in the PR, but I think it'd be a good idea as well. To be determined in further discussion, if there will be any.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale