Schedule pods to an x86-based virtual node - Elastic Container Instance

In ACK clusters that mix Elastic Compute Service (ECS) real nodes with Elastic Container Instance (ECI) virtual nodes, pods are scheduled to real nodes by default. To run specific pods on ECI, label those pods or their namespace to redirect them to the x86-based virtual node.

Note

ACK Serverless clusters run all pods on virtual nodes automatically — no scheduling configuration is needed. By default, the virtual nodes are x86 architecture. The methods in this topic apply only to ACK clusters with both real nodes and virtual nodes.

Prerequisites

Before you begin, ensure that you have:

An ACK cluster with at least one x86-based virtual node (ECI) registered
kubectl configured with access to the cluster

Choose a scheduling method

Select a method based on how many pods you want to redirect to ECI:

Scenario	Method	Recommended
Run a few specific pods on ECI	Add a label to each pod	Yes
Run all pods in a namespace on ECI	Add a label to the namespace	Yes
Use node affinity or a fixed node name	Configure `nodeSelector`/`tolerations` or `nodeName`	No

Important

For automatic, policy-based scheduling without modifying individual resources, configure an eci-profile instead. An eci-profile matches pods by label and schedules them to ECI automatically.

Usage notes

All methods require modifying existing resources and may introduce security vulnerabilities. Review your changes carefully before applying them.
If you use pod labels, namespace labels, or nodeName to schedule pods, the provisioner does not support the WaitForFirstConsumer binding mode for dynamically provisioned disk volumes. For details, see Use a dynamically provisioned disk volume.

Method 1: Add a pod label

Add the alibabacloud.com/eci=true label directly to a pod spec to schedule that pod to the x86-based virtual node. Use this method when you want to target individual pods.

Note

The eci=true label also works, but it is deprecated. Use alibabacloud.com/eci=true instead.

Create a pod manifest with the label:

apiVersion: v1
kind: Pod
metadata:
  name: nginx1
  labels:
    alibabacloud.com/eci: "true"   # Schedules this pod to the virtual node
spec:
  containers:
  - image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
    imagePullPolicy: Always
    name: nginx

Apply the manifest:
```
kubectl create -f test-pod.yaml
```

Method 2: Add a namespace label

Label a namespace with alibabacloud.com/eci=true to schedule all pods in that namespace to the x86-based virtual node. Use this method when you want every pod in a dedicated namespace to run on ECI.

Note

The virtual-node-affinity-injection=enabled namespace label also works, but it is deprecated. Use alibabacloud.com/eci=true instead.

Create a namespace:
```
kubectl create ns vk
```

Label the namespace:

kubectl label namespace vk alibabacloud.com/eci=true

Create a pod manifest that targets the labeled namespace:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: vk   # Pods in this namespace are automatically scheduled to the virtual node
spec:
  containers:
  - image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
    imagePullPolicy: Always
    name: nginx

Apply the manifest:
```
kubectl create -f test-pod.yaml
```

Method 3: Use nodeSelector, tolerations, or nodeName (not recommended)

These methods rely on low-level Kubernetes scheduling primitives — node affinity labels, taints, and explicit node names. They are error-prone, tightly coupled to node naming conventions, and harder to maintain than label-based scheduling. Use them only when the label-based methods above do not meet your requirements.

By default, x86-based virtual nodes have the label type: virtual-kubelet and a taint with the key virtual-kubelet.io/provider. To schedule a pod to one of these nodes, configure your pod spec to match that label and tolerate that taint.

Create a pod manifest using one of the following approaches:

Option A: nodeSelector and tolerations

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
    imagePullPolicy: Always
    name: nginx
  nodeSelector:
    type: virtual-kubelet          # Targets nodes with this label
  tolerations:
  - key: virtual-kubelet.io/provider
    operator: Exists               # Tolerates the default taint on virtual nodes

Option B: nodeName

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
    imagePullPolicy: Always
    name: nginx
  nodeName: virtual-kubelet-cn-beijing-g   # Targets a specific virtual node by name

Apply the manifest:

kubectl create -f test-pod.yaml

What's next

Configure an eci-profile — Set up automatic pod scheduling without modifying individual resources.
Use a dynamically provisioned disk volume — Understand storage limitations when pods run on virtual nodes.