kubernetes的调度机制

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显卡数等；
二、缓存全部运行中的pod，按照pod所在的node进行区分，统计每一个node上的pod request了多少资源。request是pod的QoS配置，能够参考以前的文章。
三、list & watch pod资源，当检查到有新的Pending状态的pod出现，就将它加入到调度队列中。
四、调度器的worker组件从队列中取出pod进行调度。

2、调度过程
一、先将当前全部的node放入队列；
二、执行predicates算法，对队列中的node进行筛选。这里算法检查了一些pod运行的必要条件，包括port不冲突、cpu和内存资源QoS（若是有的话）必须知足、挂载volume（若是有的话）类型必须匹配、nodeSelector规则必须匹配、硬性的affinity规则（下文会提到）必须匹配、node的状态（condition）必须正常，taint_toleration硬规则（下文会提到）等等。
二、执行priorities算法，对队列中剩余的node进行评分，这里有许多评分项，各个项目有各自的权重：总体cpu，内存资源的平衡性、node上是否有存在要求的镜像、同rs的pod是否有调度、node affinity的软规则、taint_toleration软规则（下文会提到）等等。
三、最终评分最高的node会被选出。即代码中suggestedHost, err := sched.schedule(pod)一句（plugin/pkg/scheduler/scheduler.go）的返回值。
四、调度器执行assume方法，该方法在pod调度到node以前，就以“该pod运行在目标node上” 为场景更新调度器缓存中的node 信息，也即预备工做中的一、2两点。这么作是为了让pod在真正调度到node上时，调度器也能够同时作后续其余pod的调度工做。
五、调度器执行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上。