Resolve common virtual node issues, including cross-zone high availability, GPU resources, scheduling priorities, image pulls, and billing.
Index
Capability overview
Key virtual node capabilities at a glance.
Capability | Supported | Notes |
Cross-zone high availability | Yes | Specify vSwitches from multiple zones in |
GPU resources | Yes | Via annotation (instance type) or |
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 vSwitches from multiple zones in the vSwitchIds field of the eci-profile. The cluster creates virtual nodes in the corresponding zones, such as Zone A and Zone B, to achieve cross-zone high availability for ECI pods. We recommend that you configure vSwitches from multiple zones to ensure high availability.
Do virtual nodes support GPU resources?
Yes. You can request GPU resources for an ECI-based pod in the following ways:
Add an annotation to the pod
metadatato specify a GPU-accelerated ECS instance type.Add
nvidia.com/gputoresourcesto specify the GPU count.
After you deploy the workload YAML file, the cluster automatically creates an ECI pod with the specified GPU configuration.
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 taints, tolerations, and affinity rules to control pod distribution between ECS and elastic container instances. Schedule pods to ECS only, elastic container instances only, or prioritize ECS so elastic container instances handle overflow. During scale-in, ECI-based pods are removed first.
See Configure resource allocation based on ECS instances and elastic container instances.
Scheduling priority by billing method:
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.
See Configure priority-based resource scheduling.
Compare scheduling options in Introduction and comparison of virtual node-based scheduling solutions.
What do I do if a virtual node fails to pull images from a self-managed image repository because of an HTTPS authentication error?
Elastic container instances pull images over HTTPS by default. If your self-managed image repository uses HTTP, the protocol mismatch causes image pulls to fail.
To fix this, add annotations to the elastic container instance to switch to HTTP. 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.