@kubernetes/sig-autoscaling-bugs

@max-rocket-internet: Reiterating the mentions to trigger a notification:
@kubernetes/sig-autoscaling-bugs

If I scale down manually:

I0606 12:06:57.269751 1 horizontal.go:592] Successful rescale of my-app-1, old size: 2, new size: 4, reason: cpu resource utilization (percentage of request) above target

And these are the resources specified in the deployment:

        resources:
          limits:
            cpu: 2048m
            memory: 4Gi
          requests:
            cpu: 2048m
            memory: 4Gi

Can you attach log to this issue ?

thanks

Hi @tedyu

I am using AWS EKS so the only HPA related log entries I can see are like this and nothing more:

I0612 09:51:36.511060 1 horizontal.go:777] Successfully updated status for xxxx
I0612 09:52:04.080816 1 horizontal.go:777] Successfully updated status for yyyy
I0612 09:52:34.415303 1 horizontal.go:777] Successfully updated status for zzzz

@tedyu Is there some other way I can get more debug information?

There are logs at higher verbosity. e.g. (not that this would be logged in your cluster)

		klog.V(4).Infof("proposing %v desired replicas (based on %s from %s) for %s", metricDesiredReplicas, metricName, metricTimestamp, reference)

See if you can tune up verbosity

@tedyu thanks for the suggestion but I don't think we have that option on EKS as it's K8S service: https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html

I guess I have to chase it up with AWS support?

Our deployment strategy could be also relevant:

spec:
  strategy:
    rollingUpdate:
      maxSurge: 100%
      maxUnavailable: 0
    type: RollingUpdate

Just look at these events and missing reason:

Events:
  Type     Reason                        Age                    From                       Message
  ----     ------                        ----                   ----                       -------
  Normal   SuccessfulRescale             4m59s                  horizontal-pod-autoscaler  New size: 8; reason: All metrics below target
  Normal   SuccessfulRescale             4m44s                  horizontal-pod-autoscaler  New size: 16; reason:
  Normal   SuccessfulRescale             4m29s                  horizontal-pod-autoscaler  New size: 32; reason:
  Normal   SuccessfulRescale             4m14s                  horizontal-pod-autoscaler  New size: 64; reason:
  Normal   SuccessfulRescale             3m59s                  horizontal-pod-autoscaler  New size: 128; reason:
  Normal   SuccessfulRescale             3m44s                  horizontal-pod-autoscaler  New size: 200; reason:
  Normal   SuccessfulRescale             0s (x2 over 5m14s)     horizontal-pod-autoscaler  New size: 4; reason: All metrics below target

I'm having the exact same issue as you @max-rocket-internet, also running on EKS with their latest version available to date. This is frustrating :(

@vdemonchy There may be sudden bursts of traffic，some times cause CPUUtilization to 100% , in this case,it won't scale down

some times cause CPUUtilization to 100% , in this case,it won't scale down

This is not the case.

The pod is all ready?
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details

If there were any missing metrics, we recompute the average more conservatively, assuming those pods were consuming 100% of the desired value in case of a scale down, and 0% in case of a scale up.
I can only speculate this is the case

@max-rocket-internet Try increasing your metrics resolution from the default. I was experienceing similar behavior, I added the flag --metric-resolution=5s (the default is 60s), and it seems to be behaving in a much more expected manner now.

As @SocietyCao said, in my case it appears that the HPA was rapidly scaling up my service, creating a bunch of pods that didn't have any metrics yet, which in turn caused the HPA to assume the pods were under load. Seems like it can create a feedback loop of sorts.

We are seeing the same behavior. Has this issue been resolved?

@wxwang33 What is your metrics-server resolution set to? That fixed it for me (on 1.14.6).

I will check later as I don't have direct access to it. Will update and thanks for the quick response!

I am having the same, issue , at first i thought its not scaling down, but as time went by , exactly 6 minutes , hpa scaled down the pods.
After looking at the events log , it showed up that an event was triggered to scale down the pods the moment the cpi load went off , but got executes 6 minutes later. I guess this is a feature or how it is supposed to work , it would be nice if we can get a gracePeriod option to define if we want to narrow down or reduce the time.
I am running k8s 1.16 on vagrant (test cluster) 1 master 2 workers

still an issue

This is also an issue for us with the HPA when using 2 metrics.
With the memory added to our HPA, we do see that the downscaling works, but at some point the downscaling stops, even through all reported metrics are below the configured threshold for the averageUtilization.

We haven't tried setting the threshold to double the expected size to see if this makes a difference.
The HPA does downscale, but only up to a certain point.

This is also an issue for us with the HPA when using 2 metrics. With the memory added to our HPA, we do see that the downscaling works, but at some point the downscaling stops, even through all reported metrics are below the configured threshold for the averageUtilization.

We haven't tried setting the threshold to double the expected size to see if this makes a difference. The HPA does downscale, but only up to a certain point.

OT - which dashboard is that?

This is also an issue for us with the HPA when using 2 metrics. With the memory added to our HPA, we do see that the downscaling works, but at some point the downscaling stops, even through all reported metrics are below the configured threshold for the averageUtilization.

We haven't tried setting the threshold to double the expected size to see if this makes a difference. The HPA does downscale, but only up to a certain point.

OT - which dashboard is that?

ArgoCD from our private clusters

This is also an issue for us with the HPA when using 2 metrics. With the memory added to our HPA, we do see that the downscaling works, but at some point the downscaling stops, even through all reported metrics are below the configured threshold for the averageUtilization.

We haven't tried setting the threshold to double the expected size to see if this makes a difference. The HPA does downscale, but only up to a certain point.

OT - which dashboard is that?

ArgoCD from our private clusters

Thanks!

Based on my experience, the key factor is that the metric is based on the Requested, not the Limit. Then, the condition to match is the Usage vs Request and the scale criteria.
On the other side, if you have 2 replicas, the required condition to scaleDown to 1 is that both replicas are 49%, so if it scales, the single one replica remaining would allocate 98% (49% on its side + 49% on the Terminated scaledDown pod). If Usage is not under 50% then an scaleDown trigger would cause the only single remaining pod to handle more than 100% of usage, which would immediately cause and scaleUp condition (which would be a riduculous loop :p).
If you have 3 pods instead of 2, the % change from 50% to 66% but the underlying analysis remains.

The Kubernetes project currently lacks enough active 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 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 rotten

Seeing this in kubernetes 1.21 when using custom metrics. The metric drops below target and the HPA responds by scaling up.

  Type    Reason             Age                   From                       Message
  ----    ------             ----                  ----                       -------
  Normal  SuccessfulRescale  5m52s (x49 over 15h)  horizontal-pod-autoscaler  New size: 4; reason: Service metric cortex_query_scheduler_queue_length above target
  Normal  SuccessfulRescale  2m20s (x34 over 9h)   horizontal-pod-autoscaler  New size: 8; reason: All metrics below target

I facing the same issue Scale down not working for me

NAME READY STATUS RESTARTS AGE
pod/device-service-78668474b5-fwd75 1/1 Running 0 156m
pod/device-service-78668474b5-g9cvg 1/1 Running 0 89m
pod/device-service-78668474b5-hz79v 1/1 Running 0 37m

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/device-service Deployment/device-service 33%/40%, 0%/70% 1 3 3 3h46m

Having the same issues with some HPA in 1.21 using API autoscaling/v1. Can anyone confirm if this is working better with autoscaling/v2?

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

/remove-lifecycle rotten

this is still a valid issue

/reopen

@h0jeZvgoxFepBQ2C: You can't reopen an issue/PR unless you authored it or you are a collaborator.

Could someone reopen this issue? I'm not allowed to do it

Yeah, this issue needs to be reopened as this is a blocker for using memory HPA in Kubernetes.

Any news?

@liggitt @wojtek-t @pohly @smarterclayton Could anyone of you reopen this issue maybe?

Is there any update on this?

@markandersontrocme Still got same issue on Kubernetes 1.24 with autoscaling/v2.

So much has changed in Kubernetes since I opened this issue but I guess some things never change: I have this issue again 😅

It seems some others also have the same problem. Rather than reopen an old issue with tonnes of comments I've created a new one to start fresh with autoscaling/v2: #120875