cc @fgrzadkowski @mwielgus @kubernetes/autoscaling

This should be fixed in 1.3 by migrating kubectl to use HPA in autoscaling/v1.

The referenced issue (#22431) points out that lots of clients will have usability issues if they are unable to show the user what percentage the controller is acting on

from @danmcp:

Part of what makes this difficult is there could be a very large difference between limit and request (especially for CPU since overcommit is common). And because HPA is based off of request, an 80% default might be a tiny fraction of limit. Which could result in the auto scaling being super aggressive for some time period before the user has a chance to take observed utilization into account. So it seems necessary to let the user understand what the default percentage will be set to for them to have a shot at understanding what's happening with their app.

from @jwforres:

From my understanding of what changed, this now means that a client will have no idea what parameters are being used to auto-scale (when the default is used). This is a big usability problem... think about it from a common user workflow:

1. I'm not sure what scaling parameters I want, I'll pick the default to start with
2. Something's not right and I'm not autoscaling soon enough, I should probably adjust something
3. I have no clue how to tune this because I have no idea what the current target is... let me make a wild guess

On the other hand, defaults more complicated when multiple metrics are introduced -- now that we have alpha custom metrics, you don't want CPU autoscaling by default if you have custom metrics set. However, at the moment, custom metrics are specified via an annotation. In autoscaling/v1 this is not problem, since we can leave the CPU percentage field empty, and it will stay that way (and if we have custom metrics, we won't get any default behavior on CPU from the controller). In extensions/v1beta1, a default gets set, so we'll always look at CPU percentage in the controller, even if we have custom metrics.

If you want to put the API-level default back in, we'd either have to elevate custom metrics to first-class citizens so that we could set the default for CPU only if no other metrics are specified (or attempt to check for the annotation value in the defaulting logic, which is probably not something that we want to do), or use a sentinel value to explicitly disable CPU autoscaling.

IMO, the "CPU target percentage is a special field different from custom metrics" design that we currently have is suboptimal, but switching back to the original layout of all metrics being specified as {"name": "foo", "value": "bar"} is probably out of the question at the moment (the custom metrics angle is mainly a problem since we have no way to indicate "I don't want this" vs "I want a default value for this").

@piosz -- status on this issue? Will it be fixed in 1.3?

@roberthbailey once #26775 is merged we can close this.

@DirectXMan12 I understand your concerns here. Not setting default to 80% was required to be able to scale only based on custom metrics (otherwise it would always scale based on cpu set by default to 80% + custom metrics).

I think defining reasonable default policies and behaviors should be a part of extending HPA definition (which basically means moving forward with custom metrics feature). cc @jszczepkowski

kubectl uses now hpa/v1 by default so closing the issue.