Autoscaler: Min & max not set for AWS ASG

[TimJones]

I have a small K8S v1.8.6 cluster deployed using kops with --node-count 2. This sets up an ASG with Min\Max instances both set to 2.

I then install an autoscaler Deployment with --nodes=1:3:<asg-name> but listing the ASG still shows Min\Max both set to 2.

I have to run kops edit instancegroup nodes to set the min\max to match before autoscaler can work.

I would expect autoscaler to set the min\max based on its config at startup.

[aleksandra-malinowska]

I would expect autoscaler to set the min\max based on its config at startup.

This feature (instance groups having built-in min/max limits which prevent resize requests) is AWS-specific. So it isn't part of Cluster Autoscaler's logic, the only change to override those settings would have to be in cloud provider code. Contributions are welcome :)

If you'd like to implement this, but are unsure how to do it, you can try to reach to other AWS cloud provider contributors for guidance (@sethpollack @mumoshu)

[TimJones]

I'd be happy to contribute when I have a few space cycles!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[aleksandra-malinowska]

/remove-lifecycle stale

[whereisaaron]

cluster-autoscaler already appears to have the functionality with --autodiscover to discover AWS ASGs and the min/max settings at start-up. The feature here would be to periodically re-run that discovery process and either update or entirely replace state.

The workaround is a CronJob to delete the cluster-autoscaler Pod periodically (ode for a kubectl rolling-update). That way it exhibits the desired behavior to automatically discover new settings and new ASGs.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.