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

(一)  核心概念

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

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

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

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

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

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

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

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

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

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

annotations:  scheduler.alpha.kubernetes.io/affinity:……

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

spec:  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条件

apiVersion: v1kind: Podmetadata: name: with-node-affinityspec: affinity:   nodeAffinity:     requiredDuringSchedulingIgnoredDuringExecution:       nodeSelectorTerms:       - matchExpressions:         - key: kubernetes.io/e2e-az-name           operator: In           values:           - e2e-az1           - e2e-az2     preferredDuringSchedulingIgnoredDuringExecution:     - weight: 1       preference:         matchExpressions:         - key: another-node-label-key           operator: In           values:           - test containers:  -name: with-node-affinity    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亲和性/非亲和性条件

apiVersion: v1kind: Podmetadata: name: with-pod-affinityspec: affinity:   podAffinity:     requiredDuringSchedulingIgnoredDuringExecution:     - labelSelector:         matchExpressions:         - key: security           operator: In            values:           - S1       topologyKey: failure-domain.beta.kubernetes.io/zone   podAntiAffinity:     preferredDuringSchedulingIgnoredDuringExecution:     - weight: 100       podAffinityTerm:         labelSelector:           matchExpressions:           - key: security              operator: In              values:              - S2         topologyKey: kubernetes.io/hostname containers:  -name: with-pod-affinity   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