All Products
Search

This Product

    Container Service for Kubernetes:Use elastic resources to implement Elastic Container Instance-based scheduling (discontinued)

    Document Center

    Container Service for Kubernetes:Use elastic resources to implement Elastic Container Instance-based scheduling (discontinued)

    Last Updated:Mar 26, 2026
    Important

    Kubernetes versions 1.18 to 1.24 retain the elastic scheduling capability in Elastic Container Instance (ECI). Since May 2023, Container Service for Kubernetes (ACK) has discontinued maintenance of this feature for clusters running Kubernetes v1.24 or later. Use one of the following alternatives instead:

    For a comparison of virtual node scheduling solutions, see Schedule a pod to a virtual node.

    Elastic Container Instance-based scheduling lets you control which compute backend runs your pods by adding a single annotation to pod metadata. Depending on the annotation value, pods run exclusively on Elastic Compute Service (ECS) nodes, exclusively on elastic container instances, or on elastic container instances only when ECS capacity in the cluster is exhausted.

    Prerequisites

    Before you begin, ensure that you have:

    • An ACK managed Pro cluster

    • A supported scheduler version for your Kubernetes version: For details on scheduler versions, see kube-scheduler.

      Kubernetes version Minimum scheduler version
      1.18 v1.18-ack-3.0
      1.20 v1.20.4-ack-4.0
      1.22 v1.22.3-ack-1.0
      1.24 v1.24.3-ack-2.0

    • The ack-virtual-node component deployed in the cluster. For setup instructions, see Schedule pods to elastic container instances through virtual nodes.

    Configure the scheduling mode

    Add the alibabacloud.com/burst-resource annotation to the pod's metadata section. For a Deployment, place the annotation under spec.template.metadata.

    The following table summarizes how each annotation value affects scheduling behavior:

    Annotation value Scheduling behavior Requires virtual node Fails if
    *(not set)* Uses only existing ECS nodes in the cluster (default) No —
    eci Uses ECS nodes first; falls back to ECI when ECS capacity is insufficient — —
    eci_only Uses only ECI; ECS nodes are never used Yes No virtual node exists in the cluster
    Any other value — — Always fails; invalid value
    Important

    alibabacloud.com/burst-resource: eci conflicts with alibabacloud.com/fluid-sidecar-target: eci. For usage examples of alibabacloud.com/fluid-sidecar-target, see Accelerate data access in serverless cloud computing and related topics.

    Apply the annotation

    1. Create a file named nginx-deployment.yaml with the following content:

      apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      annotations:
        alibabacloud.com/burst-resource: eci  # Fall back to ECI when ECS capacity is insufficient
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

    2. Apply the manifest:

      kubectl apply -f nginx-deployment.yaml

    Failure scenarios

    Pod scheduling fails in the following situations:

    • The annotation value is not eci or eci_only. The PodStatus message is requesttypemustbeeci,eci_onlyorecs (Kubernetes v1.22.15 and v1.24.6).

    • The annotation value is eci_only but no virtual node exists in the cluster. The PodStatus message is doesn'tfitecitype:eci_only (Kubernetes v1.22.15 and v1.24.6).

    What's next