Unlocking Serverless Elastic Scaling: ElasticWorkload, WorkloadSpread, UnitedDeployment & ResourcePolicy Explained

ElasticWorkload

ElasticWorkload is an early ACK plugin that clones a native workload (e.g., Deployment) into multiple elastic units. Each elastic unit defines a label selector, a minimum/maximum replica count, and optional extra scheduling constraints. The controller watches the source workload, creates a separate workload for each unit, and distributes the total replica count according to the unit order: forward expansion fills earlier units first, while reverse contraction removes replicas from later units first.

apiVersion: autoscaling.alibabacloud.com/v1beta1
kind: ElasticWorkload
metadata:
  name: elasticworkload-sample
spec:
  sourceTarget:
    name: nginx-deployment-basic
    kind: Deployment
    apiVersion: apps/v1
  replicas: 6
  elasticUnit:
  - name: ecs               # first 5 pods → ECS nodes
    labels:
      alibabacloud.com/acs: "false"
    max: 5
  - name: acs               # remaining pods → ACS virtual nodes
    labels:
      alibabacloud.com/acs: "true"

Typical elastic scenarios include:

When ECS capacity is exhausted, new pods are scheduled to Virtual Kubelet (ACS) nodes.

In hybrid clouds, failed IDC pods are migrated to public cloud.

Static pool handles baseline load; Spot or ACS handles burst load.

WorkloadSpread

WorkloadSpread is an OpenKruise component that intercepts pod‑creation requests via a mutating webhook and patches the pod according to a Subset definition. Each subset specifies a maximum replica count, node‑selection criteria, and an optional patch that can modify any pod field (labels, resources, env, etc.). Two scheduling strategies are supported:

Fixed : Pods are forced into the defined subset even if scheduling fails.

Adaptive : If a subset cannot schedule a pod, the controller retries the pod in another subset.

apiVersion: apps.kruise.io/v1alpha1
kind: WorkloadSpread
metadata:
  name: workloadspread-demo
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: workload-xxx
  subsets:
  - name: subset-a
    maxReplicas: 3
    requiredNodeSelectorTerm:
      matchExpressions:
      - key: topology.kubernetes.io/zone
        operator: In
        values:
        - zone-a
    patch:
      metadata:
        labels:
          xxx-specific-label: xxx
  - name: subset-b
    requiredNodeSelectorTerm:
      matchExpressions:
      - key: topology.kubernetes.io/zone
        operator: In
        values:
        - acs-cn-hangzhou
  scheduleStrategy:
    type: Adaptive
    adaptive:
      rescheduleCriticalSeconds: 30

Patch examples:

# add a topology label to all pods in the subset
patch:
  metadata:
    labels:
      topology.application.deploy/zone: "zone-a"

# increase container resources
patch:
  spec:
    containers:
    - name: main
      resources:
        limits:
          cpu: "2"
          memory: 800Mi

# set an environment variable
patch:
  spec:
    containers:
    - name: main
      env:
      - name: K8S_AZ_NAME
        value: zone-a

UnitedDeployment

UnitedDeployment (OpenKruise) provides a native, one‑resource solution for partitioned elastic workloads. The resource contains a template (usually a CloneSet or Deployment) and a topology that defines multiple subsets . For each subset the controller creates a secondary workload that inherits the template and applies subset‑specific node selectors, replica limits, and pod patches. UnitedDeployment therefore manages the full lifecycle—creation, scaling, upgrade—of all secondary workloads.

apiVersion: apps.kruise.io/v1alpha1
kind: UnitedDeployment
metadata:
  name: sample-ud
spec:
  replicas: 6
  selector:
    matchLabels:
      app: sample
  template:
    cloneSetTemplate:
      metadata:
        labels:
          app: sample
      spec:
        # CloneSet spec omitted for brevity
  topology:
    subsets:
    - name: ecs
      nodeSelectorTerm:
        matchExpressions:
        - key: node
          operator: In
          values:
          - ecs
      maxReplicas: 2
    - name: acs-serverless
      nodeSelectorTerm:
        matchExpressions:
        - key: node
          operator: In
          values:
          - acs-virtual-kubelet

Key capabilities:

One‑stop management : a single CR defines application, partitioning, capacity, scaling, and upgrade.

Fine‑grained partition configuration : each subset can have its own replica limits (elastic or fixed) and arbitrary pod patch fields.

Adaptive elasticity : supports HPA and can reschedule pending pods to other subsets when a subset becomes unschedulable.

UnitedDeployment uses a three‑level model: the UnitedDeployment object, secondary workloads (e.g., CloneSets), and the actual Pods managed by those secondary workloads.

ResourcePolicy

ResourcePolicy is a native ACK scheduler extension that defines a prioritized list of Units (resource pools such as ECS, ECI, or ACS). Pods matching the selector are scheduled into the first unit that has capacity; on scale‑down the order is reversed. The policy can fine‑tune pre‑emptive behavior and pod counting via flags like ignorePreviousPod and ignoreTerminatingPod. Several adaptive strategies control how the scheduler falls back to the next unit when the current one is full or times out.

apiVersion: scheduling.alibabacloud.com/v1alpha1
kind: ResourcePolicy
metadata:
  name: test
  namespace: default
spec:
  ignorePreviousPod: false
  ignoreTerminatingPod: true
  matchLabelKeys:
  - pod-template-hash
  preemptPolicy: AfterAllUnits
  selector:
    app: my-app
  strategy: prefer
  units:
  - nodeSelector:
      unit: first
    resource: ecs
    max: 4
  - resource: eci
  whenTryNextUnits:
    policy: TimeoutOrExceedMax
    timeout: 1m

Supported adaptive policies:

ExceedMax : if a unit’s max is reached, schedule to the next unit.

TimeoutOrExceedMax : wait up to timeout for resources; on timeout or max‑exceed, move to next unit.

LackResourceOrExceedMax (default): fall back when resources are insufficient or max is exceeded.

LackResourceAndNoTerminating : fall back only when no terminating pods exist in the current unit (useful for rolling updates).

Comparison & Typical Use Cases

All four components address the need for “flexible, minimally invasive elastic scheduling” in serverless‑style workloads. Choosing the right tool depends on the operational constraints:

ElasticWorkload – suitable for legacy ACK clusters (K8s ≤1.18) where a dedicated CR is acceptable and direct control over the source workload’s replica count is desired.

WorkloadSpread – ideal when you cannot modify the original workload object; it adds elasticity via a webhook and supports rich per‑subset pod patches.

UnitedDeployment – best for new applications that can adopt a unified CR; provides one‑stop lifecycle management and advanced partitioning, at the cost of migrating existing workloads.

ResourcePolicy – the least invasive option for ACK‑only clusters; it leverages the native scheduler, requires no extra controllers, but offers limited pod‑level customization.

Representative scenarios:

Hybrid‑cloud burst: primary traffic runs on on‑prem or ECS nodes; excess load is automatically placed on ACS virtual nodes.

Multi‑architecture deployment: different subsets target X86, ARM, or GPU nodes with tailored resource requests.

Sidecar injection for serverless nodes: combine SidecarSet with WorkloadSpread to add acceleration components only to ACS pods.

Low‑frequency spikes: use ResourcePolicy to keep a fixed number of stable ECS pods and scale out to ACS only when needed, avoiding the overhead of installing OpenKruise.

Summary Table (core fields)

The following matrix (textual) highlights the main differences:

Component          | Config Complexity | Native ACK Support | Partition Granularity | Pod‑Level Patch | Adaptive Scheduling
-------------------|-------------------|--------------------|----------------------|----------------|---------------------
ElasticWorkload   | Low (single CR)   | Yes (deprecated)   | ElasticUnit          | No             | Yes (forward/reverse)
WorkloadSpread    | Medium (Webhook)  | No                 | Subset               | Yes            | Yes (Fixed/Adaptive)
UnitedDeployment  | Medium (UD CR)    | No                 | Subset (UD topology) | Yes            | Yes (Adaptive + HPA)
ResourcePolicy    | Low (policy CR)   | Yes (native)        | Unit (resource pool) | No             | Yes (preempt & strategies)

By aligning the workload characteristics with the capabilities above, users can achieve cost‑effective, on‑demand elasticity for serverless‑style applications on Alibaba Cloud ACK.