k8s教程（15）-pod之亲和性与互斥性调度
文章目录
- 01 引言
- 02 pod亲和性调度与互斥性调度
-
- 2.1 拓扑域
- 2.2 举例
-
- 2.2.1 参照目标pod
- 2.2.2 pod的亲和性调度
- 2.2.3 pod的互斥性调度
- 03 其它
- 04 文末
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-flag
labels:
security:"S1"
app:"nginx"
spec:
containers:
-name:nginx
image: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:security
operator:In
values:
-S1
topologyKey:kubernetes.io/hostname
containers:
- name:with-pod-affinity
image: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:security
operator:In
values:
-S1
topologyKey:topology.kubernetes.io/zone
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key:app
operator:In
values:
-nginx
topologyKey:kubernetes.io/hostname
containers:
- name:anti-affinity
image: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上。
04 文末
本文主要讲解了pod的亲和性调度与互斥性调度的概念及例子，并简单地介绍了拓扑域的概念，希望能帮助到大家，谢谢大家的阅读，本文完！