kubernetes-sigs / lws / 35909535330

85%

main: 85%

Build Type

push

github

Committed by web-flow

Commit Message

[release-0.11] KEP-666: Support workload-aware scheduling with groupIdentity Hash (#1089)

* KEP-666: Support workload-aware scheduling with groupIdentity Hash

Phase 1 gang scheduling only worked with groupIdentity Ordinal, where the
LeaderWorkerSet controller can enumerate every replica instance from the
replica count. Admission rejected spec.scheduling with groupIdentity Hash.

With Hash identity a group is named by a key that admission draws for each
leader pod, so the replica and leader/worker PodGroups do not have names until
their leader exists. Every hash leader is already admitted with the
group-replacement scheduling gate, which gives the point where those PodGroups
can be created while the leader still cannot be scheduled. That preserves the
KEP-666 rule that a pod's leaf PodGroup exists before the pod is schedulable,
and keeps the PodGroups controller-owned by the LeaderWorkerSet rather than by
the leader pod.

- The Deployment reconcile path now compiles the Workload, and the whole-LWS
  PodGroup whose name is group independent, before applying the leader
  Deployment. Both identity modes share one helper.
- The kubernetes provider defers replica and role PodGroups to
  CreatePodGroupIfNotExists under Hash, materializing them from the persisted
  Workload template with the group key the pod webhook already stamped into the
  group index label. Cleanup keeps any group that still has member pods, which
  covers the names the controller cannot enumerate.
- The pod controller creates the PodGroups before it lifts the replacement
  gate, instead of after.
- The Volcano provider skips its ordinal pre-creation loop under Hash and
  relies on the pod-driven path it already implements.

* Retain PodGroups of active Hash leader pods during cleanup

Under groupIdentity Hash, replica instances cannot be enumerated from
the replica count alone at the start of ReconcileScheduling, so desiredGroups
was previously empty. Cleanup relied solely on inUseGro... (continued)

Coverage Stats

160 of 183 new or added lines in 5 files covered. (87.43%)

1 existing line in 1 file now uncovered.

5234 of 6139 relevant lines covered (85.26%)

39.71 hits per line