Tutorial: Autoscaling Your Node Pools (Beta)

You can now enable the OKS cluster autoscaler to automatically manage and scale your node pools based on resource usage.

OKS autoscaling is a form of horizontal autoscaling, meaning that instead of increasing the CPU or memory resources of an existing virtual machine (vertical autoscaling), it adjusts the number of nodes in your node pools (VM groups). This ensures your cluster scales dynamically and cost-effectively by adding or removing nodes as demand changes.

After providing you with context on how scaling operates, this tutorial is divided into two parts:

Updating existing clusters to support autoscaling.
Creating node pools that can be managed by the autoscaler.

Autoscaling is only supported for mono-Subregion node pools. You cannot set the autoscaling flag to true on a multi-Subregion node pool.

This feature is currently in beta. For more information about beta services, see the Glossary and our General Terms and Conditions of Sale.

Understanding Scaling Triggers

Upscaling

The autoscaler adds nodes to the pool in these cases:

When pods remain in a Pending state because no node has enough CPU or memory to host them.
When a new workload requests resources exceeding the current cluster capacity.
When resource usage consistently exceeds available node capacity.

Pods typically need to remain Pending for a few minutes before upscaling occurs. This prevents unnecessary node creation during short scheduling delays.

Downscaling

The autoscaler removes nodes when:

Nodes remain underexploited (low CPU and memory usage) for a sustained period.
All pods on a node can be rescheduled elsewhere without overloading other nodes.

Downscaling happens only after a cooldown period of around 10 minutes. This delay prevents any node from being prematurely removed during temporary traffic drops.

Updating Existing Clusters to Support Autoscaling Using OKS CLI

Run the cluster update command to manually enable autoscaling support:
```
$ oks-cli cluster update \
    --profile NAME_OF_PROFILE \
    --project-name NAME_OF_PROJECT \
    --cluster-name NAME_OF_CLUSTER
```
This command contains the following options that you need to specify:
- profile: The named profile you used to create the cluster you want to update.
- project-name: The name of the project containing the cluster you want to update.
- cluster-name: The name of the cluster you want to update.
Run the cluster upgrade command to deploy the autoscaler components on your cluster:
```
$ oks-cli cluster upgrade \
    --profile NAME_OF_PROFILE \
    --project-name NAME_OF_PROJECT \
    --cluster-name NAME_OF_CLUSTER
```
This command contains the following options that you need to specify:
- profile: The named profile you used to create the cluster you want to upgrade.
- project-name: The name of the project containing the cluster you want to upgrade.
- cluster-name: The name of the cluster you want to upgrade.

You are then prompted to confirm the cluster upgrade. Enter y to proceed.

Creating Node Pools Managed by the Autoscaler

Once your cluster supports the autoscaler, you can configure node pools to be automatically scaled based on workload demand.

Before you begin:

You must have an existing OKS cluster in a Ready state.
You must have a valid kubeconfig file and network access to the cluster’s API endpoint. You can verify connectivity with the kubectl get nodes command.
Nodes with attached local volumes (e.g., via hostPath) are excluded from autoscaler operations and upgrades to prevent data loss. To allow their removal, you must manually annotate them using the kubectl annotate node command.

Updating Your Node Pool Manifest

To create a node pool that can be managed by the autoscaler, you need to attach the required annotations to your node pool manifest, including:

Setting a minimum and maximum number of nodes.
Setting the autoscaling flag to true.

The following manifest sample defines a node pool named autoscaling-pool with autoscaling enabled between 2 and 10 nodes. It uses the tinav6.c2r4p3 node type in the eu-west-2a Region, starts with 2 nodes, supports auto-upgrade and auto-healing, and limits upgrades to 1 unavailable node at a time with no surge:

Node Pool Manifest Sample

apiVersion: oks.dev/v1beta2
kind: NodePool
metadata:
  name: autoscaling-pool
spec:
  minNodes: 2
  maxNodes: 10
  desiredNodes: 2
  nodeType: tinav6.c2r4p3
  autoscaling: true
  zones:
    - eu-west-2a
  upgradeStrategy:
    maxUnavailable: 1
    maxSurge: 0
    autoUpgradeEnabled: true
  autoHealing: true

For more information on how to write a manifest, see Node Pool Manifest Reference.

Applying the Node Pool Manifest Using Kubectl

Once your manifest is ready, you can apply it to the cluster using the following command:

$ kubectl apply -f NAME_OF_MANIFEST.yaml

The autoscaler now manages the number of nodes based on workload demands, scaling up or down within the minNodes and maxNodes limits defined in your manifest.

The desiredNodes value only acts as the initial node count. The autoscaler will override it as needed to match workload requirements.

Once the node pool is active, the autoscaler continuously monitors the cluster.

Related Pages