Promote LocalQueueDefaulting to per-namespace configuration in the Kueue Configuration API

[valdar]

What would you like to be added:

Promote the LocalQueueDefaulting behavior from a global feature gate to a full-fledged, per-namespace configuration option in the Kueue Configuration API.

Today, LocalQueueDefaulting is a GA feature gate (LockToDefault: true since v0.17, scheduled for removal in v0.19). The defaulting behavior is implicitly activated by the presence of a LocalQueue named default in a namespace — there is no explicit administrative knob to enable or
disable it per namespace.

The proposal is to introduce a configuration mechanism (e.g., a namespace selector in Configuration, or a namespace annotation) that lets administrators explicitly control which namespaces participate in LocalQueue defaulting, independently of whether a LocalQueue named default
exists.

Why is this needed:

The current convention-based approach (create a LocalQueue named default → defaulting activates) conflates resource creation with policy intent. This creates several gaps:

1. Multi-tenant clusters: In shared clusters, different tenants may have different requirements. Some namespaces may need defaulting for ease of use (e.g., data science teams submitting ad-hoc jobs), while others require explicit queue assignment for auditability or cost attribution. Today there is no way to enforce "defaulting must not happen in namespace X" — if someone creates a LocalQueue named default, defaulting silently activates.
2. Downstream distributions: Platforms built on top of Kueue often need to pre-provision LocalQueues across namespaces. A per-namespace configuration lets platform operators decide the defaulting policy centrally rather than relying on naming conventions that end users could inadvertently trigger or break.
3. Consistency with existing patterns: Kueue already has ManagedJobsNamespaceSelector in the Configuration API, which provides namespace-level control over job management. LocalQueue defaulting is a natural candidate for the same pattern — administrators expect namespace-scoped behaviors to be configurable namespace-by-namespace.
4. Separation of concerns: A LocalQueue named default may legitimately exist as a routing target without the administrator intending it to be the implicit default for unlabeled jobs. Decoupling the "this queue exists" fact from the "this namespace uses defaulting" policy avoids accidental behavior and makes the system more predictable.
5. Gradual rollout and migration: Operators adopting Kueue incrementally can enable defaulting in onboarded namespaces while leaving others untouched, reducing blast radius during migration.
6. Compliance and governance: Some environments require that every job submission explicitly declares its target queue for regulatory or chargeback reasons. A per-namespace opt-out provides a clear enforcement point.

Completion requirements:

This enhancement requires the following artifacts:

• Design doc
• API change
• Docs update

[kannon92]

cc @PannagaRao @sohankunkerkar @MaysaMacedo

[kannon92]

Just checking, are you asking that Kueue still work in the namespace but not default? I was thinking you just opt out namespace from being managing by Kueue (ie use ManagedNamespaceSelector).