Horizontal Pod Autoscaler - Ranges

[Leonardo-Ferreira]

Which component are you using?:

Horizontal Pod Autoscaler

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

My feature is meant to allow an easier control of your deployment total capacity

Describe the solution you'd like.:

Let's say that im scaling out/in based on CPU. I would like to be able to express that my IF my deployment usage of cpu is:

• inferior to 30%, a scale in operation should take place
• superior to 75%, a scale out operation should take place

any value in between, and the deployment stays put.

I imagine that the yml should look like:

spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment 
    name: sample-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      range: #NOT target, but RANGE!
        type: Utilization
        minUtilization: 30
        maxUtilization: 75

Describe any alternative solutions you've considered.:

Couldn't come up with alternative solutions

Additional context.:

I would be willing to help coding this feature

[raywainman]

Interesting idea...

This sounds very similar to what tolerance tries to do, except here you are specifying it on a per-HPA basis.

Does modifying the tolerance value help you at all? (Note that not all Cloud providers expose this to users as a configurable parameter).

[Leonardo-Ferreira]

given its a global value I can't really fiddle with it... would you be able to tell how the tolerance integrates with the formula desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]? perhaps desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] * abs(1-tolerance)

[raywainman]

The tolerance value isn't actually incorporated into the calculation itself, rather it is used as a check to see if we should still proceed with the calculation as seen below:

https://github.com/kubernetes/kubernetes/blob/83f99cbd4775a1d311df79537b4e26e4725a3128/pkg/controller/podautoscaler/replica_calculator.go#L135C2-L139C3

And yes, totally understand that having a global value here is hard to fiddle with.

[gjtempleton]

Moving issue as HPA controller is part of the core

/transfer-issue kubernetes

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[gjtempleton]

/sig autoscaling

[Leonardo-Ferreira]

so, is there a process here? or we just wait for other key members take notice and discuss?

[Leonardo-Ferreira]

any other feedback here?

[raywainman]

Sorry for the delay. Yes, basically we should try and solicit a bit more feedback from the community and then convert this to a KEP for more formal review. We have a SIG meeting on Mondays, I'd be happy to bring this one up if you like.

One thing to note - have you seen #116984? This is another take at this problem where I think the outcome is the same. We should probably pick one approach to move forward.