Skip to main content

Autoscaling

WorkloadDeployment exposes the Kubernetes /scale subresource, so a stock HorizontalPodAutoscaler (HPA) or KEDA ScaledObject can target it directly. That covers HTTP workloads too: an HTTPTrigger routes to a WorkloadDeployment, and the WorkloadDeployment is what you scale.

Changed in v0.13.0

From v0.6.0 through v0.12.x, HTTPTrigger also exposed /scale, because it carried the workload's replicas. The control.cosmonic.io/v1alpha2 HTTPTrigger in v0.13.0 has no replicas and no /scale subresource. Point any scaleTargetRef that names an HTTPTrigger at its WorkloadDeployment; see Upgrading from v0.12.2 to v0.13.0.

Jeremy Fleitz walks through the design and a working demo of WorkloadDeployment autoscaling on the wasmCloud community call:

Targeting a WorkloadDeployment​

HPA reads the live replica count and selector from the WorkloadDeployment's /scale subresource and writes back to spec.replicas. For an HTTP workload, target the WorkloadDeployment named in the trigger's backendRefs:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hello-world
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: runtime.wasmcloud.dev/v1alpha1
    kind: WorkloadDeployment
    name: hello-world
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: External
      external:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: '10'

The same manifest works for non-HTTP workloads, which have no trigger at all.

Don't set spec.replicas on a WorkloadDeployment that an HPA already manages. Pick one source of truth so a re-apply and the autoscaler don't fight over the field. The http-trigger chart always renders replicas (default 1), so a helm upgrade of a chart-installed workload resets the count until the autoscaler acts again.

When a trigger splits traffic across several WorkloadDeployments by weight, each one scales on its own. Give each its own autoscaler if they should all follow load.

Mechanics, metric sources, and KEDA​

The /scale subresource on WorkloadDeployment is the same one that backs kubectl scale, HPA, and KEDA. The upstream wasmCloud Autoscaling guide covers the mechanics in full, including:

  • Why HPA's built-in Resource (CPU/memory) and Pods metric types don't apply to Wasm workloads, and how to use External or Object metrics via the Prometheus Adapter instead.
  • The host group as a precondition: HPA holds at host-group capacity, not at maxReplicas.
  • A worked KEDA ScaledObject example that scales on a Prometheus query of metrics emitted by the workload itself.
  • The runtime.wasmcloud.dev/workload-deployment selector label.
  • Scale-to-zero, cold-start, and other cases where autoscaling is not the right answer.

Everything in the upstream guide applies to the WorkloadDeployment behind an HTTPTrigger unchanged.

Autoscaling changes replicas, the number of workload copies across the host group. That is one of three scaling axes. The other two, how many calls a single instance serves concurrently and how many connections a workload may hold, are set on the component and the host rather than by a scaler. See Concurrency and connections for how to tune them and size them together.

Last updated on by github-actions[bot]