Example 6-7. Pod tolerating node taints Tolerate (i.e., consider for scheduling) nodes, which have a taint with key  node- role.kubernetes.io/master . On production clusters, this taint is set on the master node to prevent scheduling of Pods on the master. A toleration like this allows this Pod to be installed on the master nevertheless. Tolerate only when the taint specifies a  NoSchedule  effect. This field can be empty here, in which case the toleration applies to every effect. There are hard taints that prevent scheduling on a node ( effect=NoSchedule ), soft taints that try to avoid scheduling on a node ( effect=PreferNoSchedule ), and taints that can evict already running Pods from a node ( effect=NoExecute ). Taints and tolerations allow for complex use cases like having dedicated nodes for an exclusive set of Pods, or force eviction of Pods from problematic nodes by tainting those nodes. You can influence the placement based on the application’s high availability and per‐ formance needs, but try not to limit the scheduler much and back yourself into a cor‐ ner where no more Pods can be scheduled, and there are too many stranded resources. For example, if your containers’ resource requirements are too coarse- grained, or nodes are too small, you may end up with stranded resources in nodes that are not utilized. In Figure 6-2, we can see node A has 4 GB of memory that cannot be utilized as there is no CPU left to place other containers. Creating containers with smaller resource requirements may help improve this situation. Another solution is to use the Kuber‐ netes  descheduler , which helps defragment nodes and improve their utilization. Solution  |  55 apiVersion : v1 kind : Pod metadata : name : random-generator spec : containers : -  image : k8spatterns/random-generator:1.0 name : random-generator tolerations : -  key : node-role.kubernetes.io/master operator : Exists effect : NoSchedule