k8s的调度机制
scheduler组件
k8s调度器会将pod调度到资源满足要求并且评分最高的node上。我们 可以使用多种规则比如：1.设置cpu、内存的使用要求；2.增加node的label，并通过pod.Spec.NodeSelector进行强匹配；3.直接设置pod的nodeName，跳过调度直接下发。
k8s 1.2加入了一个实验性的功能：affinity。意为亲和性。这个特性的设计初衷是为了替代nodeSelector，并扩展更强大的调度策略。
调度器的工作机制是这样的：
一、预备工作
1、缓存所有的node节点，记录他们的规格：cpu、内存、磁盘空间、gpu显卡数等；
2、缓存所有运行中的pod，按照pod所在的node进行区分，统计每个node上的pod request了多少资源。request是pod的QoS配置，可以参考之前的文章。
3、list & watch pod资源，当检查到有新的Pending状态的pod出现，就将它加入到调度队列中。
4、调度器的worker组件从队列中取出pod进行调度。
二、调度过程
1、先将当前所有的node放入队列；
2、执行predicates算法，对队列中的node进行筛选。这里算法检查了一些pod运行的必要条件，包括port不冲突、cpu和内存资源QoS（如果有的话）必须满足、挂载volume（如果有的话）类型必须匹配、nodeSelector规则必须匹配、硬性的affinity规则（下文会提到）必须匹配、node的状态（condition）必须正常，taint_toleration硬规则（下文会提到）等等。
2、执行priorities算法，对队列中剩余的node进行评分，这里有许多评分项，各个项目有各自的权重：整体cpu，内存资源的平衡性、node上是否有存在要求的镜像、同rs的pod是否有调度、node affinity的软规则、taint_toleration软规则（下文会提到）等等。
3、最终评分最高的node会被选出。即代码中suggestedHost, err := sched.schedule(pod)一句（plugin/pkg/scheduler/scheduler.go）的返回值。
4、调度器执行assume方法，该方法在pod调度到node之前，就以“该pod运行在目标node上” 为场景更新调度器缓存中的node 信息，也即预备工作中的1、2两点。这么做是为了让pod在真正调度到node上时，调度器也可以同时做后续其他pod的调度工作。
5、调度器执行bind方法，该方法创建一个Binding资源，apiserver检查到创建该资源时，会主动更新pod的nodeName字段。完成调度。
nodeSelector
举例：
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: ssd上面这个pod会且仅会被调度到带有disktype: ssd这个label的node上。这是一种强规则，没有妥协，必须遵守。
affinity 和 anti-affinity
- 有亲和性规则，那么反亲和性规则肯定也要有。
- 亲和性规则实现了更丰富的规则表达方式。并且包含了nodeSelector的硬规则和另一种软规则。
- 软规则是一种优先规则，如果没有符合这个优先规则的节点，它仍然会被进行调度。
node亲和性
node亲和性和nodeSelector类似，通过label进行可调度node的过滤，现在有两种node亲和性：requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution：
requiredDuringSchedulingIgnoredDuringExecution
强规则。和nodeSelector完全相同，以label进行强制的约束。需要指出的是：目前，如果一个node在运行时label发生了变化，变化后和其上运行的pod的requiredDuringSchedulingIgnoredDuringExecution 不再匹配，这个node上的pod也不会被驱逐，这个功能会在以后被改进，届时会增加一种类型RequiredDuringSchedulingRequiredDuringExecution 。
preferredDuringSchedulingIgnoredDuringExecution
软规则。举例来说：我们要将某个容器尽可能地调度到可用域X中，但如果不存在这个可用域或者可用域无法再运行pod，调度器也允许这个pod被调度到其他可用域。
以下是一个包含了强规则和软规则的案例:
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: - another-node-label-value containers: - name: with-node-affinity image: gcr.io/google_containers/pause:2.0该案例表明，这个pod只允许被调度到带有kubernetes.io/e2e-az-name=e2e-az1或e2e-az2的label的node上，也即只允许被调度到e2e-az1或者e2e-az2两个可用域中；另外，pod要尽量调度到包含another-node-label-key的值为another-node-label-value的node上。
matchExpressions结构记录各种表达式，一个表达式包含key,operator,values，分别表示关键字、关键字匹配关系、关键字匹配值。匹配关系包括：In,NotIn,Exists,DoesNotExist,Gt,Lt。NotIn和DoesNotExist是node anti-affinity的一种表现。
如果一个pod的描述信息中同时包含了nodeSelector和nodeAffinity,那么调度时两个规则都要满足。
如果一个nodeAffinity中包含了多条nodeSelectorTerms， 调度器只需要满足其中一条； 如果一个 nodeSelectorTerms中记录了多条matchExpressions，那么调度器要满足所有的matchExpressions
inter-pod affinity 和 anti-affinity
这两个特性都包含在1.4版本中，上面的亲和性是node亲和性，这个就是pod亲和性，简而言之，要把pod调度到某个node上，这个node上已有的pod能满足、或尽量满足某些条件。这个特性用pod.spec.affinity.podAffinity和pod.spec.affinity.podAntiAffinity来表示。
pod亲和性的规则可以这么表示：
这个pod应该（或者不应该）运行在节点X上，X上必须已经运行了一个或多个满足规则Y的pod。规则Y的表达方式类似于一个labelSelector并关联了一个namespace列表:namespaces（若没有则表示“allnamespaces”）,X可能是node或一个az，我们通过字段topologyKey来规划X，即所有的X都要满足topologyKey相同，一般topologyKey是一个label的key。
为什么要有namespace列表？因为和node不同，pod是有分namespace的，因此pod的label也是有分namespace的。在这种情况下，规则Y必须要指明自己这个规则要适用于哪些namespace。比如node上运行的是hy这个namespace下的pod，即便pod的label和规则Y的nodeSelector都相同，我们也视为不符合规则。
和node亲和性一样，pod亲和性也包含两个（硬规则和软规则）：
-
requiredDuringSchedulingIgnoredDuringExecution: 硬规则。 -
preferredDuringSchedulingIgnoredDuringExecution：
举个例子：
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模板使用了podAffinity的硬规则和podAntiAffinity的软规则。
- podAffinity规则中
topologyKey是zone，也就是可用域，说明这条规则可以规划处调度到的域，首先，node上必须至少有一个running状态的pod包含key为security，value为S1的label。只要满足这个条件，那么这个node和其同一个域（拥有相同的failure-domain.beta.kubernetes.io/zone为key，且值相同的label）的node均会被调度。 - podAntiAffinity规则中
topologyKey是hostname，表明该规则约定了某种node尽量不会被调度到，这种node上已经运行了包含key为security，value为S2的label的pod。 - 假如现在有node a，b，c，其中a和b拥有相同的zone，且b上运行了一个pod，这个pod有一个label,key为
security，value为S1。那么我们创建如上的一个亲和性规则的3副本时，三个副本都会被调度到a或者b上。假如b上同时运行了一个pod，这个pod有一个label,key为security，value为S2,那么所有的副本都会调度到node a上。
taint toleration
node 可以被打上污点标记，并配置污点容忍策略。而pod的描述信息中如果包含了相同的污点容忍策略，就可以被调度到这个node上，反之则不可、或尽量不允许。
硬性规则
给node a 打上污点 name=huang, 策略为不可调度：kubectl taint nodes a name=huang:NoSchedule
若我创建的pod中包含如下描述：
tolerations:
- key: "name" operator: "Equal" value: "huang" effect: "NoSchedule"则这个pod可以容忍有这类污点的node，即可以调度到node a，当然，也可以用如下的描述：
tolerations:
- key: "name" operator: "Exist" effect: "NoSchedule"类似的硬性规则体现在effect字段中，还有NoExecute,它比NoSchedule更严格，不止pod不能调度上去，node上原有的pod如果不能容忍污点，就会被驱逐（eviction），配合字段tolerationSeconds可以规定这些会被驱逐的pod能在node上呆多久。
软规则
除了NoExecute，NoSchedule，还有一条软规则：PreferNoSchedule.配置effect=PreferNoSchedule后，没有相关污点策略的pod会尽量避免调度到该node上。
本文转自SegmentFault-kubernetes的调度机制
