This page answers common questions about virtual nodes in ACK, including cross-zone high availability, GPU support, scheduling priority, image pull behavior, and billing.
Capability overview
The following table summarizes key virtual node capabilities at a glance.
| Capability | Supported | Notes |
|---|---|---|
| Cross-zone high availability | Yes | Specify vSwitches from multiple zones in eci-profile |
| GPU resources | Yes | Via annotation (instance type) or nvidia.com/gpu field |
| Mixed scheduling with ECS instances | Yes | Configure via taints, tolerations, and affinity rules |
| Billing method-based scheduling priority | Yes | Subscription ECS → pay-as-you-go ECS → elastic container instances |
| Image pull from self-managed HTTP repository | Yes (with workaround) | Add an annotation to switch from HTTPS to HTTP |
| Billing based on actual resource usage | No | Billed by the vCPU and memory specifications set at creation |
How do I use virtual nodes to implement high availability for a service deployed across zones?
Specify multiple vSwitches from different zones in the vSwitchIds field of the eci-profile. When the cluster creates Elastic Container Instance (ECI)-based pods, it attempts to create virtual nodes in the zones associated with those vSwitches — for example, Zone A and Zone B — achieving high availability for the service.
For configuration details, see Configure an eci-profile.
Do virtual nodes support GPU resources?
Yes. There are two ways to request GPU resources for an ECI-based pod:
Add an annotation to the
metadatasection of the pod spec to specify a GPU-accelerated Elastic Compute Service (ECS) instance type.Add
nvidia.com/gputo theresourcessection to specify the number of GPUs.
After you deploy the YAML, the pod is automatically created with the specified GPU configuration.
For details, see Create pods by using GPU-accelerated instance types.
How do I prioritize ECS instances over elastic container instances for pod scheduling and prioritize elastic container instances over ECS instances for pod scale-in?
Use Kubernetes taints, tolerations, and affinity rules to control how pods are distributed between ECS instances and elastic container instances. You can configure only ECS instances or only elastic container instances for pod scheduling. You can also prioritize ECS instances over elastic container instances, so that elastic container instances are used when ECS capacity is insufficient. During scale-in, ECI-based pods are removed first.
For setup instructions, see Configure resource allocation based on ECS instances and elastic container instances.
To prioritize scheduling by billing method, configure the scheduling order as follows:
| Priority | Resource type |
|---|---|
| 1 (highest) | Subscription ECS instances |
| 2 | Pay-as-you-go ECS instances |
| 3 (lowest) | Elastic container instances |
Scale-in runs in reverse order: ECI-based pods are removed first, followed by pay-as-you-go ECS instance-based pods, then subscription ECS instance-based pods.
For billing method-based scheduling, see Configure priority-based resource scheduling.
For a comparison of all virtual node-based scheduling options, see Introduction and comparison of virtual node-based scheduling solutions.
What do I do if certificate verification fails when a virtual node pulls images from a self-managed image repository over HTTPS?
Elastic container instances pull images over HTTPS by default. If your self-managed image repository uses HTTP, certificate verification fails and the pull is rejected.
To fix this, add annotations to the elastic container instance to switch the image pull protocol to HTTP. For the annotation details, see Pull an image from a self-managed image repository.
After I create an ECI-based pod by specifying the number of vCPUs and memory size, is the pod billed based on the resource specification or the actual resource usage?
The pod is billed based on the vCPU and memory specifications you set at creation time, not actual usage. If the specifications you request are not supported by Elastic Container Instance, the system automatically adjusts them and bills you based on the adjusted specifications.
For pricing details, see Billing of elastic container instances.