ing nodes get ordered by weight. In the last stage the Pod gets a node assigned, which is the primary outcome of the scheduling process. In most cases, it is better to let the scheduler do the Pod-to-node assignment and not micromanage the placement logic. However, on some occasions, you may want to force the assignment of a Pod to a specific node or a group of nodes. This assignment can be done using a node selector.  .spec.nodeSelector  is Pod field and specifies a map of key-value pairs that must be present as labels on the node for the node to be eligible to run the Pod. For example, say you want to force a Pod to run on a specific node where you have SSD storage or GPU acceleration hardware. With the Pod defi‐ nition in Example 6-3 that has  nodeSelector  matching  disktype: ssd , only nodes that are labeled with  disktype=ssd  will be eligible to run the Pod. Set of node labels a node must match to be considered to be the node of this Pod In addition to specifying custom labels to your nodes, you can use some of the default labels that are present on every node. Every node has a unique  kubernetes.io/host name  label that can be used to place a Pod on a node by its hostname. Other default labels that indicate the OS, architecture, and instance-type can be useful for place‐ ment too. Kubernetes supports many more flexible ways to configure the scheduling processes. One such a feature is node affinity, which is a generalization of the node selector approach described previously that allows specifying rules as either required or pre‐ ferred. Required rules must be met for a Pod to be scheduled to a node, whereas pre‐ ferred rules only imply preference by increasing the weight for the matching nodes without making them mandatory. Besides, the node affinity feature greatly expands the types of constraints you can express by making the language more expressive with operators such as  In ,  NotIn ,  Exists ,  DoesNotExist ,  Gt , or  Lt . Example 6-4 demon‐ strates how node affinity is declared. Solution  |  51 Node Affinity Example 6-3. Node selector based on type of disk available apiVersion : v1 kind : Pod metadata : name : random-generator spec : containers : -  image : k8spatterns/random-generator:1.0 name : random-generator nodeSelector : disktype : ssd