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: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
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: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
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