Kubernetes Scale Target Management

Kubernetes Scale Target Management is the practice of correctly identifying, configuring, and maintaining the reference between an autoscaler and the specific workload controller it adjusts — the scaleTargetRef in an HPA or VPA, and the node group configuration referenced by the Cluster Autoscaler — ensuring the autoscaler is actually attached to the controller whose replica count or resource allocation it is intended to manage.

The scaleTargetRef Field

Identifying the Target Precisely

An HPA or VPA's scaleTargetRef specifies the API version, kind, and name of the controller it manages, and the referenced controller must implement the scale subresource for the HPA to actually adjust its replica count — Deployment, ReplicaSet, StatefulSet, and custom resources implementing the scale subresource are all valid targets, while a bare Pod is not, since pods have no replica count to scale.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-service
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 2
  maxReplicas: 10

The scale Subresource

Any resource an HPA targets must expose a /scale subresource returning and accepting a standard Scale object with a replicas field; custom resources intending to be horizontally scaled need explicit support for this subresource defined in their CustomResourceDefinition, which is a common oversight when building operators expected to interoperate with HPA.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
spec:
  versions:
  - name: v1
    subresources:
      scale:
        specReplicasPath: .spec.replicas
        statusReplicasPath: .status.replicas

One Target, One Autoscaler

Avoiding Multiple HPAs on the Same Target

Kubernetes does not prevent creating more than one HPA referencing the same scaleTargetRef, but doing so produces undefined, conflicting behavior as both controllers independently attempt to set the same underlying replica count; scale target management includes ensuring exactly one HPA governs any given controller.

Reconciling HPA and Manual Replica Changes

Once an HPA is attached to a target, manually setting spec.replicas on the underlying Deployment (through kubectl scale, for instance) is immediately overwritten by the HPA's next reconciliation, since the HPA continuously drives the replica count toward its own calculated value — manual scaling of an HPA-managed workload should go through adjusting minReplicas/maxReplicas or temporarily disabling the HPA, not direct replica edits.

kubectl scale deployment api-service --replicas=1
# Overwritten within the HPA's next sync period

VPA Target Considerations

VPA and HPA on the Same Target

Configuring both a VPA and an HPA against the same target using overlapping resource metrics (CPU, for example) is explicitly discouraged, since VPA resizing a pod's resource requests can alter the CPU utilization percentage the HPA is simultaneously reacting to, producing feedback between the two controllers; using VPA for memory sizing and HPA for CPU-based replica scaling on the same workload is a safer separation of concerns.

Target Availability During VPA Updates

Because VPA in Auto mode may need to evict and recreate pods to apply a new resource allocation, the target controller's own update strategy (rolling update parameters, pod disruption budget) directly affects how disruptive a vertical resize is in practice — reviewing these settings alongside the VPA configuration is part of managing the scale target correctly.

Cluster Autoscaler Target Considerations

Node Group as the Scale Target

The Cluster Autoscaler's equivalent of a scale target is the node group (or equivalent cloud-provider construct) it is configured to manage, bounded by minimum and maximum node counts; a node group misconfigured with too low a maximum silently caps cluster capacity regardless of how much pod-level demand exists, a scope mismatch analogous to an HPA's maxReplicas being set too conservatively.

cluster-autoscaler --nodes=2:10:my-node-group

Verifying Target Configuration

Confirming the Autoscaler Is Actually Attached

kubectl describe hpa <name> and kubectl describe vpa <name> both report the current status of their target reference, including any errors resolving it (a typo in the target name, a missing scale subresource); checking this status after creating or modifying an autoscaler confirms it is genuinely operating against the intended controller rather than silently failing to find its target.

kubectl describe hpa api-service
# Conditions: AbleToScale True, ScalingActive True