1. 亲缘性调度
通过给节点设置污点,可以让Pod选择容忍或者远离这些节点,那么通过设置节点亲缘性(node affinity),可以让Pod调度到特点的节点上,就像我住酒店会选择无烟房一样。在前面的课程我们使用Node Selector将Pod 运行在有制定标签的Node上,那么亲缘性调度可以理解为新一代的Node Selector,业务未来Node Selector会被完全弃用,因为亲缘性调度更加的强大,当然也更加的复杂。
1.1. Node 亲和性
Node亲和性在概念上类似于nodeSelector – 它能够基于node标签约束哪些pod能够被分配到node上。
目前有两种类型的node亲和性,叫做 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution。您可以认为它们分别是 “硬性” 和 “软性” 的,即前者要求 pod 必须满足指定的规则才能调度到 node 上(就像 nodeSelector,但使用更具表达性的语法),后者指定 偏向,即让 scheduler 尝试但是不保证完全满足规则。
与 nodeSelector 工作方式类似,名称中的 “IgnoredDuringExecution” 部分意味着,如果一个 node 的标签在运行时发生改变,从而导致pod的亲和性规则不再被满足时,pod 也仍然会继续运行在 node 上。以后我们计划提供 requiredDuringSchedulingRequiredDuringExecution,这类似于 requiredDuringSchedulingIgnoredDuringExecution,但是它会从不再满足 pod 的 node 亲和性的 node 上驱逐 Pod。
因此 requiredDuringSchedulingIgnoredDuringExecution 的一个例子是 “只能在有 Intel CPU 的 node 上运行 pod”,preferredDuringSchedulingIgnoredDuringExecution 的例子是 “尝试在可用域 XYZ 的范围内运行 pod,但是如果不满足,那么也允许在其它地方运行 pod”。
没错,上面这段描述如果让你有点晕了,再次证明了Node 亲和性是真的比Node Selector复杂太多了!!!
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0
这个 node 亲和性规则意思是,pod 只能被调度在标签满足 key 为 kubernetes.io/e2e-az-name 并且 value 为 e2e-az1 或者 e2e-az2 的 node 上。另外,在满足条件的所有 node 中,更倾向于拥有 key 为 another-node-label-key 并且 value 为 another-node-label-value 的标签的 node。
您可以在例子中看到 In 运算符。新的 node 亲和性语法支持以下运算符:In、NotIn、Exists、DoesNotExist、Gt 和 Lt。 实际上并没有明确的 “node 反亲和性” 概念,不过 NotIn 和 DoesNotExist 提供了这种行为。
如果您指定了 nodeSelector 和 nodeAffinity,那么 pod 必须满足这 两个 规则才能调度到候选节点上。
如果您在 nodeAffinity 类型中指定了多个 nodeSelectorTerms,那么 pod 将会被调度到 只要满足其中一个 nodeSelectorTerms 的 node 上。
如果您在 nodeSelectorTerms 中指定了多个 matchExpressions,那么 pod 将会被调度到 满足所有 matchExpressions 的 node 上。