QoS

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.

Definition

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

QoS	feature	Description
SYSTEM	system process, resource constrained	For 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 resources	Rarely used, common in middleware-type applications, generally in independent resource pools
LSR(Latency Sensitive Reserved)	reserve resources for better certainty	Similar to Guaranteed by the community, CPU cores are bound
LS(Latency Sensitive)	share resources for better resilience to burst traffic	Typical 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 cases	Typical 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 QoS	Kubernetes QoS
SYSTEM	---
LSE	Guaranteed
LSR	Guaranteed
LS	Guaranteed/Burstable
BE	BestEffort

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