霸州市建设局网站,十大网站建设,代理公司注册机构,网站建设优化服务咨询一、节点选择 nodeSelector 提供了一个非常简单的方式#xff0c;将 Pod 限定到包含特定标签的节点上。亲和性与反亲和性#xff08;affinity / anti-affinity#xff09;特性则极大地扩展了限定的表达方式。主要的增强点在于#xff1a; 表达方式更加有效#xff08;不仅…一、节点选择 nodeSelector 提供了一个非常简单的方式将 Pod 限定到包含特定标签的节点上。亲和性与反亲和性affinity / anti-affinity特性则极大地扩展了限定的表达方式。主要的增强点在于 表达方式更加有效不仅仅是多个精确匹配表达式的“和”关系 可以标识该规则为“soft” / “preference” 软性的、偏好的而不是 hard requirement必须的此时如果调度器发现该规则不能被满足Pod 仍然可以被调度 可以对比节点上或其他拓扑域 topological domain已运行的其他 Pod 的标签而不仅仅是节点自己的标签此时可以定义类似这样的规则某两类 Pod 不能在同一个节点或拓扑域上共存
二、节点亲和性 节点亲和性node affinity的概念与 nodeSelector 相似可以基于节点的标签来限定 Pod 可以被调度到哪些节点上。
当前支持两种类型的节点亲和性 requiredDuringSchedulingIgnoredDuringExecution hard目标节点必须满足此条件 以及 preferredDuringSchedulingIgnoredDuringExecution soft目标节点最好能满足此条件。名字中 IgnoredDuringExecution 意味着如果 Pod 已经调度到节点上以后节点的标签发生改变使得节点已经不再匹配该亲和性规则了Pod 仍将继续在节点上执行这一点与 nodeSelector 相似。将来Kubernetes 将会提供 requiredDuringSchedulingRequiredDuringExecution 这个选项该选项与 requiredDuringSchedulingIgnoredDuringExecution 相似不同的是当节点的标签不在匹配亲和性规则之后Pod 将被从节点上驱逐。
requiredDuringSchedulingIgnoredDuringExecution 的一个例子是只在 Intel CPU 上运行该 PodpreferredDuringSchedulingIgnoredDuringExecution 的一个例子是尽量在高可用区 XYZ 中运行这个 Pod但是如果做不到也可以在其他地方运行该 Pod。
PodSpec 中通过 affinity.nodeAffinity 字段来定义节点亲和性
apiVersion: v1kind: Podmetadata:name: 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: node-affinityimage: k8s.gcr.io/pause:2.0此处的亲和性规则表明该 Pod 只能被调度到包含 key 为 kubernetes.io/e2e-az-name 且 value 为 e2e-az1 或 e2e-az2 的标签的节点上。此外如果节点已经满足了前述条件将优先选择包含 key 为 another-node-label-key 且 value 为 another-node-label-value 的标签的节点。
例子中使用了操作符 In。节点亲和性支持如下操作符In、NotIn、Exists、DoesNotExist、Gt、Lt。使用 NotIn 和 DoesNotExist 可以实现节点反亲和性node anti-affinity的效果或者也可以使用 [污点 为节点排斥某类 Pod。
如果某个 Pod 同时指定了 nodeSelector 和 nodeAffinity则目标节点必须同时满足两个条件才能将 Pod 调度到该节点上。
如果为 nodeAffinity 指定多个 nodeSelectorTerms则目标节点只需要满足任意一个 nodeSelectorTerms 的要求就可以将 Pod 调度到该节点上。
如果为 nodeSelectorTerms 指定多个 matchExpressions则目标节点必须满足所有的 matchExpressions 的要求才能将 Pod 调度到该节点上。
当 Pod 被调度到某节点上之后如果移除或者修改节点的标签Pod 将仍然继续在节点上运行。换句话说节点亲和性规则只在调度该 Pod 时发生作用。
preferredDuringSchedulingIgnoredDuringExecution 中的 weight 字段取值范围为 1-100。对于每一个满足调度要求的节点资源请求、亲和性/反亲和性规则等调度器将遍历该节点匹配的 preferredDuringSchedulingIgnoredDuringExecution 中所有的weight 并求和。此求和结果将与节点的其他优先级计算的得分合并。得分最高的节点被优先选择。
三、Pod亲和性与反亲和性 Pod之间的亲和性与反亲和性inter-pod affinity and anti-affinity可以基于已经运行在节点上的 Pod 的标签而不是节点的标签来限定 Pod 可以被调度到哪个节点上。此类规则的表现形式是
当 X 已经运行了一个或者多个满足规则 Y 的 Pod 时待调度的 Pod 应该或者不应该 - 反亲和性在 X 上运行
规则 Y 以 LabelSelector 的形式表述附带一个可选的名称空间列表
与节点不一样Pod 是在名称空间中的因此Pod的标签是在名称空间中的针对 Pod 的 LabelSelector 必须同时指定对应的名称空间
X 是一个拓扑域的概念例如节点、机柜、云供应商可用区、云供应商地域等。X 以 topologyKey 的形式表达该 Key代表了节点上代表拓扑域topology domain的一个标签。 apiVersion: v1kind: Podmetadata:name: with-pod-affinityspec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: securityoperator: Invalues:- S1topologyKey: failure-domain.beta.kubernetes.io/zonepodAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: securityoperator: Invalues:- S2topologyKey: failure-domain.beta.kubernetes.io/zonecontainers:- name: with-pod-affinityimage: k8s.gcr.io/pause:2.0该 Pod 的 affinity 定义了一个 Pod 亲和性规则和一个 Pod 反亲和性规则例子中 podAffinity 是 requiredDuringSchedulingIgnoredDuringExecution而 podAntiAffinity 则是 preferredDuringSchedulingIgnoredDuringExecution。
Pod 亲和性规则要求该 Pod 可以被调度到的节点所在的可用区 zone 必须已经有一个已经运行的 Pod 包含标签 keysecurityvalueS1或者更准确地说节点必须满足如下条件
节点包含 key 为 failure-domain.beta.kubernetes.io/zone 的标签假设该标签的值为 V
至少有一个包含 key 为 failure-domain.beta.kubernetes.io/zone 且 value 为 V 的标签的节点已经运行了一个包含标签 key 为 security 且 value 为 S1 的 Pod
Pod 反亲和性规则要求该 Pod 最好不要被调度到已经运行了包含 key 为 security 且 value 为 S2 的标签的 Pod 的节点上或者更准确地说必须满足如下条件
如果 topologyKey 是 failure-domain.beta.kubernetes.io/zone则Pod不能被调度到同一个 zone 中的已经运行了包含标签 security: S2 的节点上
原则上 topologyKey 可以是任何合法的标签 key。然而处于性能和安全的考虑仍然对 topologyKey 有如下限制
对亲和性以及 requiredDuringSchedulingIgnoredDuringExecution Pod 反亲和性topologyKey 不能为空
对 requiredDuringSchedulingIgnoredDuringExecution Pod 反亲和性管理控制器 LimitPodHardAntiAffinityTopology 被用来限制 topologyKey 必须为 kubernetes.io/hostname。如果想要使用其他的自定义 topology必须修改该管理控制器或者将其禁用
对 preferredDuringSchedulingIgnoredDuringExecution Pod 反亲和性如果 topologyKey 为空则代表所有的 topology 此时不局限于 kubernetes.io/hostname、failure-domain.beta.kubernetes.io/zone 和 failure-domain.beta.kubernetes.io/region 的组合
除了上述的情形以外topologyKey 可以是任何合法的标签 Key
除了 labelSelector 和 topologyKey 以外还可以指定一个 namespaces 的列表用作 labelSelector 的作用范围与 labelSelector 和 topologyKey 的定义为同一个级别。如果不定义或者该字段为空默认为 Pod 所在的名称空间。
所有与 requiredDuringSchedulingIgnoredDuringExecution 亲和性和反亲和性关联的 matchExpressions 必须被满足Pod 才能被调度到目标节点。
