k8s教程(15)-pod之亲和性与互斥性调度

时间:2022-12-04 20:02:13

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-flagPod,带有标签security=S1app=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

这里要求这个新Podsecurity=S1的Pod为同一个zone,但是不与app=nginxPod为同一个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的亲和性调度与互斥性调度的概念及例子,并简单地介绍了拓扑域的概念,希望能帮助到大家,谢谢大家的阅读,本文完!