节点污点可以用来让pod远离特定的节点，尽量在不修改已有pod信息的前提，通过在节点添加污点信息，来拒绝pod在某些节点上的部署。
而现在介绍一种叫做节点亲缘性，通过明确的在pod中添加的信息，来决定一个pod可以或者不可以被调度到哪些节点上。
对比节点亲缘性和节点选择器
在早期版本的Kubernetes中，初始的节点亲缘性机制，就是pod描述中的nodeSelector字段。节点必须包含所有pod对应字段中的指定label,才能成为pod调度的目标节点。
节点选择器实现简单，但是它不能满足你的所有需求。正因为如此，一种更强大的机制被引入。节点选择器最终会被弃用，所以现在了解新的节点亲缘性机制就变得重要起来。
与节点选择器类似，每个pod可以定义自己的节点亲缘性规则。这些规则可以允许指定硬性限制或者偏好。如果指定一种偏好的话，你将告知Kubernetes对于某个特定的pod,它更倾向于调度到某些节点上，之后Kubernetes将尽量把这个pod调度到这些节点上面。如果没法实现的话，pod将被调度到其他某个节点上。
检查默认的节点标签
节点亲缘性根据节点的标签来进行选择，这点跟节点选择器是一致的。现在检查一个GoogleKubernetes引擎集群(GKE)中节点的标签，来看一下它们默认的标签是什么，如以下代码所示。
#代码16.7GKE节点的默认标签$kubectldescribenodegke-kubia-default-pool-db274c5a-mjnfName:gke-kubia-default-pool-db274c5a-mjnfRole:Labels:beta.kubernetes.io/arch=amd64beta.kubernetes.io/fluentd-ds-ready=truebeta.kubernetes.io/instance-type=f1-microbeta.kubernetes.io/os=linuxcloud.google.com/gke-nodepool=default-poolfailure-domain.beta.kubernetes.io/region=europe-west1#最后这三个标签对于节点亲缘性来说最为重要failure-domain.beta.kubernetes.io/zone=europe-west1-dkubernetes.io/hostname=gke-kubia-default-pool-db274c5a-mjnf这个节点有很多标签，但涉及节点亲缘性和pod亲缘性时，最后三个标签是最重要的。这三个标签的含义如下：
这三个以及其他标签，将被用于pod亲缘性规则。在第三章中，你己经学会如何给一个节点添加自定义标签，并且在pod的节点选择器中使用它。可以通过给pod加上节点选择器的方式，将节点部署到含有这个自定义标签的节点上。现在，你将学习到怎么用节点亲缘性规则实现同样的功能。
有这么一个例子，使用了节点选择器使得需要GPU的pod只被调度到有GPU的节点上。包含了nodeSelector字段的pod描述如以下代码所示。
#代码16.8使用了节点选择器的pod:kubia-gpu-nodeselector.yamlapiVersion:v1kind:Podmetadata:name:kubia-gpuspec:nodeSelector:gpu:"true"containers:-image:luksa/kubia#这个pod会被调度到包含了gpu=true标签的节点上name:kubianodeSelector字段表示，pod只能被部署在包含了gpu=true标签的节点上。如果将节点选择器替换为节点亲缘性规则，pod定义将会如以下代码清单所示。
#代码16.9使用了节点亲缘性规则的pod:kubia-gpu-nodeaffinity.yamlapiVersion:v1kind:Podmetadata:name:kubia-gpuspec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchExpressions:-key:gpuoperator:Invalues:-"true"containers:-image:luksa/kubianame:kubia首先会注意到的是，这种写法比简单的节点选择器要复杂得多，但这是因为它的表达能力更强，再详细看一下这个规则。
较长的节点亲缘性属性名的意义
把这个名字分成两部分，然后分别看下它们的含义：
目前，当你知道当前的亲缘性规则只会影响正在被调度的pod，并且不会导致己经在运行的pod被剔除时，情况可能会更简单一些。这就是为什么目前的规则都是以IgnoredDuringExecution结尾的。最终，Kubernetes也会支持RequiredDuringExecution，表示如果去除掉节点上的某个标签，那些需要节点包含该标签的pod将会被剔除，但是，Kubernetes目前还不支持次特性。所以，可以暂时不去关心这个长字段的第二部分。
了解节点选择器条件
记住上一节所解释的内容，将更容易理解nodeSelectorTerms和matchExpressions字段，这两个字段定义了节点的标签必须满足哪一种表达式,才能满足pod调度的条件。样例中的单个表达式比较容易理解，节点必须包含一个叫作gpu的标签，并且这个标签的值必须是true。
因此，这个pod只会被调度到包含gpu=true的节点上。如图16.2所示。
现在，更有趣的部分来了，节点亲缘性也可以在调度时指定节点的优先级，将在接下来的部分看到。
最近介绍的节点亲缘性的最大好处就是，当调度某一个pod时，指定调度器可以优先考虑哪些节点，这个功能是通过preferredDuringSchedulingIgnoredDuringExecution字段来实现的。
想象一下拥有一个跨越多个国家的多个数据中心，每一个数据中心代表了一个单独的可用性区域。在每个区域中，有一些特定的机器，只提供给你自己或者你的合作公司使用。现在，你想要部署一些pod,希望将pod优先部署在区域zone1,并且是为你公司部署预留的机器上。如果你的机器没有足够的空间用于这些pod,或者出于其他一些重要的原因不希望这些pod调度到上面，那么就会调度到其他区域的其他机器上面，这种情况你也是可以接受的。节点亲缘性就可以实现这样的功能。
给节点加上标签
首先，节点必须加上合适的标签。每个节点需要包含两个标签，一个用于表示所在的这个节点所归属的可用性区域，另一个用于表示这是一个独占的节点还是一个共享的节点。
在接下来假设双节点的集群环境，将使用这个集群中的两个工作节点，当然也可以使用GKE或者其他多节点的集群。
首先，给这些节点加上标签，如以下代码所示。
#代码16.10给节点加上标签$kubectllabelnodenode1.k8savailability-zone=zone1node"node1.k8s"labeled$kubectllabelnodenode1.k8sshare-type=dedicatednode"node1.k8s"labeled$kubectllabelnodenode2.k8savailability-zone=zone2node"node2.k8s"labeled$kubectllabelnodenode2.k8sshare-type=sharednode"node2.k8s"labeled$kubectlgetnode-Lavailability-zone-Lshare-typeNAMESTATUSAGEVERSIONAVAILABILITY-ZONESHARE-TYPEmaster.k8sReady4dv1.6.4
当这些节点的标签设置好，现在可以创建一个Deployment，其中优先选择zone1中的dedicated节点。下面的代码清单显示了这个Deployment的描述。
#代码16.11含有优先级节点亲缘性规则的Deployment:preferred-deployment.yamIapiVersion:extensions/v1beta1kind:Deploymentmetadata:name:prefspec:replicas:5template:metadata:labels:app:prefspec:affinity:nodeAffinity:preferredDuringSchedulingIgnoredDuringExecution:#指定优先级，这不是必需的-weight:80#这块是节点有限调度到zone1，这是最重要的偏好preference:matchExpressions:-key:availability-zoneoperator:Invalues:-zone1-weight:20#同时优先调度pod到独占节点，但是该优先级为zone1优先级的1/4preference:matchExpressions:-key:share-typeoperator:Invalues:-dedicatedcontainers:-args:-sleep-"99999"image:busyboxname:main查看上面的代码清单，定义了一个节点亲缘性优先级，而不是强制要求(后面会讲解)。想要pod被调度到包含标签availability-zone=zone1以及share-type=dedicated的节点上。第一个优先级规则是相对重要的，因此将其weight设置为80，而第二个优先级规则就不那么重要（weight设置为20)。
了解节点优先级是如何工作的
如果集群包含多个节点，当调度上面的代码中的Deploymentpod时，节点将会分成4个组，如图16.3所示。那些包含availability-zone以及share-type标签，并且匹配pod亲缘性的节点，将排在最前面。然后，由于pod的节点亲缘性规则配置的权重，接下来是zone1的shared节点，然后是其他区域的dedicated节点，优先级最低的是剩下的其他节点。
在一个包含两个节点的集群中部署节点
如果在一个包含两个节点的集群中创建该部署，看到的最多的应该是pod被部署在了node1上面。检查下面的代码清单看情况是否属实。
#代码16.12查看pod调度情况$kubectlgetpo-owideNAMEREADYSTATUSRESTARTSAGEIPNODEpref-607515-1rnwv1/1Running04m10.47.0.1node2.k8spref-607515-27wp01/1Running04m10.44.0.8node1.k8spref-607515-5xd0z1/1Running04m10.44.0.5node1.k8spref-607515-jx9wt1/1Running04m10.44.0.4node1.k8spref-607515-mlgqm1/1Running04m10.44.0.6node1.k8s5个pod被创建，其中4个部署在了node1,1个部署在了node2。为什么会有1个pod会被调度到node2而不是node1原因是除了节点亲缘性的优先级函数，调度器还是使用其他的优先级函数来决定节点被调度到哪。其中之一就是SelectorSpreadPriority函数，这个函数确保了属于同一个ReplicaSet或者Service的pod,将分散部署在不同节点上，以避免单个节点失效导致这个服务也宕机。这就是有1个pod被调度到node2的最大可能。
可以去试着扩容部署至20个实例或更多，将看到大多数的pod被调度到node1。如果没有设置任何节点亲缘性优先级，pod将会被均匀地分配在两个节点上面。
上面也简单介绍了简单的原理以及过程，现在介绍更多的规则以及案例。
节点亲和调度分成软策略(soft)和硬策略(hard)，在软策略下，如果没有满足调度条件的节点，pod会忽略这条规则，继续完成调度。
表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，pod也会继续运行。
表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中RequiredDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，则重新选择符合要求的节点。
表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。
表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。其中RequiredDuringExecution表示如果后面节点标签发生了变化，满足了条件，则重新调度到满足条件的节点。
再来一个官方示例
apiVersion:v1kind:Podmetadata:name:with-node-affinityspec:affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchExpressions:-key:kubernetes.io/e2e-az-nameoperator:Invalues:-e2e-az1-e2e-az2preferredDuringSchedulingIgnoredDuringExecution:-weight:1preference:matchExpressions:-key:another-node-label-keyoperator:Invalues:-another-node-label-valuecontainers:-name:with-node-affinityimage:gcr.io/google_containers/pause:2.0这个pod同时定义了requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution两种nodeAffinity。第一个要求pod运行在特定AZ的节点上，第二个希望节点最好有对应的another-node-label-key:another-node-label-value标签。
这里的匹配逻辑是label在某个列表中，可选的操作符有：
如果nodeAffinity中nodeSelector有多个选项，节点满足任何一个条件即可；如果matchExpressions有多个选项，则节点必须同时满足这些选项才能运行pod。