Skip to main content
Version: v1.5


QoS is used to express the running quality of the Pod on the node, such as the way to obtain resources, the proportion of resources obtained, and the QoS guarantee policy.


There are five types of QoS supported by the Koordinator scheduling system:

SYSTEMsystem process, resource constrainedFor system services such as DaemonSets, the latency needs to be guaranteed but it needs to limit the resource usage limit of all containers running on the node to ensure that system processes do not occupy too many resources
LSE(Latency Sensitive Exclusive)reserve resources and organizing co-located pods to share resourcesRarely used, common in middleware-type applications, generally in independent resource pools
LSR(Latency Sensitive Reserved)reserve resources for better certaintySimilar to Guaranteed by the community, CPU cores are bound
LS(Latency Sensitive)share resources for better resilience to burst trafficTypical QoS level for microservice workloads to achieve better resource elasticity and more flexible resource adjustment capabilities
BE(Best Effort)share resource exclude LSE, the quality of resource operation is limited, or even killed in extreme casesTypical QoS level for batch jobs, stable computing throughput within a certain period, low-cost resources

QoS CPU Orchestration


Koordinator QoS vs. Kubernetes QoS

As seen in the Definition section, Koordinator's QoS is more complicated than Kubernetes QoS, because in colocation scenarios, we need to fine-tune the QoS for latency-sensitive workloads to meet the needs of co-located performance.

There is a correspondence between Koordinator and Kubernetes QoS:

Koordinator QoSKubernetes QoS

Koordlet triggers corresponding resource isolation and QoS guarantee according to Pod's Priority and QoS definition.