Kubernetes调度管理（上）

作者 | 老郑

来源 |运维开发故事(ID：mygsdcsf)

转载请联系授权(微信ID：wanger5354)

基本介绍
在日常工作中，每个机场都有调度室，用来管理飞机应该从哪里降落，停在什么地方。在Kubernetes也有这样的调度器，主要作用就是将Pod安排到合适的节点上。

Kubernetes中的调度器是kube-scheduler，工作流程如下：

1. 在集群中所有Node中，根据调度算法挑选出可以运行该Pod的所有Node；
2. 在上一步的基础上，再根据调度算法给筛选出的Node进行打分，筛选出分数最高的Node进行调度；
3. 将Pod的spec.nodeName填上调度结果的Node名字；
   其原理图如下： 

由上图可知，Kubernetes的调度器核心是两个相互独立的控制循环。1、Informer Path其主要作用是启动一个Informer来监听Etcd中Pod，Node，Service等与调度器相关的API对象的变化。当一个Pod被创建出来后，就被通过Informer Handler将待调度的Pod放入调度队列中，默认情况下，Kubernetes的调度策略是一个优先级队列，并且当集群信息发生变化的时候，调度器还会对调度队列里的内容进行一些特殊操作。而且Kubernetes的默认调度器还负责对调度器缓存（scheduler cache）进行更新，以执行调度算法的执行效率。

2、Scheduler Path其主要逻辑是不断从队列中出一个Pod，然后调用Predicates进行过滤，然后得到一组Node（也就是可运行Pod的所有Node信息，这些信息都是来自scheduler cache），接下来调用Priorities对筛选出的Node进行打分，然后分数最高的Node会作为本次调度选择的对象。调度完成后，调度器需要将Pod的spec.nodeName的值修改为调度的Node名字，这个步骤称为Bind。

但是在Bind阶段，Kubernetes默认调度器只会更新scheduler cache中的信息，这种基于乐观假设的API对象更新方式被称为Assume。在Assume之后，调度器才会向API Server发起更新Pod的请求，来真正完成Bind操作。如果本次Bind失败，等到scheduler cache更新之后又会恢复正常。

正是由于有Assume的原因，当一个Pod完成调度需要在某个Node节点运行之前，kubelet还会进行一步Admit操作来验证该Pod是否能够运行在该Node上，作为kubelet的二次验证。

常用的预算策略有：

• CheckNodeCondition
• GeneralPredication:
  HostName, PodFitsHostPort, MatchNodeSelector, PodFitsResources
• NoDiskConflict
  优先级和抢占机制
  正常情况下，当一个Pod调度失败后，它会被搁置起来，直到Pod被更新，或者集群状态发生变化，调度器才会对这个Pod进行重新调度。但是有的时候我们不希望一个高优先级的Pod在调度失败就被搁置，而是会把某个Node上的一些低优先级的Pod删除，来保证高优先级的Pod可以调度成功。

Kubernetes中优先级是通过ProrityClass来定义，如下：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for high priority service pods only."

其中的value就是优先级数值，数值越大，优先级越高。优先级是一个32bit的整数，最大值不超过10亿，超过10亿的值是被Kubernetes保留下来作为系统Pod使用的，就是为了保证系统Pod不会被抢占。另外如果globalDefault的值设置为 true的话表明这个PriorityClass的值会成为系统默认值，如果是false就表示只有在申明这个PriorityClass的Pod才会拥有这个优先级，而对于其他没有申明的，其优先级为0。

如下定义Pod并定义优先级：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

上面的PriotiryClassName就是定义我们的PriorityClass，当这个Pod提交给Kubernetes之后，Kubernetes的PriorityAdmissionController会自动将这个Pod的spec.priority字段设置为我们定义的值。而当这个Pod拥有这个优先级之后，高优先级的Pod就可能比低优先级的Pod先出队，从而尽早完成调度。

而当一个高优先级的Pod调度失败后，其抢占机制就会被触发，这时候调度器就会试图从当前的集群中寻找一个节点，使得这个节点上的一个或多个低优先级的Pod被删除，然后这个高优先级的Pod就可以被调度到这个节点上。当抢占发生时，这个高优先级Pod并不会立即调度到即将抢占的节点上，调度器只会将这个Pod的spec.nominatedNodeName的值设置为被抢占节点的Node名字，然后这个Pod会重新进入下一个调度周期，然后会在这个周期内决定这个Pod被调度到哪个节点上。在这个重新调度期间，如果有一个更高的优先级Pod也要抢占这个节点，那么调度器就会清空原Pod的nominatedNodeName的值，而更高优先级的Pod将会抢占这个值。

实现原理：Kubernetes用两个队列来实现抢占算法：ActiveQ和unschedulableQ。

1. ActiveQ：凡是在ActiveQ里的Pod，都是下一个周期需要调度的对象，所以当Kubernetes创建一个新的Pod，这个Pod就会被放入ActiveQ里；
2. unschedulableQ：专门用来存放调度失败的Pod；
   那么如果一个Pod调度失败，调度器就会将其放入unschedulableQ里，然后调度器会检查这个调度失败的原因，分析并确认是否可以通过抢占来解决此次调度问题，如果确定抢占可以发生，那么调度器就会把自己缓存的所有信息都重新复制一份，然后使用这个副本来模拟抢占过程。如果模拟通过，调度器就会真正开始抢占操作了：

调度器会检查牺牲者列表，清空这些Pod所携带的nominatedNodeName字段；
调度器会把抢占者的nominatedNodeName的字段设置为被抢占的Node名字；
调度器会开启Goroutine，同步的删除牺牲者；
接下来调度器就会通过正常的调度流程，把抢占者调度成功。在这个过程中，调度器会对这个Node，进行两次Predicates算法：

假设上述抢占者已经运行在这个节点上，然后运行Predicates算法；
调度器正常执行Predicates算法；
只有上述者两个都通过的情况下，这个Node和Pod才会被 绑定。

高级调度
上面介绍的是Kubernetres默认的调度策略，有时候默认的调度策略不能满足我们的需求，比如想把Pod调度到指定的节点，或者不让某些节点调度Pod。这时候就要用到更高级的调度策略，主要有如下几种：

• nodeSelector
• nodeName
• nodeAffinity
• podAffinity
• podAntiAffinity
• 污点调度
  nodeSelector
  nodeSelector也可以叫做节点选择器，其原理是通过在节点上定义label标签，然后Pod中指定选择这些标签，让Pod能够调度到指定的节点上。

比如给kk-node01指定env=uat标签，命令如下：

$ kubectl label nodes kk-node01 env=uat

现在在Pod的YAML清单中配置nodeSelector，如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeselector
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  nodeSelector:
    env: uat

这样，该Pod就会调度到kk-node01节点上，如果该Pod指定为env=prod，则调度不到kk-node01节点。

nodeName
nodeName也是节点选择器，和nodeSelector不同之处在于nodeName是直接指定节点名，这属于强调度，定义方式如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodename
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  nodeName: kk-node01     # 节点名字

nodeAffinity
nodeAffinity叫做节点亲和性调度，其调度方式比nodeSelector和nodeName更强大。

目前，nodeAffinity支持两种调度策略：

• preferredDuringSchedulingIgnoredDuringExecution
• requiredDuringSchedulingIgnoredDuringExecution
  preferredDuringSchedulingIgnoredDuringExecution表示如果有Node匹配，则优先调度到该Node，如果没有，可以根据配置调度到其他节点。requiredDuringSchedulingIgnoredDuringExecution则表示必须满足条件的节点才允许调度。

定义preferredDuringSchedulingIgnoredDuringExecution的例子如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-preferred
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - preference:
          matchExpressions:
          - key: disktype
            operator: In
            values: ["ssd", "harddisk"]
        weight: 60

requiredDuringSchedulingIgnoredDuringExecution的例子如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeaffinity-required
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values: ["ssd", "harddisk"]

其中，operator支持In,NotIn, Exists, DoesNotExist. Gt, and Lt。

podAffinity
上面介绍的nodeSelector，nodeName，nodeAffinity都是针对节点的，下面介绍的podAffinity和podAntiAffinity则是针对Pod。

podAffinity表示Pod亲和性调度，意识就是把Pod调度到与它比较紧密的Pod上，如下：

apiVersion: v1
kind: Pod
metadata:
  name: fronted
  labels:
    app: myapp
    row: fronted
spec:
  containers:
  - name: myapp
    image: ikubernetes/myapp:v1
---
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    app: db
    row: backend
spec:
  containers:
  - name: db
    image: busybox
    imagePullPolicy: IfNotPresent
    command:
    - "/bin/sh"
    - "-c"
    - "sleep 3600"
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: ["myapp"]
        topologyKey: kubernetes.io/hostname

这表示把后端pod和前端pod调度在一起。

podAffinity也有preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution，也就是硬亲和和软亲和，其使用情况和nodeAffinity一样。