Controlling Pod placement with taints and tolerations
1. Controlling Pod placement with taints and tolerations
In addition to affinity and anti-affinity rules, taints and tolerations can be used to control Pod placement. A taint is a special label applied to a node that acts as a restriction. It indicates that the node is not suitable for running certain Pods unless those Pods specifically tolerate the taint. A toleration, therefore, is a specification within a Pod's configuration that allows it to be scheduled onto a node that has a matching taint. Unlike nodeSelector, affinity, and anti-affinity rules, taints are configured on nodes instead of Pods, and they affect all Pods in the cluster. You can apply a taint on a node by using the kubectl taint command. A taint consists of three elements: A key, which gives a descriptive name that represents the taint's purpose; a value, which provides optional information that further clarifies the taint; and an effect to prevent or discourage Pods from being scheduled on tainted nodes. When a node has a taint, it notifies certain types of Pods that they are not welcome on a node. A toleration on a Pod acts like an exception, and it allows it to override the taint and run on the node anyway. A toleration field consists of four components: a key, value, effect, and operator. A Pod can only override a taint if its toleration has the same key, effect, and passes the value check using its operator. If a toleration's operator is "Equal", its value must match the taint's value exactly to be effective. If a toleration's operator is "Exists", it only needs to have the same key and effect as the taint, regardless of value. And if multiple taints are applied to a node, new Pods will be prevented from landing on the node, and running Pods will be evicted. There are three effect settings that can be applied to taints and tolerations: NoSchedule prevents new Pods from being scheduled on the tainted node, unless the toleration effect is also set to NoSchedule. PreferNoSchedule encourages–but does not strictly prohibit–Pod scheduling, which means that the Pod might still be scheduled. NoExecute evicts existing Pods and prevents new ones from landing on the tainted node, unless the Pods have a toleration set to NoExecute. Constraining Pods to particular nodes adds additional complexity to cluster management. GKE helps abstract some of that complexity by using node pools to place Pods on the correct hardware. This is because node pools have the same hardware, and NodeSelectors can be used to direct Pods to the correct node pool. Let’s demonstrate this concept through an example of a GKE cluster that has two node pools, one named “High CPU” and the other named “High Memory.” GKE automatically labels the nodes in each node pool with the specified name, so that NodeSelectors can direct Pods to the appropriate nodes. Imagine that a fleet of frontend web servers requires a moderate increase of vCPUs relative to memory. In this case, the nodeSelectors identify nodes with the “High CPU” name and GKE will direct those Pods to the “High CPU” node pool.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.