Image for post
Image for post
Photo by Remy_Loz on Unsplash

By Andrew Chen and Dominik Tornow

Image for post
Image for post
Image for post
Image for post
Figure 1. Processing a Pod

Scheduling

The task of the Kubernetes Scheduler is to choose a placement. A placement is a partial, non-injective assignment of a set of Pods to a set of Nodes.

Image for post
Image for post
Figure 2. Example Schedule
Image for post
Image for post
Figure 3. Possible, Feasible, and Viable Schedules
Image for post
Image for post
Figure 4. Multi-Step vs. Single Step

The Kubernetes Scheduler

Image for post
Image for post
Figure 5. Kubernetes Pod Object and Kubernetes Node Object
  • a Node as a Kubernetes Node Object, and
  • the assignment of a Pod to a Node as the Pod’s .Spec.NodeName.

The Control Loop

Scheduling Step

Preemption Step

1. Feasibility

For each Pod, the Kubernetes Scheduler identifies the set of feasible Nodes, which is the set of Nodes that satisfy the constraints of the Pod.

1.1 Schedulability and Lifecycle Phase

This filter function deems a Node feasible based on the Node’s schedulability and lifecycle phase. Node conditions are accounted for via taints and tolerations (see below).

Image for post
Image for post
Figure 1.1 Schedulability and Lifecycle Phase

1.2 Resource Requirements and Resource Availability

This filter function deems a Node feasible based on the Pod’s resource requirements and the Node’s resource availabilities.

Image for post
Image for post
Figure 1.2 Resource Requirements and Resource Availability

1.3 Node Selector

This filter function deems a Node feasible based on the Pod’s node selector values and the Node’s label values.

Image for post
Image for post
Figure 1.3 Node Selector

1.4 Node Taints and Pod Tolerations

This filter function deems a Node feasible based on the Pod’s taints’ key value pairs and the Node’s tolerations’ key value pairs.

Image for post
Image for post
Figure 1.4 Node Taints and Pod Tolerations

1.5 Required Affinity

This filter function deems a Node feasible based on the Pod’s required Node Affinity Terms, Pod Affinity Terms, and Pod Anti Affinity Terms.

Image for post
Image for post
Figure 1.5 Required Affinity

2. Viability

For each Pod, the Kubernetes Scheduler identifies the set of feasible Nodes, which is the set of Nodes that satisfy the constraints of the Pod. Then, the Kubernetes Scheduler identifies the set of feasible Nodes with the highest Viability.

Image for post
Image for post
Figure 2.1 Preferred Affinity
  • Sum of the Term Weights for each matching Pod Affinity Term
  • Sum of the Term Weights for each matching Pod Anti Affinity Term

Case Study

Figure 6. depicts a case study involving two different types of Nodes and two different types of Pods:

  • 6 Nodes with GPU resources
  • Pods that do require GPUs are assigned to Nodes with GPUs
Image for post
Image for post
Figure 6. Case Study

(*) Kubernetes Binding Objects

The blog post states that the Kubernetes Scheduler binds a Pod to a Node by setting the Pod’s .Spec.NodeName to the Node’s Name. However, the Scheduler sets the .Spec.NodeName not directly but indirectly.

About this post

This blog post is a summary of the KubeCon 2018 Contributor Summit’s “Unconference” track hosted by Google and SAP detailing the Kubernetes Scheduler.

Principal Engineer at Cisco, Office of the CTO

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store