k8s教程（pod篇）-亲和性与互斥性调度

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的亲和性调度与互斥性调度的概念及例子，并简单地介绍了拓扑域的概念，希望能帮助到大家，谢谢大家的阅读，本文完！