Docs

Volcengine Kubernetes Engine

Workload autoscaler

Workload scaling overview

Workload scaling refers to the modification of the scheduling capacity of a workload by adding the number of application workload replicas. This topic describes the workload scaling solutions and principles in VKE clusters.

Solution introduction

VKE supports the workload scaling solutions described in the following table.

Solution name	HPA	CronHPA	IHPA
Solution overview	Horizontal Pod Autoscaler	CronHPA functions as a preset task, which can execute specified scaling rules at specified times. This automatically scales out or scales in computing resources to meet business requirements and control costs.	Intelligent Horizontal Pod Autoscaler (IHPA) is provided by the internal AI algorithm team of the Volcano Engine cloud-native team based on the time series prediction algorithm. IHPA can generate resource profiles and time-based resource views of workload replicas and resources (such as CPU and memory utilization) based on historical and predicted workload data. IHPA accurately adjusts the number of workload replicas to promptly respond to changes in business workloads based on data.
Scaling criteria	Resource metrics such as CPU, memory, GPU, and network Custom metrics	The time period, such as specific time points each hour, each day, each week, or each month.	Performs prediction and learning based on resource metrics such as CPU and memory, and generates resource views that reflect changes over time. Automatically scales resources based on resource views.
Application scenarios	HPA is suitable for online services that include a large number of pods and require frequent scaling to handle traffic fluctuations, such as e-commerce services, online education, and financial services.	CronHPA is suitable for services that have fixed traffic patterns and scenarios where you need to run applications at a scheduled time.	IHPA can automatically identify the pattern of workload fluctuations and predict resource demand based on historical metric data to implement predictive scaling, which reduces the impact of native HPA scaling delay on business operations.
Related documentation	Achieving autoscaling by using CPU and memory metrics Achieving autoscaling by using GPU and network metrics Achieving autoscaling by using custom metrics	Creating CronHPA	IHPA overview Creating IHPA

Technical principles

HPA

The Horizontal Pod Autoscaler (HPA) is used in Kubernetes clusters for automatically scaling Pods horizontally. It dynamically adjusts the number of Pods in workloads such as Deployments and ReplicaSets based on metrics like CPU and memory utilization, GPU and GPU memory usage, and network throughput.

A HPA is implemented as a Kubernetes API resource and a controller. The behavior of the controller is determined by resources. The controller periodically obtains metrics such as CPU and memory utilization, GPU and GPU video memory utilization, and network throughput, and compares the obtained metric values with the target values to make corresponding adjustments to the number of replicas in Replication Controllers or Deployments.

HPA is implemented as a control loop, and the loop cycle is specified by the --horizontal-pod-autoscaler-sync-period flag in the controller manager.

The process in each cycle is as follows:

The controller manager queries the user-defined expected metrics of resources in HPA.

In addition, the controller manager obtains the current resource metrics of each pod based on the resource metrics API (with the metrics server being its implementation).

The HPA calculates the scaling proportion based on the current metric and the expected metric.

tip

The formula is as follows: Expected number of replicas = ceil [Current number of replicas × (Current metric/Expected metric)]. Here, ceil refers to rounding up the value to the nearest integer.

For example:

Assuming the current CPU metric is 200 millicores and the expected metric is 100 millicores, since 200.0/100.0 = 2.0, the replica count will double.

Assuming the current CPU metric is 50 millicores and the expected metric is 100 millicores, since 50.0/100.0 = 0.5, the replica count will halve.

If the calculated scaling proportion is close to 1, specifically when |scaling ratio - 1.0| <= tolerance value based on the Kubernetes HPA calculation method, the scaling operation will not be performed. The default tolerance value in the community edition is 0.1, which is the globally set value of the --horizontal-pod-autoscaler-tolerance parameter.

HPA can be configured with one or multiple target metrics. When configured with a single target metric, the desired number of replicas is calculated by summing the current metric values of all Pods, dividing by the target value, and rounding up. For example, consider a Deployment with 3 Pods whose CPU usage is 70%, 50%, and 90% respectively. If the HPA target CPU utilization is set to 50%, the desired number of replicas is calculated as (70 + 50 + 90) / 50 = 4.2, which rounds up to 5.

If you configure multiple expected metrics, calculate the expected number of replicas for each one. Use the maximum value as the final expected number of replicas.

tip

HPA does not apply to objects that cannot be scaled, such as DaemonSets.

CronHPA

The Cron Horizontal Pod Autoscaler (CronHPA) functions as a preset task, which can execute specified scaling rules at specified times. This automatically scales out or scales in computing resources to meet business requirements and control costs.

CronHPA is suitable for scenarios where workloads change regularly over time, such as flash sales in e-commerce. The flash sales in e-commerce start at a fixed time point. In this case, you can use the CronHPA feature to automatically scale out workloads during specified time periods to ensure that the whole system runs as expected.

Description of HPA and CronHPA compatibility

The YAML definition for CronHPA is as follows:

Based on the preceding definition of CronHPA, you can discover that:

CronHPA knows the values of minReplicas, maxReplicas, and desiredReplicas in HPA.

CronHPA knows the current value of Relicas that corresponds to scaleTargetRef in HPA.

CronHPA adjusts the number of workload replicas by preferentially adjusting HPA.

CronHPA compares the desired and current replica counts and takes the larger value. It then determines if scale-in or scale-out is needed, and whether to adjust HPA's upper limit.

CronHPA determines whether to modify the lower limit of HPA by comparing the desired number of replicas and the configured number of replicas for HPA and taking the lower value.

Therefore, CronHPA is compatible with HPA in the following rules:

HPA (min/max)	CronHPA	Workload replica	Scaling result	Description of compatibility rules
1/10	5	5	HPA (min/max): 1/10 Workload replicas: 5	When the target replica count in CronHPA equals the current count, you don't need to modify HPA's maximum/minimum replica counts or the current application replica count.
1/10	4	5	HPA (min/max): 1/10 Workload replicas: 5	When the target number of replicas in CronHPA is less than the current number of replicas, retain the current number of replicas.
1/10	6	5	HPA (min/max): 6/10 Workload replicas: 6	When the target replica count in CronHPA is higher than the current replica count, keep the CronHPA target count. If the target replica count exceeds the HPA minimum replicas (minReplicas), update the HPA minReplicas.
5/10	4	5	HPA (min/max): 4/10 Workload replicas: 5	When the target number of replicas in CronHPA is less than the current number of replicas, retain the current number of application replicas. When the target number of replicas in CronHPA is less than the minimum number of HPA replicas (minReplicas), modify the minimum number of HPA replicas.
5/10	11	5	HPA (min/max): 11/11 Workload replicas: 11	When the target replica count in CronHPA exceeds the current count, retain that target number. When the target replica count in CronHPA exceeds HPA's maxReplicas, adjust HPA's maximum replicas.

Last updated: 2026.07.24 14:51:37