What would you like to be added:
A way for a user to restrict, directly on the CR, which MultiKueue worker clusters
a Workload may be dispatched to — without running an external dispatcher. The user
provides a list of worker cluster names (annotation in the MVP); the built-in
dispatcher nominates only those, always intersected with the clusters the
Workload's ClusterQueue is already authorized for (narrow only, never widen).
Why is this needed:
Motivating use case: checkpoint data locality. A training RayCluster runs on some
worker cluster; every N steps the caller writes a checkpoint (local to that
cluster) and launches a separate RayJob to run an async eval over it. The eval
must run on the cluster where that checkpoint lives — a fixed cluster resolved by
the caller at launch time, which must not follow the training job if it is later
preempted and relocated. Today the only per-Workload way to pin a cluster is an
external dispatcher, which is heavyweight for the "caller already knows the target
cluster" case.
Design doc / KEP draft PR: #14539.
Completion requirements:
This enhancement requires the following artifacts:
The artifacts should be linked in subsequent comments.
AI tools were used to help draft this issue, per the Kubernetes AI tool usage policy.
What would you like to be added:
A way for a user to restrict, directly on the CR, which MultiKueue worker clusters
a Workload may be dispatched to — without running an external dispatcher. The user
provides a list of worker cluster names (annotation in the MVP); the built-in
dispatcher nominates only those, always intersected with the clusters the
Workload's ClusterQueue is already authorized for (narrow only, never widen).
Why is this needed:
Motivating use case: checkpoint data locality. A training
RayClusterruns on someworker cluster; every N steps the caller writes a checkpoint (local to that
cluster) and launches a separate
RayJobto run an async eval over it. The evalmust run on the cluster where that checkpoint lives — a fixed cluster resolved by
the caller at launch time, which must not follow the training job if it is later
preempted and relocated. Today the only per-Workload way to pin a cluster is an
external dispatcher, which is heavyweight for the "caller already knows the target
cluster" case.
Design doc / KEP draft PR: #14539.
Completion requirements:
This enhancement requires the following artifacts:
The artifacts should be linked in subsequent comments.
AI tools were used to help draft this issue, per the Kubernetes AI tool usage policy.