Yandex Cloud
Search
Discuss with expertTry it for free
  • Customer Stories
  • Documentation
  • Blog
  • All Services
  • System Status
  • Marketplace
    • Featured
    • Infrastructure & Network
    • Data Platform
    • AI for business
    • Security
    • DevOps tools
    • Serverless
    • Monitoring & Resources
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Center for Technologies and Society
    • Yandex Cloud Partner program
    • Price calculator
    • Pricing plans
  • Customer Stories
  • Documentation
  • Blog
© 2026 Direct Cursus Technology L.L.C.
Yandex Managed Service for Kubernetes
  • Comparing with other Yandex Cloud services
  • Getting started
    • Resource relationships
    • Release channels and updates
    • Support for Kubernetes versions
    • Zones of control in Managed Service for Kubernetes
    • Updating node group OS
    • Encryption
    • Networking in Managed Service for Kubernetes
    • Network settings and cluster policies
    • Autoscaling
    • Audit policy
    • External cluster nodes
    • Quotas and limits
    • Recommendations on using Managed Service for Kubernetes
    • Recommended master configurations
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • Release notes

In this article:

  • Cluster autoscaling
  • Master autoscaling
  • Horizontal pod autoscaling
  • Vertical pod autoscaling
  • Use cases
  1. Concepts
  2. Autoscaling

Autoscaling

Written by
Yandex Cloud
Improved by
Andrei P.
Updated at July 13, 2026
View in Markdown
  • Cluster autoscaling
  • Master autoscaling
  • Horizontal pod autoscaling
  • Vertical pod autoscaling
  • Use cases

Autoscaling is when you resize a node group, change the number of pods or the amount of resources allocated to each pod based on resource requests for pods running on this group's nodes.

In a Managed Service for Kubernetes cluster, you can leverage the following auto-scaling options:

  • Cluster autoscaling (Cluster Autoscaler). Managed Service for Kubernetes monitors workloads on the nodes and updates the number of nodes within specified limits as required.
  • Master autoscaling (Master Autoscaler). Managed Service for Kubernetes monitors workload on the master node and updates its configuration as required.
  • Horizontal pod scaling (Horizontal Pod Autoscaler). Kubernetes dynamically changes the number of pods running on each node in the group.
  • Vertical pod scaling (Vertical Pod Autoscaler). When workloads increase, Kubernetes allocates additional resources to each pod within the set limits.

Warning

Starting June 18, 2026, master node auto-scaling will be enabled on all clusters in the RAPID release channel where the master is deployed in a highly available configuration.

You can employ several types of autoscaling in the same cluster. However, using Horizontal Pod Autoscaler and Vertical Pod Autoscaler together is not recommended.

Cluster autoscalingCluster autoscaling

Cluster Autoscaler automatically modifies the number of nodes in a group depending on your workloads.

Warning

You can only place an autoscaling node group in one availability zone.

When creating a node group, select an autoscaling type and set the minimum, maximum, and initial number of nodes in the group. Kubernetes will periodically check the pod status and workloads on the nodes, adjusting the group size as required:

  • If pods cannot be assigned due to a lack of vCPUs or RAM on the existing nodes, the number of nodes in the group will gradually increase to the specified maximum.
  • If a workload on nodes is low, and all pods can be assigned to fewer nodes in a group, the number of nodes in the group will gradually decrease to the specified minimum. If pods on the node cannot be evicted within the specified period of time (7 minutes), the node is forced to stop. The timeout cannot be changed.

Note

When calculating the current limits and quotas, Managed Service for Kubernetes uses the specified maximum node group size as its actual size, regardless of the current group size.

Cluster Autoscaler activation is only available when creating a node group. Cluster Autoscaler is managed on the Managed Service for Kubernetes side.

For more information, see these Kubernetes guides:

  • Cluster Autoscaler description
  • Default parameters

See also Questions and answers about node group autoscaling in Managed Service for Kubernetes.

Master autoscalingMaster autoscaling

Warning

Starting June 18, 2026, master node auto-scaling will be enabled on all clusters in the RAPID release channel where the master is deployed in a highly available configuration.

Warning

Starting June 18, 2026, master node pricing has changed, with fees now based on the number of vCPUs and the amount of RAM. Use this table to estimate the required master node resources for your cluster.

Master Autoscaler automatically adjusts master configuration according to the current workload. This enables stable cluster operation without manual configuration selection.

For scaling, Master Autoscaler regularly collects master utilization metrics, such as th number of vCPUs and the amount of RAM. It can then take the following decisions based on these metrics:

  • Scale up resources if the master node is near overload.
  • Scale down resources if the master node is consistently underutilized.
  • Keep resources unchanged if utilization is within normal ranges.

To prevent reactions to brief load spikes, Master Autoscaler takes decisions based on aggregated metrics over a few minutes. Scaling is only triggered when a critical threshold persists for a sustained period.

Apart from that, Master Autoscaler does not scale down below the master configuration you selected when creating or modifying your cluster; such configuration acts as a lower scaling limit.

After taking a decision, the scaler selects the closest matching master configuration to ensure that post-scaling utilization remains within normal limits.

Even when using Master Autoscaler, choose the master configuration that matches the real cluster load. You may want to check out our recommended configuration options that depend on the number of nodes, maximum number of pods, and CNI in use. An over-provisioned vCPU and RAM configuration will prevent the release of excess resources, while an under-provisioned one may cause over-frequent scaling.

You can view the master node auto-scaling operations under cluster operations. While scaling is in progress, you cannot initiate other cluster operations; you will have to wait for the process to complete.

Horizontal pod autoscalingHorizontal pod autoscaling

When using horizontal pod scaling, Kubernetes changes the number of pods depending on vCPU workload.

When creating a Horizontal Pod Autoscaler, specify the following parameters:

  • vCPU load average percentage for each pod.
  • Minimum and maximum number of pod replicas.

Horizontal pod autoscaling is available for the following controllers:

  • Deployment.
  • StatefulSet.
  • ReplicaSet.

Learn more about Horizontal Pod Autoscaler in this Kubernetes guide.

Vertical pod autoscalingVertical pod autoscaling

Kubernetes uses the limits parameters to restrict resources allocated for each application. A pod exceeding the vCPU limit will trigger CPU throttling. A pod exceeding the RAM limit will be stopped.

If required, Vertical Pod Autoscaler allocates additional vCPU and RAM resources to pods.

When creating a Vertical Pod Autoscaler, set the autoscaling mode in the specification:

  • updateMode: "Off" for Vertical Pod Autoscaler to provide recommendations on managing pod resources without modifying them.
  • updateMode: "Initial" for Vertical Pod Autoscaler to apply recommendations only when creating pods.
  • updateMode: "Recreate" for Vertical Pod Autoscaler to recreate pods with updated resource values in case of a serious discrepancy between the current requests and recommendations.
  • updateMode: "InPlaceOrRecreate" for Vertical Pod Autoscaler to attempt updating requests and resource limits first, without restarting the pod. If such an update is not possible, the pod will be recreated as in the Recreate mode. For more information, see Resize CPU and Memory Resources assigned to Containers.

Learn more about Vertical Pod Autoscaler in this Kubernetes guide.

Use casesUse cases

  • Horizontal scaling of an application in a cluster
  • Vertical scaling of an application in a cluster

Was the article helpful?

Previous
Network settings and cluster policies
Next
Audit policy
© 2026 Direct Cursus Technology L.L.C.