kubernetes-sigs / lws / 30090703632

59%

main: 58%

Build Type

Pull #922

github

Committed by hasB4K

Commit Message

fix(disaggregatedset): scale on leader pods; supersedes 4c988d2

The prior fix multiplied status.replicas by leaderWorkerTemplate.size to
report pod count. That breaks HPA's ratio math when size > 1: HPA writes
spec.replicas in units of LWS groups (that's what the controller forwards
to LWS.spec.replicas), but reads status.replicas in units of pods. HPA
computes desiredReplicas = currentReplicas × (currentMetric/targetMetric)
without knowing the units differ, so a scale event lands in the wrong unit
and the loop diverges — e.g. HPA reads current=6 (pods), computes
desired=12, writes 12 to spec.replicas (which the controller creates as
12 groups = 36 pods), then next tick reads 36 and continues overshooting.

Correct approach: keep status.replicas as LWS groups (matching spec.replicas)
and refine status.selector to match one pod per group (the leader), so
HPA's per-pod-metric averaging divides its metric sum by the group count.
Selector becomes:

  disaggregatedset.x-k8s.io/name=<ds>,
  disaggregatedset.x-k8s.io/role=<role>,
  leaderworkerset.sigs.k8s.io/worker-index=0

This mirrors LWS's own /scale semantics (also leader-only). Scaling is
now driven by the leader's per-pod metric — the right signal for the
common LWS shape where the leader handles ingress and workers are
downstream compute.

KEP-849 prose updated in three places (Scale Subresource Status Fields,
Rolling Update Interaction, Interaction with Slices) to describe the
leader-only selector and the group-unit invariant.

Reported by @yankay at https://github.com/yankay/lws/issues/17

Pull Request Pull Request #922: feat(disaggregatedset): per-role autoscaling via DisaggregatedSetRoleScaler

Coverage Stats

190 of 240 new or added lines in 4 files covered. (79.17%)

114 existing lines in 3 files now uncovered.

2510 of 4285 relevant lines covered (58.58%)

45.51 hits per line