01 引言
声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记
在前面的博客《k8s教程（13）-pod定向调度》，讲解了Pod使用NodeSelector来进行定向调度的概念及使用案例，同时也简单介绍了一些预定义的标签。
NodeAffinity意为Node亲和性的调度策略，是用于替换NodeSelector的全新调度策略，本文来讲解下。
02 Node亲和性调度
在前面的博客，我们知道如如果要做到定向调度，首先需要给node节点搭上标签，然后在Pod的资源文件声明NodeSelector即可。但是这样的操作限制太死了，很多时候我们希望调度到“满足一定条件”的node，也就是这里要将的NodeAffinity亲和度调度了。
2.1 亲和性调度分类
目前有两种节点亲和性表达：
| 表达式 | 含义 |
|---|---|
RequiredDuringSchedulingIgnoredDuringExecution |
必须满足指定的规则才可以调度Pod到Node上（功能与nodeSelector很像，但是使用的是不同的语法)，相当于限制 |
PreferredDuringSchedulingIgnoredDuringExecution |
强调优先满足指定规则，调度器会尝试调度Pod到Node上，但并不强求，相当于软限制 |
多个优先级规则还可以设置权重(weight)值，以定义执行的先后顺序。
IgnoredDuringExecution的意思是：如果一个Pod所在的节点在Pod运行期间 标签发生了变更，不再符合该Pod的节点亲和性需求，则系统将忽略Node上Label 的变化，该Pod能继续在该节点上运行。
2.2 举例
有如下要求：
- requiredDuringSchedulingIgnoredDuringExecution:要求只运行在amd64的节点上(beta.kubernetes.io/arch In amd64)；
- preferredDuringSchedulingIgnoredDuringExecution:要求尽量运行在磁盘类型为ssd(disk-type In ssd)的节点上；
则资源文件的定义如下：
apiVersion:vl
kind:Pod
metadata:
name:with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms
- matchExpressions:
- key:beta.kubernetes.io/arch
operator:In
values:
- amd64
preferredDuringSchedulingIgnoredDuringExecution:
- weight:1
preference:
matchExpressions:
- key:disk-type
operator:In
values:
- ssd
containers:
- name:with-node-affinity
image:gcr.io/google containers/pause:2.0
从上面的配置中可以看到In操作符，NodeAffinity语法支持的操作符包括In、NotIn、Exists、DoesNotExist、Gt、Lt。虽然没有节点排斥功能,但是用NotIn 和DoesNotExist就可以实现排斥的功能了。
2.3 注意事项
- 如果同时定义了
nodeSelector和nodeAffinity，那么必须两个条件都得到满足，Pod才能最终运行在指定的Node上； - 如果
nodeAffinity指定了多个nodeSelectorTerms，那么其中一个能匹配成功即可； - 如果在
nodeSelectorTerms中有多个matchExpressions，则一个节点必须满足所有matchExpressions才能运行该Pod。
03 文末
本文主要讲解的是node亲和性调度的两种表达式的含义以及举例（requiredDuringSchedulingIgnoredDuringExecution和preferredDuringSchedulingIgnoredDuringExecution），希望能帮助到大家，谢谢大家的阅读，本文完！
转载：https://blog.csdn.net/qq_20042935/article/details/127939824