Chapter 16. Advanced scheduling

Kubernetes allows you to affect where pods are scheduled. Initially, this was only done by specifying a node selector in the pod specification, but additional mechanisms were later added that expanded this functionality. They’re covered in this chapter.

16.1. Using taints and tolerations to repel pods from certain nodes

The first two features related to advanced scheduling that we’ll explore here are the node taints and pods’ tolerations of those taints. They’re used for restricting which pods can use a certain node. A pod can only be scheduled to a node if it tolerates the node’s taints.

This is somewhat different from using node selectors and node affinity, which you’ll learn about later in this chapter. Node selectors and node affinity rules make it possible to select which nodes a pod can or can’t be scheduled to by specifically adding that information to the pod, whereas taints allow rejecting deployment of pods to certain nodes by only adding taints to the node without having to modify existing pods. Pods that you want deployed on a tainted node need to opt in to use the node, whereas with node selectors, pods explicitly specify which node(s) they want to be deployed to.

16.1.1. Introducing taints and tolerations

16.1.2. Adding custom taints to a node

16.1.3. Adding tolerations to pods

16.1.4. Understanding what taints and tolerations can be used for

16.2. Using node affinity to attract pods to certain nodes

16.2.1. Specifying hard node affinity rules

16.2.2. Prioritizing nodes when scheduling a pod

16.3. Co-locating pods with pod affinity and anti-affinity

16.3.1. Using inter-pod affinity to deploy pods on the same node

16.3.2. Deploying pods in the same rack, availability zone, or geographic region

16.3.3. Expressing pod affinity preferences instead of hard requirements

16.3.4. Scheduling pods away from each other with pod anti-affinity

16.4. Summary