Kubernetes1.6新特性：POD高级调度-亲和性/反亲和性特性

转载

云原生总监 2022-12-16 19:30:47 博主文章分类：kubernetes

文章标签 Pod 取值 html 文章分类 运维

(一) 核心概念

Pod是kubernetes中的核心概念，kubernetes对于Pod的管理也就是对Pod生命周期的管理以及对Pod进行调度管理。

Kubernetes早期版本使用系统默认调度器来对Pod进行统一调度管理，在1.2版本中增加了多个调度器特性，多个调度器可以并行调度不同的Pod，并且可以允许用户自己定义新的调度器并以插件的方式供kubernetes使用。

在1.6版本中对POD调度进行了增强，这里称之为“高级调度”，涉及到多个调度器配置变化、节点亲和性/反亲和性特性、Pod亲和性/反亲和性特性、污点和容忍特性、报告节点问题特性。

在1.6版本这些“高级调度”特性中，多个调度器配置变化、节点亲和性/反亲和性特性、Pod亲和性/反亲和性特性、污点和容忍特性，这四个特性属于β特性，报告节点问题特性属于α特性，所以大家在使用的时候应该注意。

(二) 亲和性/反亲和性介绍

我们先来看看1.6版本中Pod相关的几个核心结构体：

Kubernetes1.6新特性：POD高级调度-亲和性/反亲和性特性_取值

在1.6版本中，PodSpec结构体中新增了四个属性，分别是AutomountServiceAccountToken、Affinity、SchedulerName、Tolerations。其中Affinity属性对应结构体Affinity，负责节点亲和性/反亲和性特性和Pod亲和性/反亲和性特性；Tolerations属性对应结构体Toleration，负责污点和容忍特性；SchedulerName属性就是这篇文章要介绍的多个调度器配置变化。其中结构体Affinity和结构体Toleration在1.5版本中已经存在了，但是并不是通过PodSpec结构体中Affinity和Tolerations两个属性进行关联的。

对于1.6中亲和性/反亲和性相关结构体，可以参考下图：

Kubernetes1.6新特性：POD高级调度-亲和性/反亲和性特性_取值_02

其中结构体Affinity负责亲和性/反亲和性特性，其中有三个属性，分别是NodeAffinity、PodAffinity和PodAntiAffinity，这三个属性分别对应节点亲和性调度、Pod亲和性调度、Pod反亲和性调度。从这张结构体图可以发现，现在是不存在节点反亲和性特性的。

我们先来看看1.5版本中，是如何配置亲和性/反亲和性的：

1. annotations:  
2.   
3.   scheduler.alpha.kubernetes.io/affinity:……

我们在看看现在1.6版本中，是如何配置节点亲和性/反亲和性的：

1. spec:  
2.   
3.   Affinity:……

通过上面两个例子可以看出来，多个调度器这个特性从α版本变成β版本后，由原先使用annotations方式定义Pod变成了直接在spec中定义Pod。

1、节点亲和性介绍

节点亲和性NodeAffinity在概念上同nodeSelector是一致的。当前有两种节点亲和性类型：

1) requiredDuringSchedulingIgnoredDuringExecution

2) preferredDuringSchedulingIgnoredDuringExecution

其中requiredDuringSchedulingIgnoredDuringExecution类型是一个强行要求，表示节点必须满足条件才能够部署Pod，而preferredDuringSchedulingIgnoredDuringExecution是一个非强行要求，调度器会尝试去满足这个节点亲和性条件，但是如果没有满足节点亲和性条件的节点，那么就会将Pod部署在其他节点上。

对于“IgnoredDuringExecution”的意思是，当Pod在运行过程中，如果节点属性改变了，原有正在运行的Pod不满足NodeAffinity条件了，那么这个时候Pod还会继续运行，不会发生变化。以后kubernetes还会考虑增加“RequiredDuringExecution”相关类型，表示如果节点属性改变了，原有正在运行的Pod不满足NodeAffinity条件了，那么这个时候Pod就会逃离到满足NodeAffinity条件的节点上。

这里需要注意的是Pod配置中可以配置nodeSelector，在1.6版本中nodeSelector和NodeAffinity特性是同时支持的，但是在kubernetes以后版本中逐渐会使用NodeAffinity特性来替代nodeSelector。

2、 Pod亲和性/反亲和性介绍

在kubernetes1.4版本中就已经有了Pod亲和性和反亲和性特性了，在1.6版本中Pod亲和性有两种类型，Pod反亲和性也有两种类型，这两种类型都是相同的，分别是：

1) requiredDuringSchedulingIgnoredDuringExecution

2) preferredDuringSchedulingIgnoredDuringExecution

其中requiredDuringSchedulingIgnoredDuringExecution类型是一个强行要求，表示必须满足才能够部署Pod，而preferredDuringSchedulingIgnoredDuringExecution是一个非强行要求，这两种类型同NodeAffinity中介绍的两种类型作用是相同的。

这里需要注意的是在1.6版本中如果明确将AffinityInAnnotations属性设置成true，那么还会继续支持scheduler.alpha.kubernetes.io/affinity这种annotations方式的，但是在kubernetes以后版本中会取消这种使用方式。如果在1.6中没有明确将AffinityInAnnotations属性设置成true，那么是不支持scheduler.alpha.kubernetes.io/affinity这种annotations方式的。在1.6版本中，如果启用了scheduler.alpha.kubernetes.io/affinity这种annotations方式，那么如果在Pod的spec中定义了affinity，就按照spec中的affinity定义运行Pod，其他pod按照annotations方式运行。

(三) 配置亲和性反亲和性使用示例

1) 定义一个Pod，配置使用节点亲和性NodeAffinity条件

1. apiVersion: v1  
2.   
3. kind: Pod  
4.   
5. metadata:  
6.   
7.  name: with-node-affinity  
8.   
9. spec:  
10.   
11.  affinity:  
12.   
13.    nodeAffinity:  
14.   
15.      requiredDuringSchedulingIgnoredDuringExecution:  
16.   
17.        nodeSelectorTerms:  
18.   
19.        - matchExpressions:  
20.   
21.          - key: kubernetes.io/e2e-az-name  
22.   
23.            operator: In  
24.   
25.            values:  
26.   
27.            - e2e-az1  
28.   
29.            - e2e-az2  
30.   
31.      preferredDuringSchedulingIgnoredDuringExecution:  
32.   
33.      - weight: 1  
34.   
35.        preference:  
36.   
37.          matchExpressions:  
38.   
39.          - key: another-node-label-key  
40.   
41.            operator: In  
42.   
43.            values:  
44.   
45.            - test  
46.   
47.  containers:  
48.   
49.   -name: with-node-affinity  
50.   
51.     image: gcr.io/google_containers/pause:2.0

在这个例子中，Pod只能部署在标识了kubernetes.io/e2e-az-name的节点上，并且取值要是“e2e-az1”或“e2e-az2”。同时，满足上面条件的节点，最好也要满足标识了another-node-label-key，并且取值是“test”。

其中operator的取值包括In、NotIn、Exists、DoesNotExist、Gt和Lt。虽然我们没有看到节点反亲和性，但是通过对operator配置NotIn或DoesNotExist，是可以实现节点反亲和性需求的。

如果同时配置了nodeSelector和nodeAffinity，那么Pod会被部署到同时满足nodeSelector和nodeAffinity条件的节点上。

如果nodeAffinity配置了多个nodeSelectorTerms条件，那么只要有一个nodeSelectorTerms条件被满足就可以。

如果matchExpressions配置了多个条件，那么所有条件都需要被满足。

2) 定义一个Pod，配置使用pod亲和性/非亲和性条件

1. apiVersion: v1  
2.   
3. kind: Pod  
4.   
5. metadata:  
6.   
7.  name: with-pod-affinity  
8.   
9. spec:  
10.   
11.  affinity:  
12.   
13.    podAffinity:  
14.   
15.      requiredDuringSchedulingIgnoredDuringExecution:  
16.   
17.      - labelSelector:  
18.   
19.          matchExpressions:  
20.   
21.          - key: security  
22.   
23.            operator: In  
24.   
25.             values:  
26.   
27.            - S1  
28.   
29.        topologyKey: failure-domain.beta.kubernetes.io/zone  
30.   
31.    podAntiAffinity:  
32.   
33.      preferredDuringSchedulingIgnoredDuringExecution:  
34.   
35.      - weight: 100  
36.   
37.        podAffinityTerm:  
38.   
39.          labelSelector:  
40.   
41.            matchExpressions:  
42.   
43.            - key: security  
44.   
45.               operator: In  
46.   
47.               values:  
48.   
49.               - S2  
50.   
51.          topologyKey: kubernetes.io/hostname  
52.   
53.  containers:  
54.   
55.   -name: with-pod-affinity  
56.   
57.    image: gcr.io/google_containers/pause:2.0

在这个例子中，定义了一个Pod亲和性和一个Pod反亲和性规则。其中Pod亲和性规则是一定要满足的，Pod反亲和性规则是参考满足的。

Pod亲和性规则的含义是：Pod必须部署在一个节点上，这个节点上至少有一个正在运行的Pod，这个Pod的security属性取值是“S1”，并且要求部署的节点同正在运行的Pod所在节点都在相同的云服务区域中，也就是“topologyKey:failure-domain.beta.kubernetes.io/zone”。换言之，一旦某个区域出了问题，我们希望这些 Pod 能够再次迁移到同一个区域。

Pod反亲和性规则的含义是，Pod不能部署在一个节点上，这个节点上正在运行的Pod中security属性取值是“S2”，并且新部署的Pod不能同security属性取值是“S2”的Pod在相同的主机上，也就是“topologyKey: kubernetes.io/hostname”。

matchExpressions中operator的取值包括In、NotIn、Exists、DoesNotExist、Gt和Lt。topologyKey的取值包括：

1) kubernetes.io/hostname

2) failure-domain.beta.kubernetes.io/zone

3) failure-domain.beta.kubernetes.io/region