Admission

Kueue’s admission process determines whether a Workload can begin execution. Admission may also be subject to the admission gate mechanism which is in beta and enabled by default.

It involves verifying:

• logical resource availability via quota reservation
• physical resource availability via Topology-Aware Scheduling, when used,
• optional AdmissionChecks for additional admission guards.

Kueue implements this through a two-phase admission cycle:

1. Quota Reservation: When a user submits a Workload, it enters a LocalQueue first. This LocalQueue points to a ClusterQueue which is responsible for managing the available resources. The Kueue checks if the targeted ClusterQueue’s available quota and resource flavors can accommodate requested resources (CPU, memory, GPUs, etc.). If the quota is available, the Kueue reserves resources for this Workload and prevents other Workloads from using the same resources. This phase also includes checking the availability of physical resources when Topology-Aware Scheduling is enabled.

2. Admission Checks: Await for AdmissionChecks configured in the ClusterQueue. Checks can be either built-in such as MultiKueue or ProvisioningRequest, or user-created plugins.

The Workload is admitted once all AdmissionCheckStates are in the Ready state.

Failure Handling:

• For temporary issues (e.g., cloud capacity shortages):

  • The system releases the reserved quota immediately.
  • It requeues the workload.
  • It triggers exponential backoff retries via retryStrategy in ProvisioningRequestConfig.
  • Kueue creates a new ProvisioningRequest for each retry, named <workload>-<admission-check>-<attempt>.

• For permanent failures:

  • The system marks the AdmissionCheck as Rejected
  • It evicts the Workload.
  • It releases the reserved quota.
  • It sets the Workload’s .spec.active field to false. To requeue it, the user needs to set the field to true.

The following diagram shows the complete admission cycle for a Workload that uses the ProvisioningRequest AdmissionCheck, including the retry loop:

Because the Workload is requeued between attempts, the quota reserved for the previous attempt is released before the next one starts. Each retry creates a new ProvisioningRequest named <workload>-<admission-check>-<attempt>, and the backoff is controlled by retryStrategy.

What’s Next?

You can read the Concepts section to learn how Admission Checks influence admission.