VKE provides the node amplification feature to virtually inflate the allocatable resources of nodes by using the Katalyst framework. It increases node deployment density without modifying workload declarations. This topic describes how to enable and use the node amplification feature for a cluster.

Feature introduction

Node amplification virtually inflates the capacity and allocatable resources of a node. It makes the scheduler perceive a larger available capacity and schedules more Pods onto the node. This fully uses idle physical resources and achieves Pod‑density improvement with zero intrusion on the Pods.

This capability is implemented through three independent policy groups: the amplification policy, scheduling watermark, and pressure eviction. Each is managed by its own CRD. You can combine them as needed:

CRD	Responsibility	Configuration content
NodeOvercommitConfig (NOC)	Amplification policy	Select node pools, set amplification ratios (static/dynamic), and set load watermarks.
NodeSchedulingConfig	Scheduling watermark	Configure the load‑aware scheduling threshold (stop line) per node pool.
AdminQoSConfiguration (AQC)	Pressure eviction	Tiered pressure eviction: Label‑based fine‑grained eviction and system‑pressure QoS‑aware fallback eviction.

Prerequisites

The katalyst add-on has been installed in the target cluster, and the node amplification feature is enabled on the Addon parameter configuration page. For details, see katalyst.

Dynamic amplification and prediction rely on VMP to provide historical metric queries. Dynamic prediction estimates load based on the use-defined amplification ratio. Cloud-native observability has been enabled in VKE. For details, see Enabling observability. For the names of related core metrics, see the Appendix section of this topic.

Considerations

Before you enable the node amplification feature, confirm the following limitations to prevent business interruption or resource contention.

Limitation item	Description
Mutual exclusivity with Cluster Autoscaler (CA)	You cannot enable both node amplification and autoscaling for the same node pool. Amplified allocatable resources may mislead CA about actual node capacity. This will cause incorrect scale-in decisions or delayed scale‑up. Amplified node pools and CA node pools must be separated.
Hard upper limit on amplification ratio	Default limits: CPU ≤ 3.0 and Memory ≤ 2.0. Any configuration exceeding these limits will be rejected by the system and will not take effect. We recommended setting the initial value of CPU to 1.5 to 2.0 and memory to 1.2 to 1.5. Then, gradually increase the value after observation.
GPU resource amplification not supported	Only CPU and memory can be amplified. GPU, NPU, and other accelerator resources cannot be amplified.
Nodes with cpuManagerPolicy: static (exclusive‑core nodes)	On nodes with cpuManagerPolicy: static enabled, only the shared CPU pool is amplified. CPU and memory resources of exclusive‑core Pods are excluded from amplification calculation.
Kubelet restart risk	When katalyst is uninstalled or the amplification ratio is lowered, scheduled Pods are unaffected. However, if kubelet restarts, Pod eviction may occur because the sum of Pod requests may exceed the current node capacity.
One NOC per node pool	When multiple NOCs match the same node pool, only the most recently created NOC takes effect.

Procedure

Step 1: Add an amplification label to the target node pool

Log in to the VKE console.

On the left navigation bar, select Cluster, and click the name of the target cluster.

In the left navigation bar of the cluster management page, click Nodes > Node pool.

On the Node pool page, find the target node pool and click Edit in the Actions column.

On the Edit node pool page, configure two node labels and select Enable auto renew for node labels and taints in the Advanced configurations section in the Node pool configuration step.

Label 1:

Label key: katalyst.kubewharf.io/overcommit_node_pool

Label value: the node pool identifier, such as the node pool name or ID. You can specify a custom value.

Label 2:

Label key: vke.node.katalyst.deploy

Label value: true

Step 2: Issue an NOC to set the amplification ratio

Connect to the cluster through kubectl. For details, see Connecting to a cluster via kubectl.

Define an amplification policy for the node pool by issuing an NOC. The following YAML file nodeovercommit-test.yaml of NOC functions as an example.

apiVersion: overcommit.katalyst.kubewharf.io/v1alpha1
kind: NodeOvercommitConfig
metadata:
name: nodeovercommit-test # The custom amplification policy name.
labels:
vke.node.katalyst.deploy: "true" # This field has a fixed value.
spec:
nodeOvercommitSelectorVal: "test-pool" # The name of the node pool. It matches the value of katalyst.kubewharf.io/overcommit_node_pool on the node.
resourceOvercommitRatio: # The amplification factor settings.
cpu: "2"
memory: "1.5"
#
overcommitStrategyType: dynamic # Whether to dynamically adjust the amplification ratio. Valid values: dynamic (adjusts based on real-time and historical load to compute a recommended value) and static (uses the fixed amplification ratio configured above). To dynamically adjust the ratio, targetLoadThreshold must be set. The final effective amplification ratio is min(dynamic, static).
targetLoadThreshold: # The target load watermark for amplified nodes. When dynamic adjustment is enabled, idle resources are amplified based on this watermark to make the actual load on the node closer to the target.
cpu: 80
memory: 90

Run the following command to create and issue the NOC.

kubectl apply -f nodeovercommit-test.yaml

Step 3: (Optional) Enable the load-aware scheduling policy

To address the scheduling priority issue between non‑amplified and amplified nodes within the same node pool, you can combine load‑aware scheduling with NodeSchedulingConfig objects.

When a node does not match any NodeSchedulingConfig, the global configuration is used. If a matching custom resource exists, its configuration takes precedence.

When a node matches multiple NodeSchedulingConfigs, the most recently created one takes effect.

On the configuration page of the load‑aware scheduling add-on (scheduler‑plugin add-on), configure the global node resource utilization threshold. For more details, see Load‑aware scheduling.

Specify a custom resource utilization threshold for the corresponding node pool by applying a NodeSchedulingConfig. The following YAML file nodeschedulingconfig-test.yaml functions as an example.

apiVersion: scheduling.vke.volcengine.com/v1beta1
kind: NodeSchedulingConfig
metadata:
name: nodeschedulingconfig-test # The custom NodeSchedulingConfig name.
spec:
nodeSelector:
matchLabels:
katalyst.kubewharf.io/overcommit_node_pool: test-pool # The node selector. It defines the scope for the resource utilization threshold. For example, the scope can be the corresponding amplified node pool.
targetLoadThreshold:
cpu: 70 # The CPU resource utilization threshold. Unit: percentage.
memory: 70 # The memory resource utilization threshold. Unit: percentage.

Run the following command to issue the NodeSchedulingConfig.

kubectl apply -f nodeschedulingconfig-test.yaml

Step 4: (Optional) Enable node pressure awareness and eviction policy

When a node is amplified, it can host workloads that exceed its capacity. If the amplification ratio is too high or the actual container load exceeds expectations, the node may become overloaded. This affects overall service performance. We recommend configuring pressure awareness and eviction policies on the node via an AQC and also creating a KatalystCustomConfig (KCC) to add the labels of the node to an allowlist.

Create an AQC and configure pressure awareness and eviction. The following YAML file adminqosconfiguration-test.yaml functions as an example.

apiVersion: config.katalyst.kubewharf.io/v1alpha1
kind: AdminQoSConfiguration
metadata:
name: katalyst-config # The name of the KatalystCustomConfig object. This field has a fixed value.
namespace: katalyst-system
labels:
vke.node.katalyst.deploy: "true" # This field has a fixed value.
spec:
# The amplified node pool selector. It matches the value of the label katalyst.kubewharf.io/overcommit_node_pool on the node.
nodeLabelSelector: "katalyst.kubewharf.io/overcommit_node_pool=test-pool"
priority: 10 # It must correspond to the nodeLabelSelectorAllowedKeyList defined in the KatalystCustomConfig.
config:
evictionConfig:
cpuSystemPressureEvictionConfig:
enableCPUSystemPressureEviction: true # Enable system CPU pressure awareness and eviction policy.
usageUpperBoundRatio: 0.8 # The node CPU utilization threshold. 1 indicates 100%.
evictionWorkloadScope: declaredEvictable # When it is enabled, only Pods with the katalyst.kubewharf.io/evictable=true annotation can be evicted.
memoryPressureEvictionConfig:
evictionWorkloadScope: declaredEvictable # When it is enabled, only Pods with the katalyst.kubewharf.io/evictable=true annotation can be evicted.
enableNumaLevelEviction: true # Enable per‑NUMA memory pressure awareness and eviction policy.

Run the following command to create an AQC.

kubectl apply -f adminqosconfiguration-test.yaml

Create a KCC object to define the Group, Version, and Resource (GVR) information as well as the management behavior of the AQC. The following YAML file katalystcustomconfig-test.yaml functions as an example.

apiVersion: config.katalyst.kubewharf.io/v1alpha1
kind: KatalystCustomConfig
metadata:
name: katalyst-config # The name of the KatalystCustomConfig object. This field has a fixed value.
namespace: katalyst-system # The namespace of the KatalystCustomConfig object. This field has a fixed value.
labels:
vke.node.katalyst.deploy: "true" # The label related to the fine-grained resource management feature of node pool configuration. This field has a fixed value.
spec:
nodeLabelSelectorAllowedKeyList: # Enable AdminQoSConfiguration to add node labels to allowlists via nodeLabelSelector.
- priority: 10 # Define the priority of the following label keys when multiple adminqosconfigurations match a single node. A higher value indicates higher priority.
keyList: # Define the list of supported label keys with the corresponding priority.
- katalyst.kubewharf.io/overcommit_node_pool
targetType: # The description of the GVR information for the AdminQosConfiguration. This field has a fixed value.
group: config.katalyst.kubewharf.io
resource: adminqosconfigurations
version: v1alpha1

Run the following command to create a KCC.

kubectl apply -f katalystcustomconfig-test.yaml

After the preceding configuration is complete, the system performs pressure awareness and eviction as follows:

CPU pressure awareness and eviction policy:

CPU pressure is detected every 5 seconds. If CPU usage reaches usageUpperBoundRatio (0.8 in the example) within at least 8 out of the last 10 detection cycles, an eviction is triggered.

The cooldown period between two Pod evictions is 300 seconds. After an eviction is triggered, no other evictions will occur within 300 seconds.

When an eviction occurs, the node is tainted with node.katalyst.kubewharf.io/SystemCPU to prevent Pods from being scheduled onto the node.

DaemonSet Pods will not be evicted.

Memory pressure awareness and eviction policy per NUMA:

Reads NUMA memory watermark values (free, low, min) from /proc/zoneinfo.

If min < free < low is detected for 12 consecutive cycles (5 seconds for each cycle), a memory eviction is triggered.

When free < min is detected, the cumulative cycles are quickly increased to 11 cycles. That means that if free < low is detected in the next cycle, eviction will be triggered.

DaemonSet Pods will not be evicted.

Validate results

Check the status field of the NOC to verify the matching relationship between the node and the NOC.

kubectl get noc nodeovercommit-test -o jsonpath='{.status.matchedNodeList}'

The expected output is as follows:

If CPU and memory amplification ratios are specified for the node, view the annotations related to amplification on the corresponding node.

kubectl get node ${NODE_NAME} -o jsonpath='{.metadata.annotations}'

The expected output is as follows:

Verify whether the capacity and allocatable resources of the node have been amplified.

# View the actual resource capacity of the node
kubectl get node ${NODE_NAME} -o jsonpath='{.status.capacity}'
kubectl get node ${NODE_NAME} -o jsonpath='{.status.allocatable}'

The expected output is as follows:

Appendix

Core metrics

The following table describes core metrics related to dynamic amplification and prediction capabilities.

Controller metrics

Webhook metrics

Agent metrics

The following table describes controller metric names and their meanings.

Metric name	Type	Tag	Meaning and measurement method
noc_matched_nodes	Gauge	config_name	The number of nodes matched by each NodeOvercommitConfig.
noc_realtime_cpu_overcommit_ratio	Gauge	node	The real-time CPU amplification ratio.
noc_realtime_memory_overcommit_ratio	Gauge	node	The real‑time memory amplification ratio.
noc_predict_cpu_overcommit_ratio	Gauge	node	The predicted CPU amplification ratio.
noc_predict_memory_overcommit_ratio	Gauge	node	The predicted memory amplification ratio.

Amplified resource calculation

Symbol	Meaning	Calculation method description
A0	Allocatable resources before node amplification	A0 = Node specification - System reserved resources tip For a description of system-reserved resources, see Policy for node reserved resources.
A	Allocatable resources after node amplification	A = (A0 - O) × R
R	Amplification ratio	Static amplification ratio: Rstatic = User-defined value of resourceOvercommitRatio configured in the NOC. Dynamic amplification ratio: Rdynamic = [ Q + ( A0 × T − U ) / L ] / A0 tip The dynamic amplification ratio will not exceed the static amplification ratio.
O	Exclusive resource	Only the resources of Pods with exclusive cores are counted. This means that the kubelet parameter of the node has been configured with cpu-manager-policy=static. tip For a description of the node kubelet parameter cpu-manager-policy, see Configuring Kubelet parameters for node pools.
Q	Allocated requests on the node	The sum of CPU or memory requests of all Pods on the node (excluding resources of exclusive-core Pods).
L	Pod average load ratio	L = U ÷ Q tip To prevent the amplification factor from being too aggressive, VKE sets the following lower limits when calculating the average load ratio of Pods on a node: Memory: 1/2 CPU: 1/3
T	Target load watermark	The user-defined value of targetLoadThreshold in NOC.
U	The actual resource usage of all Pods on the node.	Resources can be calculated through the following two methods: Real‑time collection: Collects the real‑time resource usage of all Pods on the node (excluding exclusive‑core Pod resources). Historical prediction: Queries the cloud‑native observability platform for historical resource usage metrics of the workloads corresponding to Pods on the node. The default query window is 7 days. At least 1 day of metrics is required. When metrics are insufficient, the usage is estimated through (1/Rstatic × Q).

Metric name	Type	Tag	Meaning and measurement method
node_mutator_request_total	Counter	type=nodeAllocatableMutator	Total webhook requests (successful and failed requests).
node_mutator_request_fail	Counter	type=nodeAllocatableMutator	The number of failed mutate operations.
node_mutator_latency	Counter	type=nodeAllocatableMutator	The mutate latency, which is a cumulative counter. You can use the irate function to calculate the latency.

Volcengine Kubernetes Engine