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.Content Continues Below
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.
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.
Kubernetes scheduler vs. other options
Kubernetes includes the ability for a user to implement a chosen scheduler instead of the default one, and to perform concurrent scheduling. Multiple schedulers can work simultaneously, including the default scheduler. Some Pods might use the default scheduler, while others do not, both within the same Kubernetes deployment.
For example, the user can write a custom scheduler to fit the demanding requirements of a workload in a Pod. Or, the user can allow Apache Spark or Mesos schedulers to take over scheduling for those applications based on these frameworks. There is not a great demand for custom schedulers generally, but they meet exacting needs around latency or uptime for specific workloads.
The Kubernetes open source community is focused on prioritization technology that enables the user to tell Kubernetes that one Pod is more important than the others, and should not wait to be scheduled behind other workloads.
Kubernetes is a young and fast-evolving open source project, originally created by Google. Many scheduling features will appear in alpha and beta in new releases before becoming part of the stable release. For example, Kubernetes 1.7 introduced an alpha feature to let users request that Pods execute on Nodes with locally attached storage via StorageClass settings.
Also, look for advanced scheduling features from the Kubernetes project, defined by node affinity and anti-affinity, taints and tolerations, pod affinity and anti-affinity, and custom parameters.