Kueue - CoreWeave Docs

Chart reference	Description
`coreweave/cks-kueue`	CoreWeave’s Helm chart for deploying Kueue on CKS clusters

About Kueue

Kueue is a Kubernetes-native system that manages jobs using quotas. Kueue makes job decisions based on resource availability, job priorities, and the quota policies defined in your cluster queues. Kueue determines when a job waits for available resources, when a job starts (Pods created), and when a job is preempted (active Pods deleted). Use Kueue on CKS to prioritize batch, AI, and ML workloads, share GPU capacity fairly across teams, and reduce idle time on expensive accelerators. CKS supports Kueue by default. To simplify getting started, CoreWeave provides a Helm chart for installing Kueue. The cks-kueue chart also includes a kueue subchart, used to configure Kueue for deployment into your CKS cluster.

Always install Kueue with CoreWeave’s cks-kueue chart. Upstream Kueue registers admission webhooks that intercept system and infrastructure Pods, which can deadlock the cluster and prevent it from starting. The cks-kueue chart configures the webhooks to exclude these Pods, so the cluster can always start.

When you install Kueue through the CoreWeave Helm chart, Kueue metrics are automatically scraped and ingested into the Kueue Scheduling Dashboard in CoreWeave Grafana.

Usage

Install the cks-kueue Helm chart to deploy Kueue into your CKS cluster. The chart installs the Kueue controller and CRDs so you can begin defining queues and submitting workloads. Add the CoreWeave Helm repo so Helm can locate the cks-kueue chart.

helm repo add coreweave https://charts.core-services.ingress.coreweave.com

Then, install Kueue on your CKS cluster.

helm install kueue coreweave/cks-kueue --namespace=kueue-system --create-namespace

After the chart installs, the Kueue controller runs in the kueue-system namespace and the Kueue CRDs are available for use in your cluster.

Sample Kueue configuration

After you install the cks-kueue chart, use the following sample configuration to set up a basic Kueue environment for CKS. This configuration creates a single shared queue that gets you started with a proof of concept. Production deployments usually divide capacity among teams instead. For more information, see Share capacity across teams with Cohorts. The samples use kueue.x-k8s.io/v1beta2. Before applying them, confirm that your installed Kueue CRDs serve this API version. The configuration includes the following Kueue components:

ResourceFlavor: Defines the characteristics of compute resources (CPU, memory, GPUs) available in your cluster.
ClusterQueue: Establishes resource quotas and admission policies across your entire cluster.
LocalQueue: Creates namespaced queues that reference a ClusterQueue for job submission.
WorkloadPriorityClass: Defines priority levels for jobs to determine scheduling order and preemption behavior.

The configuration also defines two priority classes for different job types: production jobs with high priority and development jobs with lower priority.

# ResourceFlavor defines the compute resources available in your cluster
# This flavor represents the standard CKS Node configuration
---
apiVersion: kueue.x-k8s.io/v1beta2
kind: ResourceFlavor
metadata:
  name: default-flavor
---
# ClusterQueue establishes resource quotas and admission policies
# This queue allows jobs to consume up to the specified resource limits
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: "cluster-queue"
spec:
  # Enable preemption of lower priority jobs when higher priority jobs need resources
  preemption:
    withinClusterQueue: LowerPriority
  # Allow jobs from all namespaces to use this queue
  namespaceSelector: {} # Match all namespaces.
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu", "rdma/ib"]
      flavors:
        - name: "default-flavor"
          resources:
            - name: "cpu"
              nominalQuota: 254          # Total CPU cores available
            - name: "memory"
              nominalQuota: 2110335488Ki # Total memory available (~2TB)
            - name: "nvidia.com/gpu"
              nominalQuota: 16           # Total GPUs available
            - name: "rdma/ib"
              nominalQuota: 12800        # Total number of RDMA Nodes available
---
# LocalQueue creates a namespaced queue for job submission
# Jobs submitted to this queue will use the cluster-queue resources
apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  namespace: "default"
  name: "default"
spec:
  clusterQueue: "cluster-queue"
---
# WorkloadPriorityClass defines priority levels for job scheduling
# Higher values = higher priority (jobs with higher priority can preempt lower priority jobs)
apiVersion: kueue.x-k8s.io/v1beta2
kind: WorkloadPriorityClass
metadata:
  name: prod-priority
value: 1000
description: "Priority class for prod jobs"
---
apiVersion: kueue.x-k8s.io/v1beta2
kind: WorkloadPriorityClass
metadata:
  name: dev-priority
value: 100
description: "Priority class for development jobs"
---

For more information, see Using Kueue with Ray on CKS.

A Cohort groups ClusterQueues so that a team can borrow quota that other teams aren’t using. With the reclaimWithinCohort policy shown in the following sample, a team can reclaim its nominal quota by preempting eligible workloads in borrowing queues. Admission still depends on the workload’s resource requirements and scheduling constraints. A single ClusterQueue is enough for a proof of concept, but most organizations divide cluster capacity among several teams. You can give each team its own ClusterQueue with a nominal quota and a LocalQueue in the team’s namespace. Nominal quota defines an admission entitlement; it does not reserve physical GPUs. The following configuration reuses the previous sample’s ResourceFlavor and WorkloadPriorityClass resources. It splits the same resource quotas between two teams, team-a and team-b, and joins their ClusterQueues in a Cohort named org-cohort. It also creates the team namespaces and a default LocalQueue in each namespace.

Use these team queues instead of the previous sample’s shared queue. If you applied that sample, stop submitting jobs to its default LocalQueue in the default namespace. Wait for its workloads to finish, then remove that LocalQueue and cluster-queue before applying the team configuration. Otherwise, both configurations can admit work against the same physical capacity.

Submit each team’s jobs in its namespace with the label kueue.x-k8s.io/queue-name: default. To select a priority, also set kueue.x-k8s.io/priority-class to prod-priority or dev-priority on the job. Creating the priority classes alone does not assign them to jobs.

# Create the namespaces before their LocalQueues.
---
apiVersion: v1
kind: Namespace
metadata:
  name: team-a
---
apiVersion: v1
kind: Namespace
metadata:
  name: team-b
---
# Cohort groups ClusterQueues so they can share unused capacity.
# ClusterQueues join the Cohort by setting spec.cohortName.
---
apiVersion: kueue.x-k8s.io/v1beta2
kind: Cohort
metadata:
  name: org-cohort
# Optional spec fields: add resourceGroups to define shared quota in addition
# to the member ClusterQueues' quotas, or parentName to nest Cohorts.
---
# ClusterQueue for team-a with half of the sample's GPU quota
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: team-a-queue
spec:
  # Join the org-cohort Cohort to borrow from and lend to team-b-queue
  cohortName: org-cohort
  preemption:
    # Higher-priority team-a jobs can preempt lower-priority team-a jobs
    withinClusterQueue: LowerPriority
    # Reclaim this queue's quota by preempting eligible workloads in
    # borrowing queues in the Cohort, regardless of workload priority
    reclaimWithinCohort: Any
    # When admission requires borrowing, allow preemption of lower-priority
    # workloads in other queues that are borrowing in the Cohort
    borrowWithinCohort:
      policy: LowerPriority
  # Only the team-a namespace can submit jobs to this queue
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: team-a
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu", "rdma/ib"]
      flavors:
        - name: "default-flavor"
          resources:
            - name: "cpu"
              nominalQuota: 127
            - name: "memory"
              nominalQuota: 1055167744Ki
            - name: "nvidia.com/gpu"
              nominalQuota: 8
              borrowingLimit: 4 # Borrow at most 4 GPUs from the Cohort
            - name: "rdma/ib"
              nominalQuota: 6400
---
# ClusterQueue for team-b with the other half of the sample's GPU quota
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: team-b-queue
spec:
  cohortName: org-cohort
  preemption:
    withinClusterQueue: LowerPriority
    reclaimWithinCohort: Any
    borrowWithinCohort:
      policy: LowerPriority
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: team-b
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu", "rdma/ib"]
      flavors:
        - name: "default-flavor"
          resources:
            - name: "cpu"
              nominalQuota: 127
            - name: "memory"
              nominalQuota: 1055167744Ki
            - name: "nvidia.com/gpu"
              nominalQuota: 8
              borrowingLimit: 4
            - name: "rdma/ib"
              nominalQuota: 6400
---
# LocalQueue for team-a job submission in the team-a namespace
apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  namespace: "team-a"
  name: "default"
spec:
  clusterQueue: "team-a-queue"
---
# LocalQueue for team-b job submission in the team-b namespace
apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  namespace: "team-b"
  name: "default"
spec:
  clusterQueue: "team-b-queue"
---

With this configuration, Kueue behaves as follows:

When team-b is idle, team-a has a quota ceiling of 12 GPUs: its 8 nominal GPUs plus 4 borrowed from the Cohort. Running those jobs also requires sufficient CPU, memory, RDMA resources, and physical capacity.
When team-b needs its nominal quota, Kueue can preempt eligible workloads in team-a’s borrowing queue to make room (reclaimWithinCohort: Any). Reclaim can select workloads regardless of their priority, provided the incoming workload can fit after preemption.
Within each queue, jobs with the prod-priority class can preempt jobs with the dev-priority class when needed for admission (withinClusterQueue: LowerPriority).

Kueue’s fair sharing feature supports withinClusterQueue and reclaimWithinCohort, but not borrowWithinCohort. If you enable fair sharing, remove borrowWithinCohort from your ClusterQueues.

Plan your ClusterQueue split

The right way to divide quota among ClusterQueues depends on your organization. When you plan the split, consider the following:

Create one ClusterQueue for each team that needs a nominal quota, and a LocalQueue in each namespace where that team submits jobs.
Set each nominalQuota to the team’s share. For a fixed-size cluster, keep the sum of quotas within the allocatable capacity of the Nodes that the ResourceFlavor matches, after accounting for system components and workloads outside Kueue. Kueue doesn’t validate configured quotas against actual Node capacity, although topology-aware scheduling checks physical fit during workload admission.
Use namespaceSelector to control which namespaces can submit jobs to each queue.
Use borrowingLimit and lendingLimit to bound how much capacity moves between teams. For more information, see ClusterQueue concepts in the Kueue documentation.
Define WorkloadPriorityClass resources and assign them to jobs for consistent priority ordering. With reclaimWithinCohort: Any, reclaim can preempt even higher-priority workloads in borrowing queues.
Revisit the split when you add Node capacity or when teams change. Adding Nodes does not automatically increase the nominal quotas configured in these samples. Update those quotas when you want the queues to admit more work.

Observability

This section describes how to monitor Kueue activity after the chart is installed. CoreWeave Grafana provides a Kueue Scheduling Dashboard that you can use to monitor your Kueue cluster.

Topology-aware scheduling

Topology-aware scheduling (TAS) lets Kueue improve scheduling decisions by considering the physical topology of your cluster’s Nodes. This is important for HPC, AI, and ML workloads, where network latency between Nodes can be a performance bottleneck. TAS can co-locate a job’s Pods to minimize communication overhead and maximize performance. The TopologyAwareScheduling feature in the Kueue controller is enabled by default. However, to use it, you must adjust some of the Kueue resources so that Kueue references the Node labels that describe your cluster’s topology. After the Helm chart is installed and the Kueue CRDs exist, choose one of the following topologies based on CKS Node labels for Kueue to use:

The infiniband topology is for instance types that are a part of InfiniBand fabrics. See About GPU instances to find InfiniBand connected instances.
The multinode-nvlink-ib topology extends the infiniband topology to also include instance types with rack-scale NVLink. See About GPU instances to find NVLink connected rack instances.
The hostname topology is for instance types without InfiniBand fabrics. It prevents Kueue from admitting workloads when total capacity is sufficient but fragmented across Nodes.

helm upgrade kueue coreweave/cks-kueue --namespace=kueue-system --values - <<EOF
topologies:
  - name: infiniband
    levels:
      - backend.coreweave.cloud/fabric
      - backend.coreweave.cloud/superpod
      - backend.coreweave.cloud/leafgroup
      - kubernetes.io/hostname
  - name: multinode-nvlink-ib
    levels:
      - backend.coreweave.cloud/fabric
      - backend.coreweave.cloud/superpod
      - backend.coreweave.cloud/leafgroup
      - ds.coreweave.com/nvlink.domain
      - kubernetes.io/hostname
  - name: hostname
    levels:
      - kubernetes.io/hostname
EOF

After you upgrade the Helm chart, the new Topology CRs appear in the cluster. The following example configuration is an adjustment of the preceding one. It demonstrates how to use the Topology resources by referencing them in ResourceFlavor resources, which are then used by ClusterQueue and LocalQueue resources. Each ResourceFlavor must select a disjoint set of Nodes. Use nodeLabels so that no Node matches more than one flavor. Overlapping selectors cause a Node to belong to multiple flavors, which leads to ambiguous quota accounting and unpredictable scheduling. Match each topologyName to a Node pool whose hardware actually provides that topology. For example, pair the infiniband topology with an InfiniBand connected pool like B200, the multinode-nvlink-ib topology with a rack-scale NVLink pool like GB200, and the hostname topology with pools that lack InfiniBand.

Referencing a topology whose labels are not present on the selected Nodes causes Kueue to fail to admit workloads for that flavor. Verify that every label in the Topology levels list exists on the Nodes selected by the flavor’s nodeLabels.

---
apiVersion: kueue.x-k8s.io/v1beta2
kind: ResourceFlavor
metadata:
  name: b200-flavor
spec:
  topologyName: infiniband # References the infiniband Topology CR
  nodeLabels:
    compute.coreweave.com/node-pool: b200-nodepool
---
# This flavor enables topology-aware scheduling across NVLINK domains
apiVersion: kueue.x-k8s.io/v1beta2
kind: ResourceFlavor
metadata:
  name: gb200-flavor
spec:
  topologyName: multinode-nvlink-ib # References the multinode-nvlink-ib Topology CR
  # nodeLabels is a map, so each flavor selects the Nodes that match all of
  # its labels. To cover more than one Node Pool, apply a shared label to the
  # pools and match that label, or create one flavor per Node Pool.
  nodeLabels:
    compute.coreweave.com/node-pool: gb200-nodepool
---
# ClusterQueue for InfiniBand-connected workloads
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: "b200-queue"
spec:
  preemption:
    withinClusterQueue: LowerPriority
  namespaceSelector: {}
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu", "rdma/ib"]
      flavors:
        - name: "b200-flavor"
          resources:
            - name: "cpu"
              nominalQuota: 2048 # 16 Nodes * 128 vCPU per Node
            - name: "memory"
              nominalQuota: 34359738368Ki # 16 Nodes * 2Ti per Node = 32Ti
            - name: "nvidia.com/gpu"
              nominalQuota: 128 # 16 Nodes * 8 GPUs per Node
            - name: "rdma/ib"
              nominalQuota: 12800
---
# ClusterQueue for GB200 workloads with multinode-NVLINK
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: "gb200-queue"
spec:
  preemption:
    withinClusterQueue: LowerPriority
  namespaceSelector: {}
  resourceGroups:
    - coveredResources: ["cpu", "memory", "nvidia.com/gpu", "rdma/ib"]
      flavors:
        - name: "gb200-flavor"
          resources:
            - name: "cpu"
              nominalQuota: 2304 # 16 Nodes * 144 vCPU per Node
            - name: "memory"
              nominalQuota: 15000000000Ki # 16 Nodes * 960 GB per Node = 15.36 TB
            - name: "nvidia.com/gpu"
              nominalQuota: 64 # 16 Nodes * 4 GPUs per Node
            - name: "rdma/ib"
              nominalQuota: 12800
---
# LocalQueue for InfiniBand workloads in the default namespace
apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  namespace: "default"
  name: "b200-local"
spec:
  clusterQueue: "b200-queue"
---
# LocalQueue for GB200 workloads in the default namespace
apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  namespace: "default"
  name: "gb200-local"
spec:
  clusterQueue: "gb200-queue"
---
# WorkloadPriorityClass definitions (same as basic example)
apiVersion: kueue.x-k8s.io/v1beta2
kind: WorkloadPriorityClass
metadata:
  name: prod-priority
value: 1000
description: "Priority class for prod jobs"
---
apiVersion: kueue.x-k8s.io/v1beta2
kind: WorkloadPriorityClass
metadata:
  name: dev-priority
value: 100
description: "Priority class for development jobs"
---

Example jobs with topology constraints

Kueue provides several annotations for expressing topology constraints on a job. Two of the most common are:

kueue.x-k8s.io/podset-required-topology requires that all Pods in a job are scheduled within the same topology domain. The job stays pending until a domain can fit it.
kueue.x-k8s.io/podset-preferred-topology treats the topology domain as best effort. Kueue tries to fit all Pods within the same domain, but falls back to spreading across domains if needed.

For the full list of annotations and their semantics, see the Kueue Topology Aware Scheduling user-facing APIs.

Four Pods on one leafgroup with the InfiniBand queue

This example schedules four Pods within a single leafgroup:

apiVersion: batch/v1
kind: Job
metadata:
  name: test-tas-job
  namespace: default
  labels:
    kueue.x-k8s.io/queue-name: b200-local
spec:
  parallelism: 4
  completions: 4
  template:
    metadata:
      annotations:
        kueue.x-k8s.io/podset-required-topology: "backend.coreweave.cloud/leafgroup"
    spec:
      containers:
        - name: training
          image: busybox
          command: ["sleep", "30s"]
          resources:
            requests:
              cpu: "32"
              memory: "256Gi"
              nvidia.com/gpu: "8"
              rdma/ib: "1"
            limits:
              cpu: "32"
              memory: "256Gi"
              nvidia.com/gpu: "8"
              rdma/ib: "1"
      restartPolicy: Never

Four Pods on one NVLINK domain with the GB200 queue

This example schedules four Pods within a single NVLINK domain for GB200 Nodes:

apiVersion: batch/v1
kind: Job
metadata:
  name: gb200-test-tas
  labels:
    kueue.x-k8s.io/queue-name: gb200-local
spec:
  parallelism: 4
  completions: 4
  template:
    metadata:
      annotations:
        kueue.x-k8s.io/podset-required-topology: "ds.coreweave.com/nvlink.domain"
    spec:
      containers:
        - name: training
          image: your-training-image:latest
          resources:
            requests:
              cpu: "32"
              memory: "256Gi"
              nvidia.com/gpu: "4"
              rdma/ib: "1"
            limits:
              cpu: "32"
              memory: "256Gi"
              nvidia.com/gpu: "4"
              rdma/ib: "1"
      restartPolicy: Never

​About Kueue

​Usage

​Sample Kueue configuration

​Share capacity across teams with Cohorts

​Plan your ClusterQueue split

​Observability

​Topology-aware scheduling

​Example jobs with topology constraints

​Four Pods on one leafgroup with the InfiniBand queue

​Four Pods on one NVLINK domain with the GB200 queue

About Kueue

Usage

Sample Kueue configuration

Share capacity across teams with Cohorts

Plan your ClusterQueue split

Observability

Topology-aware scheduling

Example jobs with topology constraints

Four Pods on one leafgroup with the InfiniBand queue

Four Pods on one NVLINK domain with the GB200 queue