:_mod-docs-content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="about-kueue"]
= Introduction to {kueue-name}
:context: about-kueue

toc::[]

[role="_abstract"]
You can use {kueue-name} to manage when jobs in your Kubernetes cluster start, get preempted, or wait for resources. {kueue-name} optimizes resource utilization by enforcing quotas and scheduling policies across your workloads.

{kueue-name} can determine when a job waits, is admitted to start by creating pods, or should be _preempted_, meaning that active pods for that job are deleted.

[NOTE]
====
In the context of {kueue-name}, a job can be defined as a one-time or on-demand task that runs to completion.
====

{kueue-name} is based on the Kueue open source project.

{kueue-name} is compatible with environments that use heterogeneous, elastic resources, where many different resource types exist and those resources are capable of dynamic scaling.

{kueue-name} does not replace any existing components in a Kubernetes cluster, but instead integrates with the existing Kubernetes API server, scheduler, and cluster autoscaler components.

{kueue-name} supports all-or-nothing semantics, where either an entire job with all of its components is admitted to the cluster, or the entire job is rejected if it does not fit on the cluster.

// Personas
[id="about-kueue-personas"]
== Personas

Different personas exist in a {kueue-name} workflow.

Batch administrators:: Batch administrators manage the cluster infrastructure and establish quotas and queues.
Batch users:: Batch users run jobs on the cluster. Examples of batch users might be researchers, AI/ML engineers, or data scientists.
Serving users:: Serving users run jobs on the cluster. For example, to expose a trained AI/ML model for inference.
Platform developers:: Platform developers integrate {kueue-name} with other software. They might also contribute to the Kueue open source project.

[id="about-kueue-workflow"]
== Workflow overview

The {kueue-name} workflow can be described at a high level as follows:

. Batch administrators create and configure `ResourceFlavor`, `LocalQueue`, and `ClusterQueue` resources.
. User personas create jobs on the cluster.
. The Kubernetes API server validates and accepts job data.
. {kueue-name} admits jobs based on configured options, such as order or quota. It injects affinity into the job by using resource flavors, and creates a `Workload` object that corresponds to each job.
. The applicable controller for the job type creates pods.
. The Kubernetes scheduler assigns pods to a node in the cluster.
. The Kubernetes cluster autoscaler provisions more nodes as required.

////
TODO:Add docs explaining different job / workload types
These can be added as we add stories / docs for different use cases
////

[id="additional-resources_{context}"]
[role="_additional-resources"]
== Additional resources
* link:https://kueue.sigs.k8s.io/docs/[Kueue (upstream documentation)]
