Container Service for Kubernetes:Virtual node scheduling solutions for ACK clusters

Common virtual node scheduling scenarios

1. Schedule pods only to virtual nodes.

2. Prioritize ECS nodes and fall back to virtual nodes when ECS resources are insufficient.

For an ACK managed cluster (Basic Edition), use the label alibabacloud.com/eci=true for the first scenario. For the second, upgrade to an ACK managed cluster (Pro Edition).

Usage notes

• The label alibabacloud.com/eci=true has the highest priority and overrides these scheduling methods:

  • Kubernetes native scheduling semantics, such as nodeSelector, affinity and anti-affinity, and pod topology spread constraints

  • ResourcePolicy

  • ElasticResource (Annotation: alibabacloud.com/burst-resource)

• ElasticWorkload and ElasticResource (Annotation: alibabacloud.com/burst-resource) are not recommended because they are in an inactive development state.

• The virtual-kubelet-autoscaler component is no longer maintained. Upgrade your ACK managed cluster (Basic Edition) to an ACK managed cluster (Pro Edition) and uninstall this component to free node resources. Use Kubernetes native scheduling semantics to implement spread deployment and affinity-based scheduling for ECI pods across zones.

• For pods on virtual nodes that use dynamically provisioned disk volumes, WaitForFirstConsumer-type StorageClasses are not supported with these scheduling methods:

  • Using labels: alibabacloud.com/eci=true.

  • Specifying a virtual node with nodeName.

Solution comparison and suggestions on how to select solutions

The following terms are used in the comparison tables:

• Priority-based scheduling: When a cluster has different node types, configure the scheduling priority. For example, prioritize ECS nodes and fall back to virtual nodes when ECS resources are insufficient.

  Without priority-based scheduling, you cannot assign priorities across node types. For example, the alibabacloud.com/eci=true label schedules pods only to virtual nodes without ECS-first fallback.

• Strict scheduling policy: Determines whether scheduling rules for different node pool types are hard constraints.

  • A non-strict policy is a soft constraint. For example, the preferredDuringSchedulingIgnoredDuringExecution field of node affinity prioritizes ECS nodes, but pods may still land on virtual nodes due to the node scoring policy.

  • A strict policy is a hard constraint. For example, ResourcePolicy ensures pods are scheduled to ECS nodes when sufficient resources are available.