---
title: "Configuring the cluster autoscaler"
url: https://docs.ovhcloud.com/es/guides/public-cloud/containers-orchestration/managed-kubernetes/configure-cluster-autoscaler
lang: es
lastUpdated: 2026-06-22
---
# Configuring the cluster autoscaler

## Objective

OVHcloud Managed Kubernetes service provides you Kubernetes clusters without the hassle of installing or operating them.

During the day-to-day life of your cluster, you may want to dynamically adjust the size of your cluster to accommodate to your workloads. The cluster autoscaler simplifies the task by scaling up or down your OVHcloud Managed Kubernetes cluster to meet the demand of your workloads.

This guide follows up the [Using the cluster autoscaler](/es/guides/public-cloud/containers-orchestration/managed-kubernetes/using-cluster-autoscaler.md) guide, and it will cover a description of the cluster autoscaler configuration.

## Requirements

- An OVHcloud Managed Kubernetes cluster
- A basic understanding of [how the cluster autoscaler works and how to enable it](/es/guides/public-cloud/containers-orchestration/managed-kubernetes/using-cluster-autoscaler.md)

## Instructions

### Cluster autoscaler configuration

When the autoscaler is enabled on a node pool, it uses a default configuration.

Here you have a description of the parameters used in the autoscaler configuration, and their default value:

| Setting                            | Description                                                                                        | Default         |
| ---------------------------------- | -------------------------------------------------------------------------------------------------- | --------------- |
| `scan-interval`                    | How often the cluster is reevaluated for scale up or down                                          | 10 seconds      |
| `scale-down-delay-after-add`       | How long after a scale-up before scale-down evaluation resumes                                     | 10 minutes      |
| `scale-down-delay-after-delete`    | How long after node deletion before scale-down evaluation resumes                                  | `scan-interval` |
| `scale-down-delay-after-failure`   | How long after a scale-down failure before scale-down evaluation resumes                           | 3 minutes       |
| `scale-down-unneeded-time`         | How long a node must be unneeded before it is eligible for scale-down                              | 10 minutes      |
| `scale-down-unready-time`          | How long an unready node must be unneeded before it is eligible for scale-down                     | 20 minutes      |
| `scale-down-utilization-threshold` | Utilization ratio (requested resources / capacity) below which a node is considered for scale-down | 0.5             |
| `max-graceful-termination-sec`     | Max seconds to wait for pod termination when scaling down a node                                   | 600 seconds     |
| `balance-similar-node-groups`      | Balance node counts across pools sharing the same instance type and labels                         | false           |
| `expander`                         | Node pool selection strategy for scale-up: `most-pods`, `random`, `least-waste`, `priority`        | `random`        |
| `skip-nodes-with-local-storage`    | Never delete nodes with pods using local storage (EmptyDir or HostPath)                            | false           |
| `skip-nodes-with-system-pods`      | Never delete nodes with kube-system pods (except DaemonSets and mirror pods)                       | false           |
| `max-empty-bulk-delete`            | Max number of empty nodes that can be deleted simultaneously                                       | 10 nodes        |
| `new-pod-scale-up-delay`           | Min age of an unscheduled pod before the autoscaler acts on it                                     | 0 seconds       |
| `max-total-unready-percentage`     | Max percentage of unready nodes; autoscaler halts if exceeded                                      | 45%             |
| `max-node-provision-time`          | Max time the autoscaler waits for a node to be provisioned                                         | 15 minutes      |
| `ok-total-unready-count`           | Number of allowed unready nodes regardless of the percentage threshold                             | 3 nodes         |

You can get more information on those parameters on the [Kubernetes autoscaler documentation](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md).

If you consider we should reevaluate the default value and/or prioritize the possible customization of one of those parameters, you are welcome to create an issue on our [Public roadmap](https://github.com/orgs/ovh/projects/16/).

### Configuring the autoscaler

The easiest way to enable the autoscaler is using the Kubernetes API, for example using `kubectl`.

#### Using Kubernetes API

When the autoscaler is enabled on a node pool, it uses a [default configuration](/es/guides/public-cloud/containers-orchestration/managed-kubernetes/configure-cluster-autoscaler.md#cluster-autoscaler-configuration).

To list node pools, you can use:

```bash
kubectl get nodepools
```

You can change several parameters values through kubectl command:

```bash
kubectl patch nodepool <your_nodepool_name> --type="merge" --patch='{"spec": {"autoscaling": {"scaleDownUnneededTimeSeconds": <a_value>, "scaleDownUnreadyTimeSeconds": <another_value>, "scaleDownUtilizationThreshold": "<and_another_one>"}}}'
```

In my example cluster:

```console
$ kubectl get nodepool nodepool-b2-7 -o json | jq .spec
{
  "antiAffinity": false,
  "autoscale": true,
  "autoscaling": {
    "scaleDownUnneededTimeSeconds": 600,
    "scaleDownUnreadyTimeSeconds": 1200,
    "scaleDownUtilizationThreshold": "0.5"
  },
  "desiredNodes": 3,
  "flavor": "b2-7",
  "maxNodes": 100,
  "minNodes": 0,
  "monthlyBilled": false
}
```

```console
$ kubectl patch nodepool nodepool-b2-7 --type="merge" --patch='{"spec": {"autoscaling": {"scaleDownUnneededTimeSeconds": 900, "scaleDownUnreadyTimeSeconds": 1500, "scaleDownUtilizationThreshold": "0.7"}}}'
nodepool.kube.cloud.ovh.com/nodepool-b2-7 patched
```

```console
$ kubectl get nodepool nodepool-b2-7 -o json | jq .spec
{
  "antiAffinity": false,
  "autoscale": true,
  "autoscaling": {
    "scaleDownUnneededTimeSeconds": 900,
    "scaleDownUnreadyTimeSeconds": 1500,
    "scaleDownUtilizationThreshold": "0.7"
  },
  "desiredNodes": 3,
  "flavor": "b2-7",
  "maxNodes": 100,
  "minNodes": 0,
  "monthlyBilled": false
}
```

For the moment, only these following parameters are editable:

- autoscale
- autoscaling
- desiredNodes
- minNodes
- maxNodes

If you consider that we should prioritize the possible customization of other autoscaling parameters, you are welcome to create an issue on our [Public roadmap](https://github.com/orgs/ovh/projects/16/).

## Go further

To have an overview of OVHcloud Managed Kubernetes service, you can go to the [OVHcloud Managed Kubernetes page](https://www.ovhcloud.com/es-es/public-cloud/kubernetes/).

Otherwise to skip it and learn more about using your Kubernetes cluster the practical way, we invite you to look at our tutorials .

- For training or technical assistance implementing our solutions, contact your sales representative or visit our [Professional Services](https://www.ovhcloud.com/es-es/professional-services/) page to request a quote and have your project analyzed by our experts.

- Join our [community of users](https://community.ovhcloud.com/).