01 引言

声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记

在前前面的博客《k8s教程（14）-pod之node亲和性调度》，我们知道了pod的亲和性（Pod Affinity）一般适用于以下场景：

存在某些相互依赖、频繁调用的Pod，它们需要被尽可能地部署在同一个Node节点、机架、机房、网段或者区域(Zone)内，这就是Pod之间的亲和性

反之，出于避免竞争或者容错的需求，我们也可能使某些Pod尽可能地远离某些特定的Pod，这就是Pod之间的反亲和性或者互斥性（Pod Anti Affinity），也就是本文要讲的pod互斥调度。

02 pod亲和性调度与互斥性调度

亲和性与互斥性可以理解为就是相关联的两种或多种Pod是否可以在同一个拓扑域中共存或者互斥。

那么什么是拓扑域？

2.1 拓扑域

拓扑域的概念：

一个拓扑域由一些Node节点组成，这些Node节点通常有相同的地理空间坐标，比如在同一个机架、机房或地区；
一般用region表示机架、机房等的拓扑区域，用Zone表示地区这样跨度更大的拓扑区域；
极端情况下，我们也可以认为一个Node就是一个拓扑区域。

k8s内置了如下一些常用的默认拓扑域，主要是为了确定各个节点所属的拓扑域：

默认拓扑域	描述
kubernetes.io/hostname	在Node节点初始化时，controller–manager会为Node打上该标签
topology.kubernetes.io/region	公有云厂商提供的Kubernetes服务或者使用cloud-controller-manager创建的集群，会给Node打上该标签
topology.kubernetes.io/zone	同上

2.2 举例

Pod亲和与互斥的调度是通过在Pod的定义上增加topologyKey 属性来声明对应的目标拓扑区域内几种相关联的Pod要 “在一起或不在一起”。

与节点亲和相同,Pod亲和与互斥的条件设置也是requiredDuringSchedulingIgnoredDuringExecution和
preferredDuringSchedulingIgnoredDuringExecution：

Pod的亲和性被定义于PodSpec的affinity字段的podAffinity子字段中；
Pod间的互斥性则被定义于同一层次的podAntiAffinity子字段中.

下面通过实例来说明Pod间的亲和性和互斥性策略设置。

2.2.1 参照目标pod

首先，创建一个名为pod-flag的Pod，带有标签security=S1和app=nginx，后面的例子将使用pod-flag作为Pod亲和与互斥的目标Pod：

apiversion:v1
kind:Pod
metadata:name:pod-flaglabels:security:"S1"app:"nginx"
spec:containers:-name:nginximage:nginx

2.2.2 pod的亲和性调度

下面创建第2个Pod来说明Pod的亲和性调度，这里定义的亲和标签是 “security=S1”，对应上面的Pod “pod-flag”，topologyKey的值被设置为 “kubernetes.io/hostname“：

apiVersion:vl
kind:Pod
metadata:name:pod-affinity
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution: - labelSelector:matchExpressions:- key:securityoperator:Invalues:-S1topologyKey:kubernetes.io/hostname containers:- name:with-pod-affinityimage:gcr.io/google_containers/pause:2.0

创建Pod之后，使用kubectl get pods -o wide命令可以看到，这两个Pod在同
一个Node上运行。

在创建这个Pod之前，删掉这个节点的 kubernetes.io/hostname 标签，重复上面的创建步骤，将会发现Pod一直处于Pending状态，这是因为找不到满足条件的Node了。

2.2.3 pod的互斥性调度

创建第3个Pod，我们希望它不与目标Pod运行在同一个Node上：

apiversion:v1
kind:Pod
metadata:name:anti-affinity
spec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution: - labelSelector:matchExpressions:- key:securityoperator:Invalues:-S1topologyKey:topology.kubernetes.io/zone podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution: - labelSelector:matchExpressions:- key:appoperator:Invalues:-nginxtopologyKey:kubernetes.io/hostnamecontainers:- name:anti-affinityimage:gcr.io/google_containers/pause:2.0

这里要求这个新Pod与security=S1的Pod为同一个zone，但是不与app=nginx 的Pod为同一个Node。

创建Pod之后，同样用kubectl get pods -o wide来查看，会看到新的Pod被调度到了同一Zone内的不同Node上。

03 其它

与节点亲和性类似，Pod亲和性的操作符也包括In、NotIn、Exists、 DoesNotExist、Gt、Lt。

原则上，topologyKey可以使用任意合法的标签Key赋值，但是出于性能和安全方面的考虑，对topologyKey有如下限制：

在Pod亲和性和RequiredDuringScheduling的Pod互斥性的定义中，不允许使用空的topologyKey；
如果Admission controller包含了LimitPodHardAntiAffinityTopology，那么针对Required DuringScheduling的Pod互斥性定义就被限制为kubernetes.io/hostname，要使用自定义的topologyKey，就要改写或禁用该控制器。
在PreferredDuringScheduling类型的Pod互斥性定义中，空的
topologyKey会被解释为kubernetes.io/hostname、failure-
domain.beta.kubernetes.io/zone 及 failure-domain.beta.kubernetes.io/region的组合。
如果不是上述情况，就可以采用任意合法的topologyKey了。

PodAffinity规则设置的注意事项如下：

除了设置Label Selector和topologyKey，用户还可以指定Namespace列表
进行限制。同样，使用Label Selector对Namespace进行选择，Namespace的定义和Label Selector及topologyKey同级，省略Namespace的设置，表示使用定义了 affinity/anti-affinity的Pod所在的命名空间。如果Namespace被设置为空值 (“”),则表示所有命名空间.
在所有关联requiredDuringSchedulingIgnoredDuringExecution的
matchExpressions 全都满足之后，系统才能将Pod调度到某个Node上。