Kubernetes scheduler is a part of the open source Kubernetes container orchestration platform that controls performance, capacity and availability through policies and topology awareness.
The scheduler is a monolithic component of Kubernetes, decoupled from the API server that manages clusters. It is not an admission controller, which is actually plug-in code that intercepts requests to the Kubernetes API. Virtualization administrators will see Kubernetes scheduling as the containerization equivalent of VM scheduling, as with VMware Distributed Resource Scheduler.
Kubernetes deploys containers organized into Pods that reside on logical groupings of resources called Nodes. Requirements specific to a workload are set through an API. The Kubernetes scheduler attempts to match each Pod created by Kubernetes to a suitable set of IT resources on a Node. It can also distribute copies of Pods across different Nodes for high availability, if that feature is desired.
If Kubernetes scheduler fails to find hardware that suits a Pod's requirements and specifications, from affinity and anti-affinity rules to quality of service settings, that Pod is left unscheduled, and the scheduler retries it until a machine becomes available.
Configuration
Kubernetes scheduler is configurable with two different policies: PriorityFunction and FitPredicate. It can also pick a Node at random, which is a method to assign containers to resources with minimal computational overhead.
The FitPredicate policy follows the required rules, while attempting to detect labels on the Kubernetes Node, or to detect the number of resources requested by the containers already running on a given machine. FitPredicate helps to detect if containers exceed the capacity of given hardware resources. If a user selects zero resources, the scheduler can always add another Pod to the Node.
PriorityFunction applies when the scheduler has already checked multiple systems for the best fit. If the scheduler finds several options that could support the Pod, PriorityFunction directs the scheduler to rank the machines based on the best fit. For example, three Nodes fit the needs of the new Pod, but one has more free resources than the others, and is, therefore, the best fit.
In the Kubernetes environment, these two policies help to load balance container workloads across multiple machines so that one machine is not given intense activity, while others sit idle.