Prevent scale up to specifix node pools on aks and gke

[eyltl]

Hey Using cluster autoscaler There is any way to suspend scale up operation on a specific node pool? For example i have a use case , i have 2 node pools I want to prevent one node pool from scale up But to continue to scale down as needed

it possible?

[Bryce-Soghigian]

Are you using the managed AKS Autoscaler? or are you deploying your own Cluster Autoscaler on AKS? What sort of GKE configuration do you have?

[Bryce-Soghigian]

/assign Bryce-Soghigian

[eyltl]

Hi For aks i am using cluster autoscaler https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/azure/README.md

For gke i am using autodiscover with the prefix of the node pool

[Bryce-Soghigian]

Sorry for the late reply. FOr cluster autoscaler there are a couple of ways to get around scaling up further.

THe first reccomended way I would use to prevent scale up beyond a threshold is to set a --max-count parameter on the aks nodepool api to control the number of nodes we scale up to. Also you can configure certain node pools to not be autoscaling nodepools. So if you just want autoscaler to scale up for one pool, just enable one nodepool.

What is your usecase? Autoscaler only creates new nodes based on pending pods. Why do you want to suspend scaling operations?

[eyltl]

Thanks for your reply So the idea is to be able to do a blue green migration for node pools So for example i have node pool A and node pool B and i want to move all my workloads from A to B i can taint all the nodes on A with some taint And than to rollout restart my apps. Due to the taints on node pool A , apps will be scheduled on node pool B, however autoscaler can still scale up node on node pool A, if the node pools is still manage by autoscaler, The idea to keep it manage by autoscaler is for the scale down operations but to block it from scale up so pods will move to the new node pool, in eks it possible by suspending process on the autoscaler group configuration, If i will modify the max node group size to 1 (vmss tags/deployment for gcp) it will do the trick ?( GCP and Azure) On azure there is possible to add taint via VMSS tags, it possible also for gke?

thanks

[eyltl]

Any update on this?

[pescetto]

I am also curious if a scale down only / disable scale up feature will work for an EKS node group / ASG. The use case would be the same as @eyltl 's where we're upgrading our cluster, so we standup a new upgraded node group, cordon the old nodes, and would like to only scale down on the old node group as workloads slowly migrate to the new node group. This will help keep costs down as app deployments happen. Currently we have to monitor the old nodes and then manually this command:

aws --profile terraform autoscaling terminate-instance-in-auto-scaling-group --instance-id <INSTANCE_ID> --should-decrement-desired-capacity

It would be very helpful if we could add a label like this:

k8s.io/cluster-autoscaler/scale-down-only = true

Thus making cluster upgrades easier.

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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-ci-robot]

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

In response to this:

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

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.