Prevent ModelServing templates from overwriting controller Pod labels

[miantalha45]

What type of PR is this?

/kind bug

What this PR does / why we need it:

Prevents entryTemplate and workerTemplate metadata from overwriting labels owned by the ModelServing controller.

The webhook now rejects template label keys under modelserving.volcano.sh/. Pod generation also ignores this label namespace as a defensive fallback, keeping controller generated identity, routing, and rollout labels authoritative.

Custom user labels remain supported.

Which issue(s) this PR fixes:

Fixes #1582

Bug evidence (required for bug-related PRs):

Before this change, a valid ModelServing template could set:

entryTemplate:
  metadata:
    labels:
      modelserving.volcano.sh/entry: "false"

The controller first set modelserving.volcano.sh/entry: "true" on the generated Entry Pod, then copied template labels into the same map. The template value overwrote the controller value.

This caused the generated Entry Pod to have:

modelserving.volcano.sh/entry=false

Headless Service selectors use the Entry label to find the Role Entry Pod, so the Service could have no endpoints.

Regression coverage verifies that:

• Reserved labels in Entry templates are rejected.
• Reserved labels in Worker templates are rejected.
• Normal custom labels are accepted.
• Pod generation preserves controller owned labels.

Tests run:

go test ./pkg/model-serving-controller/utils ./pkg/model-serving-controller/webhook -count=1
go test ./pkg/model-serving-controller/... -count=1

Special notes for your reviewer:

The Pod generation guard protects controller labels if an existing resource, an older client, or an admission bypass supplies a reserved label. The webhook provides clear feedback for new or updated ModelServing resources.

Does this PR introduce a user-facing change?:

ModelServing now rejects Pod template labels in the modelserving.volcano.sh namespace, which is reserved for controller-managed labels.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[miantalha45]

/cc @LiZhenCheng9527 @acsoto @YaoZengzeng

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[acsoto]

Should we reserve the entire modelserving.volcano.sh/ prefix instead of enumerating the current labels? Any future controller-managed label will remain user-overridable unless it is also added to this list.

[acsoto]

The public examples/kthena-router/ModelServing-ds1.5b-pd-disaggregation.yaml example and the matching router-routing.md snippet still set modelserving.volcano.sh/group-name, so the documented flow will now be rejected at admission.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[miantalha45]

Thanks for review @acsoto . I reserved the full modelserving.volcano.sh/ prefix so future controller-managed labels are protected automatically.

I migrated the P/D role classification label from modelserving.volcano.sh/rolename to the user-owned role-name label in the E2E fixtures, public example, documentation asset, and router guide. I also removed the user-supplied modelserving.volcano.sh/group-name labels from the ModelServing example.

[kube-gopher]

Have you considered cluster upgrade scenarios? The code design might discard non-conflicting labels

[kube-gopher]

examples/kthena-router/ModelServing-ds1.5b-pd-disaggregation.yaml use modelserving.volcano.sh/rolename

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[volcano-sh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign yaozengzeng for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• examples/OWNERS
• pkg/OWNERS
• test/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment