Kubernetes1.6新特性：POD高级调度

ycvodzf

　　(一)  核心概念
　　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