ElasticWorkload, WorkloadSpread, UnitedDeployment, and ResourcePolicy: Configurable Plugins for Serverless Elasticity in Alibaba Cloud Container Service

Serverless extends cloud computing by providing on‑demand elastic scaling, allowing developers to focus on application logic without managing underlying resources. As enterprises adopt Serverless, Alibaba Cloud Container Service (ACK) offers four configurable plugins—ElasticWorkload, WorkloadSpread, UnitedDeployment, and ResourcePolicy—to address capacity planning and elastic workload distribution challenges.

Elastic Scenario Overview

Typical elastic scenarios include preferring on‑premise IDC resources, falling back to ECS pools, using spot instances after dedicated resources are exhausted, and configuring different resource amounts for workloads running on various architectures (x86, ARM, ACS Serverless). The four plugins each solve these problems with distinct strengths.

1. ElasticWorkload

ElasticWorkload, an early ACK plugin (now deprecated), clones a base workload into multiple replicas with independent scheduling policies, using “elastic units” as the smallest control unit. It supports HPA and enables fine‑grained partitioned scaling. Example definition:

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
    labels:
      alibabacloud.com/acs: "false"
    max: 5
  - name: acs
    labels:
      alibabacloud.com/acs: "true"

It allocates replicas to elastic units in order, expanding forward and shrinking backward, ensuring stable instances handle normal traffic while elastic instances serve spikes.

2. WorkloadSpread

Provided by the OpenKruise community, WorkloadSpread intercepts Pod creation via a webhook and patches Pods based on defined Subsets, allowing custom labels, resources, environment variables, etc., without modifying the original workload. It supports Job, CloneSet, Deployment, ReplicaSet, and StatefulSet. Example:

apiVersion: apps.kruise.io/v1alpha1
kind: WorkloadSpread
metadata:
  name: workloadspread-demo
spec:
  targetRef:
    apiVersion: apps/v1 | apps.kruise.io/v1alpha1
    kind: Deployment | CloneSet
    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 | Fixed
    adaptive:
      rescheduleCriticalSeconds: 30

It follows forward expansion and reverse contraction across Subsets, offering both Fixed and Adaptive scheduling strategies.

3. UnitedDeployment

UnitedDeployment is a native OpenKruise workload that manages partitioned applications in a single resource. It defines a template workload and creates secondary workloads (e.g., CloneSet) for each partition, handling replica distribution, upgrades, and HPA automatically. Example:

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 ...
  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

It provides one‑stop management, adaptive scaling, and three‑level workload hierarchy (UnitedDeployment → secondary workload → Pods), simplifying complex elastic deployments.

4. ResourcePolicy

ResourcePolicy is a native ACK scheduler capability that defines ordered units (e.g., ECS, ECI, ACS) with capacity limits and pre‑empt policies, enabling fine‑grained, priority‑based pod placement without additional components. Example:

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

It supports various adaptive policies (ExceedMax, TimeoutOrExceedMax, LackResourceOrExceedMax, LackResourceAndNoTerminating) and integrates tightly with ACK features such as node pools.

Customer Cases

Multiple real‑world cases illustrate how each plugin solves specific needs: using WorkloadSpread to allocate bandwidth packages for load‑testing agents, combining SidecarSet with WorkloadSpread for hybrid on‑premise/cloud acceleration, leveraging UnitedDeployment for adaptive scaling between ECS and ACS, and applying ResourcePolicy for low‑frequency burst traffic without extra operational overhead.

Conclusion

Elastic resources dramatically reduce costs and raise performance ceilings. Selecting the appropriate plugin—ElasticWorkload, WorkloadSpread, UnitedDeployment, or ResourcePolicy—depends on factors such as existing workload types, desired level of integration, and operational complexity. The article’s comparison table (not reproduced here) summarizes each component’s strengths and trade‑offs.