Needs based queue selection

[KPostOffice]

What would you like to be added:

If I have multiple queues available to me, I would like to have the ability to choose a queue based off of labels indicating capabilities provided by that queue.

Why is this needed:

I have nodes which all provide a number of nvidia.com/gpu. Not captured in this is the GPU model provided by this node. I can create ClusterQueues which only have resource flavors that point at specific models. I would like the ability to label these ClusterQueues with the models and any other specifics about the ClusterQueues. Then, within a workload I would like to be able to specify these labels i.e.:

...
  selectors:
  - listType: allOf
    labels: [CUDAXX]
  - listType: oneOf
    labels: [A100, H100] 

or

...
  selectors:
  - listType: NoneOf
    labels: [GPU] 

Completion requirements:
API change for ClusterQueues/LocalQueues allowing for labeling based off of provided capabilities and changes to scheduling algorithm to allow for labels based scheduling.

This enhancement requires the following artifacts:

• Design doc
• API change
• Docs update

The artifacts should be linked in subsequent comments.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten