Managing jobs and label policies

As an administrator, you can configure how Alauda Build of Kueue identifies and manages workloads by using label policies. Label policies determine whether workloads must have the kueue.x-k8s.io/queue-name label to be managed by Kueue.

Label policy options

The label policy is configured in the Alauda Build of Kueue deployment. The following options are available:

PolicyDescription
QueueName(Default) Kueue manages only workloads that have the kueue.x-k8s.io/queue-name label. Workloads without this label are ignored by Kueue.
NoneKueue manages all workloads, even those without the kueue.x-k8s.io/queue-name label. In this case, a default local queue must exist in the namespace.

Labeling workloads

To submit a workload to a specific local queue, add the kueue.x-k8s.io/queue-name label to the workload manifest:

metadata:
  labels:
    kueue.x-k8s.io/queue-name: <local-queue-name>

This label must be present on the top-level object of the workload (e.g., on the Job, RayJob, PyTorchJob, or InferenceService metadata).

Using a default local queue

If you create a local queue named default in a namespace, newly created workloads in that namespace that do not have the kueue.x-k8s.io/queue-name label are automatically assigned to the default local queue.

This is useful for enforcing quota management on all workloads in a namespace without requiring users to label each workload individually.

For more information on creating a default local queue, see Configuring a default local queue.

Queue enforcement for projects

To enforce quota management on all workloads within a project namespace, you can combine the default local queue mechanism with the QueueName label policy. This ensures that:

  1. All new workloads in the namespace are automatically managed by Kueue.
  2. Workloads that do not specify a queue are assigned to the default local queue.
  3. Workloads that specify a non-existent queue are rejected.

Setting up queue enforcement

  1. Create a project and namespace in Alauda Container Platform.

  2. Create a default local queue in the namespace:

    apiVersion: kueue.x-k8s.io/v1beta2
    kind: LocalQueue
    metadata:
      namespace: <project-namespace>
      name: default
    spec:
      clusterQueue: <cluster-queue-name>
  3. Apply the LocalQueue:

    kubectl apply -f default-local-queue.yaml

After this setup, any new workload created in the namespace without the kueue.x-k8s.io/queue-name label will be automatically assigned to the default local queue and managed by Kueue.

INFO

Note: Pre-existing workloads are not affected by the creation of a default local queue. Only newly created workloads will be automatically labeled.

Restricting ClusterQueue access with namespace selectors

You can restrict which namespaces can submit workloads to a ClusterQueue by using the namespaceSelector field:

Allow all namespaces (default):

spec:
  namespaceSelector: {}

Allow only specific namespaces:

spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: team-a

Allow namespaces with a custom label:

spec:
  namespaceSelector:
    matchLabels:
      kueue-enabled: "true"

To apply a custom label to a namespace:

kubectl label namespace <namespace> kueue-enabled=true