All Products
Search
Document Center

Container Service for Kubernetes:Serverless elasticity in virtual nodes

Last Updated:Sep 16, 2026

Virtual nodes let you schedule pods directly to Elastic Container Instance (ECI) without provisioning or maintaining node pools. This page explains how virtual nodes work, when to use them, and what their limitations are.

Why use virtual nodes

What are virtual nodes

In ACK clusters, nodes are the basic units that provide computing and storage resources for running workloads. Most ACK clusters have at least one ECS node pool. When a pod is created, the kubelet schedules it to an ECS node in the node pool. This scheduling mode is ideal for applications with stable traffic. However, this mode struggles with traffic spikes because creating and starting ECS instances is time-consuming. Virtual nodes allow you to schedule pods directly on Alibaba Cloud Elastic Container Instance (ECI), which reduces the operational burden of node management and lowers costs by avoiding idle node resources.

image
Important

Compared with ECS nodes, virtual nodes do not support custom labels, annotations, or taints.

A virtual node uses the ack-virtual-node component to encapsulate computing resources, which lets you deploy workloads without managing the underlying infrastructure. The component automatically schedules application pods to run on ECI. ECI is a serverless container service where each ECI instance is equivalent to a pod. When you use ECI to deploy containerized applications, you provide a container image and pay only for the resources that your containers consume.

Benefits

Virtual nodes provide the following benefits.

  • Fully managed: You do not need to create underlying resource pools, which reduces the O&M workload. Virtual nodes are managed resources and do not require routine O&M operations for Kubernetes nodes, such as system upgrades or security patch installations.

  • Large capacity: You can scale out to a maximum of 50,000 pods without capacity planning.

    Important

    If many pods are associated with services, we recommend that you keep the number of pods within 20,000.

  • Elasticity in seconds: You can create thousands of pods in a short time. This prevents pod creation latency from affecting services during traffic spikes.

  • Secure isolation: Pods are created based on ECI. Each container instance is strongly isolated from others using lightweight sandboxed container technology.

  • Cost-effective: Applications are created on demand and billed on a pay-as-you-go basis. You are not charged for idle resources. The serverless architecture also reduces O&M costs.

Scenarios

Virtual nodes are suitable for the following scenarios.

  • Online services

    For online services that experience frequent traffic spikes, such as online education and e-commerce, virtual nodes support scaling in seconds. This prevents system failures caused by slow scale-outs during traffic surges and avoids resource waste from idle resources.

  • Data processing

    For processing many concurrent online data tasks, such as Spark and Presto tasks, the concurrency is no longer limited by the cost of underlying resources. You can quickly scale out to thousands of pods to meet the requirements of big data processing.

  • AI tasks

    For AI tasks such as model training and model inference, which do not run continuously but require significant computing resources, you do not need to reserve resources. Instead, use resources on demand and pay by the second to reduce AI inference costs. Additionally, second-level elasticity lets you quickly respond to burst workloads.

  • CI/CD staging environments

    For batch testing tasks in the CI/CD process, such as CI packaging, stress testing, and simulation testing, you can use virtual nodes to create and release container instances at any time. You can use resources on demand and are charged on a per-second basis. This approach provides large-scale resources at a low cost.

  • Jobs and CronJobs

    Jobs and CronJobs do not need to run continuously. After a job is complete, it stops, and the corresponding pod is deleted. With virtual nodes, billing stops and computing resources are released automatically when the job is complete. This avoids resource waste from idle resources.

Limitations

Before using virtual nodes, check that your workloads are compatible.

Capability

Supported

Notes

DaemonSets

No

Use sidecar containers instead.

HostPath volumes in pod manifests

No

HostNetwork in pod manifests

No

Privileged containers

No

Use a security context to add capabilities to a pod. The privileged container feature is in internal preview — submit a ticket to request access.

NodePort Services

No

Session affinity

No

China South Finance region

No

Alibaba Gov Cloud region

No

ARM-based virtual nodes

Yes

Windows virtual nodes

Yes

In invitational preview.

Billing

Virtual nodes are free of charge. ECI pods that run on virtual nodes are billed based on the billing rules of ECI. For more information, see ECI billing overview.

Note

ECI pods use the pay-as-you-go billing method. Billing starts when an ECI pod enters the Pending state and stops when the pod enters the Succeeded or Failed state. For more information, see ECI pod lifecycle.

Quick start

For information about how to use virtual nodes, see Schedule pods to run on ECI.

What's next

Before upgrading your cluster, make sure your ECI platform version is compatible with the target Kubernetes version. If incompatible ECI-based pods exist, delete and recreate them before upgrading. For details, see Update Elastic Container Instance platform version.

Task

Description

Reference

Configure pods in bulk

Create an eci-profile ConfigMap to configure security groups and zones for ECI-based pods. Changes apply immediately to new pods and after a rolling update for existing pods.

Configure an eci-profile

Customize pod behavior with annotations

Use pod annotations to specify ECI instance types, enable image cache, assign IPv6 addresses, or expand temporary storage.

ECI pod annotations

Choose a scheduling policy

Schedule pods exclusively to virtual nodes, fall back to virtual nodes when ECS resources are unavailable, or mix ECS and ECI scheduling.

Schedule a pod to a virtual node

Enable virtual node scheduling for a cluster

Configure the cluster-level scheduling policy to route pods to virtual nodes.

Enable the virtual node-based pod scheduling policy for an ACK cluster

Schedule pods to ECI

Follow a step-by-step guide to schedule pods to elastic container instances.

Schedule pods to elastic container instances

Use ACS computing power

Access ACS computing power through an ACK managed cluster Pro edition.

Use ACS computing power through ACK managed cluster Pro edition

Mix ECS and ECI resource allocation

Configure scheduling to split workloads across ECS instances and elastic container instances.

Configure resource allocation based on ECS instances and elastic container instances

Spread pods across zones

Configure zone affinity for ECI-based pods to improve availability.

Spread Elastic Container Instance-based pods across zones and configure affinities

Use ARM-based virtual nodes

By default, ACK clusters schedule workload pods to x86-based virtual nodes. Pods become pending when x86 nodes are insufficient. Schedule workloads to ARM-based virtual nodes to handle these cases.

Schedule workloads to ARM-based virtual nodes

Use Windows virtual nodes

Add Windows virtual nodes to the cluster and schedule pods to them.

(In invitational preview) Schedule pods to run on Windows virtual nodes

Run Jobs on virtual nodes

Handle peak compute demand by running Jobs on virtual nodes without creating new nodes.

Use an elastic container instance to run a Job

Run Spark jobs on ECI

Configure scheduling policies to run Spark workloads on ECI and pay only for resources used.

Use elastic container instances to run Spark jobs

Inject sidecar containers

Use the ACK Virtual Node component to automatically inject sidecar containers into pods on virtual nodes.

Inject sidecar containers into pods on virtual nodes

Monitor virtual nodes

Modify Prometheus monitoring configurations to collect metrics from specific virtual nodes.

Collect the metrics of the specified virtual node

Configure service discovery

Enable service discovery (intranet, headless, and ClusterIP services) on virtual nodes using Alibaba Cloud DNS PrivateZone.

Service discovery on virtual nodes based on Alibaba Cloud DNS PrivateZone

Review FAQs

Find answers to common questions about virtual nodes.

FAQs about virtual nodes