18.1、kubernetes调度过程

假如要创建一个pod(对应Pod1的定义yaml)，相应的调度过程是什么？

• ApiServer 会先把这个待创建的请求路由给webhooks的Controlles进行校验

• 验证通过后，ApiServer 它将在集群中生成pod(写入到etcd中)，但此时 pod的nodeName 它是空的，它的 phase 是 Pending 状态。

• 在生成了 pod 之后，kube-Scheduler 以及kubelet 都能 watch 到这个 pod 生成事件，kube-Scheduler 发现这个 pod 的 nodeName 当它是空的时候，你会认为这是空的pod 处于未调度状态。

• 接下来，它会这样做 pod 通过一系列的调度算法，包括一系列的过滤和评分算法，得到自己的队列进行调度，Schedule 选择最合适的节点，并将该节点的名称绑定到该节点 pod 的 spec 上(通过apiserver 入库)，完成调度过程。此时pod 的 spec 上，nodeName 已更新 Node1 这个 node

• 更新完 nodeName 之后，在 Node1 上的这台 kubelet 会 watch 到这个 pod 属于自己节点的一个 pod。

• 然后它会这样做 pod 拿到节点上进行操作，包括创建一些容器 storage 以及 network，最后等所有资源都准备好了，kubelet 会把pod状态更新为 Running，这样一个完整的调度过程就结束了。

调度过程：其实是在做一件事，那就是把 pod 放到合适的 node 上。什么是合适的？

• 首先要满足 pod 资源要求；

• 二是满足 pod 一些特殊关系的要求；

• 3.再次满足 node 一些限制要求；

• 4.最后，要合理利用整个集群资源。

18.2、Kubernetes基本调度能力-资源调度

• 资源需求 - 满足Pod资源需求

  • Resource: CPU/Memory/Storage/GPU/
  • Qos: Guaranteed/Burstable/BestEffort

1、如何满足Pod资源要求 ？资源调度用法

2、如何满足Pod资源需求？ - Pod Qos类型

注意：QosClass不能手动指定，只能通过requests和limit 来影响

3、如何满足Pod资源需求， - Pod Qos配置

4、如何满足Pod资源要求？- 不同QoS的区别

不同的 Qos，其实在调度和底层表现上有一些不同:

• 调度性能不同，只使用调度器 request 调度，也就是说，不管你配得多大， limit，它只会使用 request 进行调度。

• 不同的底层 Qos 性能也不一样。

  • CPU是按 request 划分不同权重的权重 Qos，它的 request 例如，它完全不同，就像 Burstable 和 BestEffort，它可能 request 它可以填写小数字或不填写，所以它的重量实际上很低。像 BestEffort，它的权重可能只有 2，而 Burstable 或 Guaranteed，它的权重可以达到几千。另外，如果kubelet 开启了 cpu-manager-policy=static 的时候，Guaranteed Qos，如果request 是一个整数，比如匹配 2，它会对 Guaranteed Pod 绑核(类似)taskset)
  • 非整数的 Guaranteed/Burstable/BestEffort，它们的 CPU 会放在一起，形成一个 CPU share pool，例如，如果有上面的例子，这个节点 8 已经分配了个核 2 核对整数 Guaranteed 绑核，然后剩下的 6 个核 CPU2~CPU7，它将是非整数的 Guaranteed/Burstable/BestEffort 分享，然后根据不同的权重划分时间片 6 个核的 CPU。
  • memory 按照不同的 Qos 进行划分：OOMScore。比如说 Guaranteed，默认配置 -998 的 OOMScore；Burstable 它将根据内存设计的大小和节点之间的关系进行分配 2-999 的 OOMScore。BestEffort 会固定分配 1000 的 OOMScore，OOMScore 分数越高，出现在物理机器上 OOM 优先考虑 kill 掉。
  • 节点上的 eviction (驱逐)动作上，不同的 Qos 也不一样，发生了 eviction 驱逐将优先考虑 BestEffort 的 pod。

5、如何满足Pod资源要求？ - 资源Quota

``` 为node预留资源，可用kubelet运行参数 --system-reserved=cpu=1,memory=1Gi(系统预留) --kube-reserved=cpu=1,memory=1G(k8s组件预留) 等参数```

spec 包括了一个 hard 和 scopeSelector。scopeSelector 为这个 Resource 方法定义了更丰富的索引能力。例如，在上述例子中，索引非 BestEffort 的 pod，限制的 cpu 是 1000 个，memory 是 200G，Pod 是 10 个，然后 Scope 除了提供 NotBestEffort，它还提供了更丰富的索引范围，包括 Terminating/Not Terminating，BestEffort/NotBestEffort，PriorityClass。

如果用户真的超过了ResourceQuota有限的资源表现为：它正在提交 Pod spec 会收到一个 forbidden 的 403 错误，提示 exceeded quota。这样，用户就不能再提交了 cpu 或者是 memory，或者是 Pod 数量资源。如果再提交一个，则不包括在此内 ResourceQuota 方案中的资源仍然可以成功。

18.3、Kubernetes基本调度能力-关系调度

• Pod和其他pod亲和/互斥关系
  • PodAffinity
  • PodAntiAffinity
• Pod和Node的亲和关系
  • NodeSelector
  • NodeAffinity
• Node配置限制标记，给予Pods配置容忍标记
  • Node - Taints
  • Pod - Tolerations

2、如何满足Pod与Node关系要求？ NodeAffinity

3.限制某些调度Node？- Node 标记/容忍

NoExecute会对已有的pod进行驱逐。

# 1、下线维护node kubectl drain   #驱逐pod kubectl uncordon  #设置可调度  # 2、为node设置污点 [root@master1 ~]# kubectl get pods -o wide |grep master3 nginx-7fddbd784f-zrd68               1/1     Running   1          10d   172.7.67.3   master3               [root@master1 ~]# kubectl taint nodes master3 key1=value1:NoExecute  #驱逐没有tolration的Pods 
node/master3 tainted
[root@master1 ~]# kubectl get pods -o wide |grep master3  #已经驱逐
[root@master1 ~]# kubectl taint nodes master3 key1=value1:NoExecute-  #删除taint

# 3、pod tolerations
[root@master1 yaml]# kubectl taint nodes master2 key1=value1:NoSchedule
node/master2 tainted
[root@master1 yaml]# cat pod2.yaml #虽然master2有taint，但是pod仍然可以调度到master2上
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: reg.mt.com:5000/nginx:latest
        name: nginx
        ports:
        - containerPort: 80
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 3
        readinessProbe:
          successThreshold: 1
          periodSeconds: 5
          httpGet:
            path: /
            port: 80
          timeoutSeconds: 5
          initialDelaySeconds: 3
      tolerations:
      - key: key1
        operator: Equal
        value: value1

18.4、Kubernetes高级调度能力-优先级

1、优先级调度配置

优先级调度和抢占: Priority, Preemption

如果集群资源充足，通过基础调能力即可满足实现合理的资源使用。在集群资源不足的情况下如何使用资源？

• 先到先得策略(FIFO) - 简单、相对公平、上手快
• 优先级策略(Priority) - 符合日常业务特点。在高优先级的pod到的时候低优先级的pod让出资源

PodPriority和Preemption在v1.14版本为stable版本，并且默认开启 链接

如何使用呢？

Kubernetes 内置的默认优先级。DefaultpriorityWhenNoDefaultClassExistis，如果集群中没有配置 DefaultpriorityWhenNoDefaultClassExistis，那所有的 Pod 关于此项数值都会被设置成 0。

[root@master1 yaml]#  kubectl get priorityclass  #k8s初始化的时候默认提供内置的系统级别的PriorityClass，主要用来确保 Kubernetes 系统的关键组件或者关键插件总是能够优先被调度，比如 coredns 等。
NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-cluster-critical   2000000000   false            15d
system-node-critical      2000001000   false            15d

另一个内置优先级是用户可配置最大优先级限制：HighestUserDefinablePriority = (10 亿) 系统级别优先级：SystemCriticalPriority = (20 亿)

2、优先级调度过程

只开启优先级调度，没有开启抢占模式的调度过程。pod1优先级高，pod2优先级低。先调度pod1，后调度pod2

3、优先级抢占过程

pod0在node1上已经占用了部分资源。优先级: Pod0 > Pod1 >Pod2 。假如先进行了Pod2的调度(pod2先到)，调度到了Node1上，在Pod1进行调度的时候进行资源抢占，让Pod2作为Pod1的让渡者。

4、优先级抢占策略

• 1、上图右侧是整个优先级抢占的调度流程，也就是 kube-scheduler 的工作流程。首先一个 Pod 进入抢占的时候，会判断 Pod 是否拥有抢占的资格(Eligible)，有可能上次已经抢占过一次。
• 2、如果符合抢占资格，它会先对所有的节点进行一次过滤，过滤出符合这次抢占要求的节点，如果不符合就过滤掉这批节点。
• 3、接着从过滤剩下的节点中，挑选出合适的节点进行抢占。这次抢占的过程会模拟一次调度，也就是把上面优先级低的 Pod 先移除出去，再把待抢占的 Pod 尝试能否放置到此节点上。然后通过这个过程选出一批节点
• 4、进入下一个过程叫 ProcessPreemptionWithExtenders。这是一个扩展的钩子，用户可以在这里加一些自己抢占节点的策略，如果没有扩展的钩子，这里面是不做任何动作的。
• 5、接下来的流程叫做 PickOneNodeForPreemption，就是从上面 selectNodeForPreemption list 里面挑选出最合适的一个节点，这是有一定的策略的。上图左侧简单介绍了一下策略：串行过滤
  • 优先选择打破 PDB 最少的节点；挑选的节点对服务的影响最小
  • 其次选择待抢占 Pods 中最大优先级最小的节点；
  • 再次选择待抢占 Pods 优先级加和最小的节点；
  • 接下来选择待抢占 Pods 数目最小的节点；
  • 最后选择拥有最晚启动 Pod 的节点；

通过这五步串行策略过滤之后，会选出一个最合适的节点。然后对这个节点上待抢占的 Pod 进行 delete，这样就完成了一次待抢占的过程。

PDB: 在Kubernetes 中，为了保证业务不中断或业务SLA不降级，需要将应用进行集群化部署。通过PodDisruptionBudget(PDB) 控制器可以设置应用POD集群处于运行状态最低个数，也可以设置应用POD集群处于运行状态的最低百分比，这样可以保证在主动销毁(node异常导致的pod异常不再此范围内)应用POD的时候，不会一次性销毁太多的应用POD，从而保证业务不中断或业务SLA不降级。删除一个pod对应需要创建一个新pod

第十九章、调度器的调度流程和算法介绍

19.1、调度器架构

调度器架构：

![]

• Policy

调度器启动时会通过配置文件 File、命令行参数、或者是配置好的 ConfigMap，来指定调度策略。调度策略主要包含：过滤器 (Predicates)、打分器 (Priorities) 、外部扩展的调度器 (Extenders)、以及最新支持的schedulerFramework的扩展点 (Plugins)。

• Informer

scheduler启动的时候会通过 kube-apiserver 去 watch 相关的数据，通过 Informer 机制将调度需要的数据如：Pod 、Node 、pv、pvc、在抢占流程中需要的 PDB 数据和打散算法需要的 Controller-Workload 数据，放入到调度队列中。并将这些数据做一定的预处理作为调度器的的 Cache。

• Algorithm 调度算法流程

通过 Informer 去 watch 到需要调度的 Pod 数据，放到Queue里面后。Schedule Pipeline 会一直循环从队列里面拿数据，然后经过调度流水线进行调度。调度流水线 (Schedule Pipeline) 循环主要有三个流程部分： 1、调度流程；2、Wait 流程；3、Bind 流程

调度流程: Schduler Thread 会经历 Pre Filter -> Filter -> Post Filter-> Score -> Reserve，可以简单理解为 Filter -> Score -> Reserve。Filter 阶段用于选择符合 Pod Spec 描述的 Nodes；Score 阶段用于从 Filter 后的 Nodes 进行打分和排序；Reserve 阶段将 Pod 跟排序后的最优 Node 的 NodeCache 中(预占用)，表示这个 Pod 已经分配到这个 Node 上, 让下一个等待调度的 Pod 对这个 Node 进行 Filter 和 Score 的时候能看到刚才分配的 Pod。Schedule Thread为串行执行

wait流程: 这个阶段可以用来等待 Pod 关联的资源的 Ready 等待，例如等待 PVC 的 PV 创建成功，或者等待关联的 Pod 调度成功等；

Bind流程：用于将 Pod 和 Node 的关联持久化 Kube APIServer。整个调度流水线只有在 Scheduler Thread 阶段是串行的一个 Pod 一个 Pod 的进行调度，在 Wait 和 Bind 阶段 Pod 都是异步并行执行。

调度完成后，会去更新调度缓存 (Schedule Cache)，如更新 Pod 数据的缓存，也会更新 Node 数据。

19.2、调度算法

注：kube-scheduler为每一个pod调度选择包含两个步骤过滤(Filter)和打分(Score)，有的文献中也说预先(Predicates)和优选(Priorities)原理一样，这里以官方说法为准

参考: 官网链接 和 《Kubernetes权威指南-第四版》

19.2.1、调度的详细流程

调度的详细流程中，调度队列分成三个队列：activeQ、backoffQ、unschedulableQ。

首先会从 activeQ 里面 pop 一个 Pod 出来，然后经过调度流水线去调度。拿到一个等待调度的 Pod后，从 NodeCache 里面拿到相关的 Node 数据进行过滤和打分，这里有一个非常有意思的算法，就是 NodeCache 部分，在过滤阶段，调度器提供一种能力，可以不用过滤所有节点，取到最优节点。可通过调度器提供的取样能力，通过配置比例来拿到部分节点进行过滤及打分，然后选中节点进行 bind 流程。提供这种能力需要在 NodeCache 里面注意一点，NodeCache 选中的节点需要足够分散，也就意味着容灾能力的增强。

• NodeCache

在 NodeCache 中，Node 是按照 zone 进行分堆。在 filter 阶段的时候，会为NodeCache 维护一个 zondeIndex和一个nodeIndex，每 Pop 一个 Node 进行（一个zone中选取一个node），zoneIndex 往后挪一个位置，然后从该 zone 的 node 列表中取一个 node 出来。可以看到上图纵轴有一个 nodeIndex，每次也会自增。如果当前 zone 的节点无数据，那就会从下一个 zone 中拿数据。大概的流程就是 zoneIndex 从左向右，nodeIndex 从上到下，从而保证拿到的 Node 节点是按照 zone 打散的。选出取样所需的节点数量后，就会进入下一个阶段，进入Score(打分器)，打分排序后选择最优节点(进行预占,pod状态为Assume,并更新pod cache)然后进行bind，bind完成后，确定已经分配到node上后，才会更新pod状态为Added。如果bind失败pod状态会更新为initial并从node上清理pod数据。pod会被重新放入unSchedulableQ。

• isEnough

如果取样的规模已经达到了我们设置的取样比例，那 Filter 就会结束（isEnough)，不会再去过滤下一个节点。 然后过滤到的节点会经过打分器(Score)，打完分后会选择最优节点(SelectHost)作为 pod 的分配位置。

• pod状态转换：

Scheduler 启动的时候所有等待被调度的 Pod 都会进入 activieQ，activeQ 会按照 Pod 的 priority 进行排序，Scheduler Pipepline 会从 activeQ 获取一个 Pod 进行 Pipeline 执行调度流程，当调度失败之后会直接根据情况选择进入 unschedulableQ 或者 backoffQ，如果在当前 Pod 调度期间 Node Cache、Pod Cache 等 Scheduler Cache 有变化就进入 backoffQ，否则进入 unschedulableQ。

分配 Pod 到 Node 的时候，需要对 Node 的内存做处理，将这个 Pod 分配到这个 Node 上，这个过程可以称呼为账本预占。 预占的过程会把 Pod 的状态标记为 Assumed 的状态(处于内存态)，紧接着就进入 bind 阶段，调用 kube-apiserver 将 Pod 的 NodeName 持久化到 etcd，这个时候 Pod 的状态还是 Assumed。只有在通过 Informer watch 到 Pod 数据已经确定分配到这个节点的时候，才会把状态变成 Added，

如果Bind 失败会做回退，会把预占用的账本做 Assumed 的数据退回 Initial，也就是把 Assumed 状态擦除，从 Node 里面把 Pod 数据账本擦除掉。并把 Pod 重新丢回到 unschedulableQ 队列里面。一般在一个调度周期里面，Cache 发生了变化才会把 Pod 放到 backoffQ 里面。在 backoffQ 里面等待的时间会比在 unschedulableQ 里面时间更短，backoffQ 里有一个降级策略，是 2 的指数次幂降级。假设重试第一次为 1s，那第二次就是 2s，第三次就是 4s，第四次就是 8s，最大到 10s，大概是这么一个机制。

unschedulableQ 里面的机制是：如果这个 Pod 一分钟没调度过，到一分钟的时候，它会把这个 Pod 重新丢回 activeQ。它的轮训周期是 30s。

• 取样规模：

它是怎么判断调度器的节点是足够的呢？按照默认值来说，默认的是在 [5%-50%] 之间，公式为 Max (5,50 - 集群的 node 数 / 125)。为什么公式是这样的呢？大家有兴趣的可以自己查一下。

这里举个例子：假如配置比率是 10%，节点规模为 3000 个节点，需要待选的节点数 Max(3000 * 10/100,100)，最后得到的值是 300，跟 100 进行比较，100 默认是得到节点最小需要值。300 大于 100，那就按照 300 节点。在调度流水线里面，Filter 只要过滤到 300 个候选节点，就可以停止 Filter 流程了。

支持以下两种方式配置调度器的过滤和打分行为：
1、Scheduling Policies allow you to configure Predicates for filtering and Priorities for scoring.
2、Scheduling Profiles allow you to configure Plugins that implement different scheduling stages, including: QueueSort, Filter, Score, Bind, Reserve, Permit, and others. You can also configure the kube-scheduler to run different profiles.

19.2.2、调度器的算法实现-过滤Predicates

过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。 例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。 在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下， 这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。

1、过滤器 (Predicates) 按照功能分为四类

• 存储相关
  • NoVolumeZoneConflict，校验 pvc 上要求的 zone 是否和 Node 的 zone 匹配；
  • MaxCSIVolumeCountPred，由于服务提供方对每个节点的单机最大挂载磁盘数是有限制的，所有这个是用来校验 pvc 上指定的 Provision 在 CSI plugin 上报的单机最大挂盘数；
  • CheckVolumeBindingPred，在 pvc 和 pv 的 binding 过程中对其进行逻辑校验；
  • NoDiskConfict，SCSI 存储不会被重复的 volume。
• Pod和Node匹配相关
  • CheckNodeCondition，在 node 节点上有一个 Condition 的 type 值是不是 true，如果是 true 这个节点才会允许被调度；
  • CheckNodeUnschedulable，在 node 节点上有一个 NodeUnschedulable 的标记，我们可以通过 kube-controller 对这个节点直接标记为不可调度，那这个节点就不会被调度了。在 1.16 的版本里，这个 Unschedulable 已经变成了一个 Taints。也就是说需要校验一下 Pod 上打上的 Tolerates 是不是可以容忍这个 Taints；
  • PodToleratesNodeTaints，就是 Pod Tolerates 和 Node Taints 是否匹配；
  • PodFitsHost，其实就是 Host 校验；
  • MatchNodeSelector
• Pod和Pod匹配相关
  • MatchinterPodAffinity：主要是 PodAffinity 和 PodAntiAffinity 的校验逻辑。
• Pod打散相关
  • EvenPodsSpread；
  • CheckServiceAffinity。

2、针对pod打散EventPodsSpread重点说明

spec描述：

-	描述符合条件的一组pod在指定的Topo上的打散要求

spec:
  # 多个之间是and的关系
  topologySpreadConstraint:
  # maxSkew最大允许不均衡的数量
  - maxSkew: 1
    # 应用在哪个topo上，zone或者node，或者...
    topologyKey: k8s.io/zone
    # ScheduleAnyway | DoNotSchedule
    # 当不满足maxSkew的策略，不调度，或者随便调度，在过滤阶段只关注DoNotSchedule
    whenUnsatisfiable: DoNotSchedule
    # 符合描述的一组pod
    selector:
      matchLabels:
        app: foo
      matchExpressions:
      - key: app
        operator: In
        values: ['foo','foo2']

pod.Spec.TopologySpreadContraints新增了一组Pod按照指定TopologKey进行打散的描述

如下: 'app=foo'这个应用，在zone级别必须是被打散的，最大的不均衡数是1；actualSkew为当前不均衡数。
spec:
  topologySpreadConstraint:
  - maxSkew: 1
    topologyKey: k8s.io/zone
    whenUnsatisfiable: DoNotSchedule
    selector:
      matchLabels:
        app: foo
假设pod都带有app=foo(当前zone1和zone2的pod都带有app:foo)，集群有三个zone
+-------+-------+-------+
| zone1 | zone2 | zone3 |
+-------+-------+-------+
|  pod  |  pod  |       |
+-------+-------+-------+
计算ActualSkew = count[topo] - min(count[topo]) 
ActualSkew的值为(1/1/0)

假设maxSkew=1
如果分配到zone1/zone2的话，skew的值为2 > maxSkew(1)，因此只能分配到zone3

假设maxSkew=2
如果分配到zone1/zone2,skew的值为2/1/0,满足<=maxSkey,分配到zone3的话，skew的值(1/1/1)，满足<=maxSkew，因此zone1/zone2/zone3都可以被选择

通过这种描述，它最大的用处就是当我们对自己的应用有容灾要求的，必须在每一个 zone 上是均衡部署的，这时就可以用这个规则去限定。比如所有的app为foo的应用maxSkew数量为1，那它在每个 zone 上都是均衡的。

扩展链接：

https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/ 
https://kubernetes.io/docs/reference/scheduling/policies/

19.2.3、调度器的算法实现-打分Priorities

打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。 根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。打分算法主要解决的问题就是集群的碎片、容灾、水位、亲和、反亲和等。

1、按照类别可以分为四大类：

• Node 水位
• Pod 打散 (topo,service,controller)
• Node 亲和&反亲和
• Pod 亲和&反亲和

2、资源水位

用户可使用资源水位比例进行score。资源水位主要有2个概念Request和Allocatable。

• 优先打散：我们应该把 Pod 分到可用资源最大比例的节点上。可用资源最大的公式就是 (Allocatable - Request) / Allocatable * Score。这个比例就是表示如果这个 Pod 分配到这个 Node 上，还剩余的资源比例越大的话，越优先分配到这个节点上，从而达到打散的要求。
• 优先堆叠：Request / Allocatable * Score。考虑的是如果 Pod 分配到 Request 的节点上，使用的资源比例越大，它应该越优先。
• 碎片率：{ 1 - Abs[CPU(Request / Allocatable) - Mem(Request / Allocatable)] } * Score。是用来考虑 CPU 的使用比例和内存使用比例的差值，这个差值就叫做碎片率。如果这个差值越大，就表示碎片越大，优先不分配到这个节点上。如果这个差值越小，就表示这个碎片率越小，那应该优先分配到这个节点上。
• 指定比率：我们可以通过打分器，当资源使用的比率达到某个值时，用户指定配置参数可以指定不同比率的分数，从而达到控制集群上每个节点 node 的分布。

3、Pod打散

Pod 打散为了解决的问题：支持符合条件的一组 Pod 在不同 topology 上部署的 spread 需求。

• SelectorSpreadPriority：

  • 在Node上计数
  • TopoPods = Exists Pod匹配Income Pod的controller的workload的slector条件
  • (sum(TopoPods) - TopoPods) / Sum(TopoPods)

  它是为了满足 Pod 所属的 Controller 上所有的 Pod 在 Node 上打散的要求。

  实现方式：它会依据待分配的 Pod 所属的 controller，计算该 controller 下的所有 Pod,假设总数为 T，对这些 Pod 按照所在的 Node 分组统计；假设为 N (表示为某个 Node 上的统计值)，那么对 Node上的分数统计为 (T-N)/T 的分数，值越大表示这个节点的 controller 部署的越少，分数越高，从而达到 workload 的 pod 打散需求。

• ServiceSpreadingPriority

  • 官方注释上说大概率会用来替换 SelectorSpreadPriority
  • 在Node上计数，在每个node上进行计算
  • TopoPods : 满足Pod所在的service的selector条件
  • (sum(TopoPods) - TopoPods) / Sum(TopoPods)

• EvenPodsSpreadPriority

  • spec指定的topologyKey
  • Topopods = 满足spec的labelSelector
  • 算分公式：
    • Node = 按照Node级别累计TopoPods
    • MaxDif = Total - Min(Node)
    • (Total - Node) / MaxDif

用来指定一组符合条件的 Pod 在某个拓扑结构上的打散需求，这样是比较灵活、比较定制化的一种方式，使用起来也是比较复杂的一种方式。因为这个使用方式可能会一直变化，我们假设这个拓扑结构是这样的：Spec 是要求在 node 上进行分布的，我们就可以按照上图中的计算公式，计算一下在这个 node 上满足 Spec 指定 labelSelector 条件的 pod 数量，然后计算一下最大的差值，接着计算一下 Node 分配的权重，如果说这个值越大，表示这个值越优先。

4、Node亲和和反亲和

• NodeAffinityPriority，这个是为了满足 Pod 和 Node 的亲和 & 反亲和；

  • TopoPods: 累计满足affinity次数
  • TopoPods /Max(TopoPods) * MaxPriority

• ServiceAntiAffinity，是为了支持 Service 下的 Pod 的分布要按照 Node 的某个 label 的值进行均衡。比如：集群的节点有云上也有云下两组节点，我们要求服务在云上云下均衡去分布，假设 Node 上有某个 label，那我们就可以用这个 ServiceAntiAffinity 进行打散分布；

• NodeLabelPrioritizer，主要是为了实现对某些特定 label 的 Node 优先分配，算法很简单，启动时候依据调度策略 (SchedulerPolicy）配置的 label 值，判断 Node 上是否满足这个label条件，如果满足条件的节点优先分配;

• ImageLocalityPriority，节点亲和主要考虑的是镜像下载的速度。如果节点里面存在镜像的话，优先把 Pod 调度到这个节点上，这里还会去考虑镜像的大小，比如这个 Pod 有好几个镜像，镜像越大下载速度越慢，它会按照节点上已经存在的镜像大小优先级亲和。

5、Pod亲和和反亲和

• InterPodAffinityPriority
  • 先介绍一下使用场景：
    • 第一个例子，比如说应用 A 提供数据，应用 B 提供服务，A 和 B 部署在一起可以走本地网络，优化网络传输；
    • 第二个例子，如果应用 A 和应用 B 之间都是 CPU 密集型应用，而且证明它们之间是会互相干扰的，那么可以通过这个规则设置尽量让它们不在一个节点上。
• NodePreferAvoidPodsPriority
• 用于针对RC(Replicas Controller)和RS(Replica set) 在node 上加 annotation 声明哪些 controller 不要分配到 Node 上来实现RC/RS的反亲和

19.2.4、配置调度policies

配置kube-scheduler --policy-config-file  or kube-scheduler --policy-configmap  来配置Policies

方式1-policy-config-file:
{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
	{"name" : "PodFitsPorts"},
	{"name" : "PodFitsResources"},
	{"name" : "NoDiskConflict"},
	{"name" : "NoVolumeZoneConflict"},
	{"name" : "MatchNodeSelector"},
	{"name" : "HostName"}
	],
"priorities" : [
    {"name" : "LeastRequestedPriority", "weight" : 1},
	{"name" : "BalancedResourceAllocation", "weight" : 1},
	{"name" : "ServiceSpreadingPriority", "weight" : 1},
	{"name" : "EqualPriority", "weight" : 1}
	]
}

方式2-独立自主使用插件，并指定kube-scheduler运行不同的配置文件
参考：https://kubernetes.io/docs/reference/scheduling/config/#profiles  

19.3、如何配置调度器

• 如何启动一个调度器：
  • 默认启动的调度器，什么参数都不指定。查看默认配置：--write-config-to
  • 指定调度器配置文件: --config
• 配置文件解析：
  • schedulerName: 该调度器负责哪些pod的调度，默认为 default-scheduler
  • algorithmSource: 配置算法提供者，目前提供三种方式：Provider、file、configMap
  • hardPodAffinitySymnetricweight，配置 PodAffinity 和 NodeAffinity 的权重是多少
  • percentageOfNodesToscore，filter到的节点占总节点数的比率，用于减少 Node 节点的取样规模
  • bindTimeoutSeconds，指定 bind 阶段的操作时间，单位是秒
  • disablePreemption，关闭抢占协议；
  • ClientConnection，是用来配置跟 kube-apiserver 交互的一些参数配置。比如 contentType，是用来跟 kube-apiserver 交互的序列化协议，这里指定为 protobuf；

配置文件Profiles和plugins格式说明： https://kubernetes.io/docs/reference/scheduling/config/

19.4、如何扩展调度器

举例：GPU share。在扩展调度器里面会记录每个卡上分配的内存大小，官方调度器只负责 Node 节点上总的显卡内存是否足够。这里扩展资源叫 example/gpu-men: 200g，假设有个 Pod 要调度，通过 kube-scheduler 会看到我们的扩展资源，这个扩展资源配置要走扩展调度器，在调度阶段就会通过配置的 url 地址来调用扩展调度器，从而能够达到调度器能够实现 gpu-share 的能力。

1、扩展点用途：

Scheduling happens in a series of stages that are exposed through the following extension points:

1、QueueSort: These plugins provide an ordering function that is used to sort pending Pods in the scheduling queue. Exactly one queue sort plugin may be enabled at a time.
2、PreFilter: These plugins are used to pre-process or check information about a Pod or the cluster before filtering. They can mark a pod as unschedulable.
3、Filter: These plugins are the equivalent of Predicates in a scheduling Policy and are used to filter out nodes that can not run the Pod. Filters are called in the configured order. A pod is marked as unschedulable if no nodes pass all the filters.
4、PreScore: This is an informational extension point that can be used for doing pre-scoring work.
5、Score: These plugins provide a score to each node that has passed the filtering phase. The scheduler will then select the node with the highest weighted scores sum.
6、Reserve: This is an informational extension point that notifies plugins when resources have been reserved for a given Pod. Plugins also implement an Unreserve call that gets called in the case of failure during or after Reserve.
7、Permit: These plugins can prevent or delay the binding of a Pod.
8、PreBind: These plugins perform any work required before a Pod is bound.
9、Bind: The plugins bind a Pod to a Node. Bind plugins are called in order and once one has done the binding, the remaining plugins are skipped. At least one bind plugin is required.
10、PostBind: This is an informational extension point that is called after a Pod has been bound.
11、UnReserve: This is an informational extension point that is called if a Pod is rejected after being reserved and put on hold by a Permit plugin

For each extension point, you could disable specific default plugins or enable your own. For example:

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: NodeResourcesLeastAllocated
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1

For each extension point, you could disable specific default plugins or enable your own. For example:

第二十章、GPU管理和Device Plugin工作机制

20.1、需求背景

2016 年，随着 AlphaGo 的走红和 TensorFlow 项目的异军突起，一场名为 AI 的技术革命迅速从学术圈蔓延到了工业界，所谓 AI 革命从此拉开了帷幕。

经过三年的发展，AI 有了许许多多的落地场景，包括智能客服、人脸识别、机器翻译、以图搜图等功能。其实机器学习或者说是人工智能，并不是什么新鲜的概念。而这次热潮的背后，云计算的普及以及算力的巨大提升，才是真正将人工智能从象牙塔带到工业界的一个重要推手。

与之相对应的，从 2016 年开始，Kubernetes 社区就不断收到来自不同渠道的大量诉求。希望能在 Kubernetes 集群上运行 TensorFlow 等机器学习框架。这些诉求中，除了前面课程所介绍的，像 Job 这些离线任务的管理之外，还有一个巨大的挑战：深度学习所依赖的异构设备及英伟达的 GPU 支持。

我们不禁好奇起来：Kubernetes 管理 GPU 能带来什么好处呢？本质上是成本和效率的考虑。由于相对 CPU 来说，GPU 的成本偏高。在云上单 CPU 通常是一小时几毛钱，而 GPU 的花费则是从单 GPU 每小时 10 元 ~ 30 元不等，这就要想方设法的提高 GPU 的使用率。

为什么要用 Kubernetes 管理以 GPU 为代表的异构资源？

具体来说是三个方面：

• 加速部署：通过容器构想避免重复部署机器学习复杂环境；
• 提升集群资源使用率：统一调度和分配集群资源；
• 保障资源独享：利用容器隔离异构设备，避免互相影响。

首先是加速部署，避免把时间浪费在环境准备的环节中。通过容器镜像技术，将整个部署过程进行固化和复用，如果同学们关注机器学习领域，可以发现许许多多的框架都提供了容器镜像。我们可以借此提升 GPU 的使用效率。

通过分时复用，来提升 GPU 的使用效率。当 GPU 的卡数达到一定数量后，就需要用到 Kubernetes 的统一调度能力，使得资源使用方能够做到用即申请、完即释放，从而盘活整个 GPU 的资源池。

而此时还需要通过 Docker 自带的设备隔离能力，避免不同应用的进程运行同一个设备上，造成互相影响。在高效低成本的同时，也保障了系统的稳定性。

20.2、GPU的容器化

如何利用容器运行GPU：

• 构建支持GPU的容器镜像: 可以使用官方容器镜像(NVIDIA/CUDA,Tensorflow/tensorflow)，或者基于官方镜像构建自己的镜像
• 利用Docker将该容器run 起来，并把GPU设备--dev和依赖库--volume映射到容器中

1、如何在宿主机上安装GPU应用

底层是安装驱动，中间是CUDA库，最上层是机器学习框架。容器镜像构建一般驱动和CUDA分开，这样的好处后可以使用不同版本的CUDA镜像。

2、利用容器运行GPU程序

这里比较复杂的是GPU 应用依赖的驱动库。对于深度学习，视频处理等不同场景，所使用的一些驱动库并不相同。这又需要依赖 Nvidia 的领域知识，而这些领域知识就被贯穿到了 Nvidia 的容器之中。

注意，新版docker，可以支持docker --gpu 方式直接使用 gpu资源 链接

20.3、k8s的GPU管理

参考：https://github.com/NVIDIA/k8s-device-plugin

• 1、安装NVIDIA驱动

  • yum install gcc kerbel-devel-$(uname -r) #驱动需要编译内核
  • sh ./NVIDIA-linux-x86_64*.run

• 2、安装NVIDIA Docker2

  • yum install nvidia-docker2
  • 重新加载docker daemon，查看daemon.json是否docker runtime已经替换。也可以通过docker info确认

• 3、部署NVIDIA Device Plugin

  • kubectl apply -f nvidia-device-plugin.yml 链接 //K8s版本后要求，
  • kubectl describe node/${GPU_NODENAME} |grep -i nvidia 查看
  • kubectl exec -it ${gpu_podname} -- nvidia-smi 查看隔离效果

  创建示例Pod：
  apiVersion: v1
  kind: Pod
  metadata:
  name: gpu-pod
  spec:
  containers:
    - name: cuda-container
      image: nvcr.io/nvidia/cuda:9.0-devel
      resources:
        limits:
          nvidia.com/gpu: 2 # requesting 2 GPUs
    - name: digits-container
      image: nvcr.io/nvidia/digits:20.12-tensorflow-py3
      resources:
        limits:
          nvidia.com/gpu: 2 # requesting 2 GPUs
  
  

20.4、工作机制

Kubernetes 本身是通过插件扩展的机制来管理 GPU 资源的，具体来说这里有两个独立的内部机制。

• Extended Resource
  • 允许用户自定义资源名称。而该资源的度量是整数级别，这样做的目的在于通过一个通用的模式支持不同的异构设备，包括 RDMA、FPGA、AMD GPU 等等，而不仅仅是为 Nvidia GPU 设计的；
• Device Plugin Framework
  • 允许第三方设备提供商以插件的方式对设备进行全生命周期的管理，而 Device Plugin Framework 建立 Kubernetes 和 Device Plugin 模块之间的桥梁。它一方面负责设备信息的上报到 Kubernetes，另一方面负责设备的调度选择。

20.4.1、Extended Resource的上报

Extend Resources 属于 Node-level 的 api，完全可以独立于 Device Plugin 使用。而上报 Extend Resources，只需要通过一个 PACTH API 对 Node 对象进行 status 部分更新即可，而这个 PACTH 操作可以通过一个简单的 curl 命令来完成。这样，在 Kubernetes 调度器中就能够记录这个节点的 GPU 类型，和对应的资源数量。当然如果使用的是 Device Plugin，就不需要做这个 PACTH 操作，只需要遵从 Device Plugin 的编程模型，在设备上报的工作中 Device Plugin 就会完成这个操作。

20.4.2、Device Plugin的工作机制

整个 Device Plugin 的工作流程可以分成两个部分：

• 一个是启动时刻的资源上报；
• 另一个是用户使用时刻的调度和运行。

Device Plugin 的开发非常简单。主要包括最关注与最核心的两个事件方法：

• 其中 ListAndWatch 对应资源的上报，同时还提供健康检查的机制。当设备不健康的时候，可以上报给 Kubernetes 不健康设备的 ID，让 Device Plugin Framework 将这个设备从可调度设备中移除；

• 而 Allocate 会被 Device Plugin 在部署容器时调用，传入的参数核心就是容器会使用的设备 ID，返回的参数是容器启动时，需要的设备、数据卷以及环境变量。

20.4.3、Device Plugin整个资源上报和监控流程

对于每一个硬件设备，都需要它所对应的 Device Plugin 进行管理，这些 Device Plugin 以客户端的身份通过 GRPC 的方式对 kubelet 中的 Device Plugin Manager 进行连接，并且将自己监听的 Unis socket api 的版本号和设备名称比如 GPU，上报给 kubelet。

整个 Device Plugin 资源上报的整个流程。总的来说，整个过程分为四步，其中前三步在节点上，第四步是 kubelet 和 api-server 的交互。

• 第一步是 Device Plugin 的注册，需要 Kubernetes 知道要跟哪个 Device Plugin 进行交互。这是因为一个节点上可能有多个设备，需要 Device Plugin 以客户端的身份向 Kubelet 汇报三件事情。
  • 我是谁？就是 Device Plugin 所管理的设备名称，是 GPU 还是 RDMA；
  • 我在哪？就是插件自身监听的 unis socket 所在的文件位置，让 kubelet 能够调用自己；
  • 交互协议，即 API 的版本号。
• 第二步是服务启动，Device Plugin 会启动一个 GRPC 的 server。在此之后 Device Plugin 一直以这个服务器的身份提供服务让 kubelet 来访问，而监听地址和提供 API 的版本就已经在第一步完成了；
• 第三步，当该 GRPC server 启动之后，kubelet 会建立一个到 Device Plugin 的 ListAndWatch 的长连接， 用来发现设备 ID 以及设备的健康状态。当 Device Plugin 检测到某个设备不健康的时候，就会主动通知 kubelet。而此时如果这个设备处于空闲状态，kubelet 会将其移除可分配的列表。但是当这个设备已经被某个 Pod 所使用的时候，kubelet 就不会做任何事情
• 第四步，kubelet 会将这些设备暴露到 Node 节点的状态中，把设备数量发送到 Kubernetes 的 api-server 中。后续调度器可以根据这些信息进行调度。

需要注意的是 kubelet 在向 api-server 进行汇报的时候，只会汇报该 GPU 对应的数量。而 kubelet 自身的 Device Plugin Manager 会对这个 GPU 的 ID 列表进行保存，并用来具体的设备分配。而这个对于 Kubernetes 全局调度器来说，它不掌握这个 GPU 的 ID 列表，它只知道 GPU 的数量。这就意味着在现有的 Device Plugin 工作机制下，Kubernetes 的全局调度器无法进行更复杂的调度。比如说想做两个 GPU 的亲和性调度，同一个节点两个 GPU 可能需要进行通过 NVLINK 通讯而不是 PCIe 通讯，才能达到更好的数据传输效果。在这种需求下，目前的 Device Plugin 调度机制中是无法实现的。

20.4.4、pod额调度和运行

Pod 想使用一个 GPU 的时候，它只需要像之前的例子一样，在 Pod 的 Resource 下 limits 字段中声明 GPU 资源和对应的数量 (比如nvidia.com/gpu: 1)。Kubernetes 会找到满足数量条件的节点，然后将该节点的 GPU 数量减 1，并且完成 Pod 与 Node 的绑定。

绑定成功后，自然就会被对应节点的 kubelet 拿来创建容器。而当 kubelet 发现这个 Pod 的容器请求的资源是一个 GPU 的时候，kubelet 就会委托自己内部的 Device Plugin Manager 模块，从自己持有的 GPU 的 ID 列表中选择一个可用的 GPU 分配给该容器。此时 kubelet 就会向本机的 Device Plugin 发起一个 Allocate 请求，这个请求所携带的参数，正是即将分配给该容器的设备 ID 列表。

Device Plugin 收到 AllocateRequest 请求之后，它就会根据 kubelet 传过来的设备 ID，去寻找这个设备 ID 对应的设备路径、驱动目录以及环境变量，并且以 AllocateResponse 的形式返还给 kubelet。

AllocateResponse 中所携带的设备路径和驱动目录信息，一旦返回给 kubelet 之后，kubelet 就会根据这些信息执行为容器分配 GPU 的操作，这样 Docker 会根据 kubelet 的指令去创建容器，而这个容器中就会出现 GPU 设备。并且把它所需要的驱动目录给挂载进来，至此 Kubernetes 为 Pod 分配一个 GPU 的流程就结束了。

20.5、扩展

1、Devie Plugin机制的缺陷

• 设备资源调度发生在kubelet层面，缺乏全局调度视角
• 资源上报信息有限导致精细度不足，单纯以数字描述，如果想要指定不同类型的GPU呢？
• 调度策略简单，并且无法配置，无法应对复杂场景

2、社区的异构资源调度方案

• Nvidia GPU Device Plugin: https://github.com/NVIDIA/k8s-device-plugin
• GPU Share Device Plugin: https://github.com/AliyunContainerService/gpushare-device-plugin
• DRMA Device Plugin: https://github.com/Mellanox/k8s-rdma-sriov-dev-plugin
• FPGA Device Plugin: ...

参考链接： https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/

第二十一章、kubernetes存储架构及插件使用

21.1、Kubernetes挂载Volume过程

1、用户创建pvc和pod后
2、pv controller会watch到api-server获取PVC状态，发现PVC处于unbind状态，pv controller尝试调用将pv和pvc绑定，从集群中找到一个合适的pv进行绑定。如果发现集群中没有合适的pv，就调用Volume Plugin去做provisioner(去具体的一个Storage volume上去创建一个volume，并且创建一个pv对象)，然后将pv和pvc绑定。
3、Scheduler根据一定的规则选择合适的worker node进行pod的调度
4、AD Controller发现Pod调度到某一个node上后，这个pod定义的pv还没有挂载。就调用Volume plugin将volume设备挂载到目标节点的设备上去
5、kubelet的volume manger组件，发现一个pod挂载到自己所在的worker上后，并且pod的volume已完成了挂载(步骤4)，调用volume plugin将设备挂载到pod的工作目录中去，volume manager也会做一些格式化等操作
6、最后一步把本地的一个pod的目录映射到容器中

21.2、Kubernetes存储架构

(D:\PERSON_BOOK\k8s\魂尊.assets\image-20210223110644875.png)

Provison => Attach => Mount;Umount=> Detach => Delete;

• PV Controller: 负责PV/PVC的绑定、生命周期管理，并根据需求进行数据卷的Provision/Delete操作
• AD Controller: 负责存储设备的Attach/Detach操作，将设备挂载到目标节点；
• Volume Manager: 管理卷的Mount/Unmount操作、卷设备的格式化等
• Volume Plugins: 扩展各种存储类型的卷管理能力，实现第三方存储的各种操作能力与Kubernetes存储系统结合；
• Scheduler: 实现Pod调度能力，存储相关的调度器实现了对存储卷配置进行调度；

21.2.1、PV Controller介绍

1、主要概念:

• PersistentVolume: 持久存储卷，详细定义预挂载存储空间的各项参数；无NameSpace限制，一般由Admin创建维护PV；
• PersistentVolumeClaim:持久化存储卷定义，用户使用的存储接口，对存储细节无感知，属于某NameSpace内；
• StorageClasss: 存储类，创建PV存储的模板类，即系统会按照StorageClass定义的存储模板创建存储卷(包括真实存储空间和PV对象)

2、主要任务:

• PV、PVC生命周期管理：创建、删除PV对象；负责pv、pvc的状态转换
• 绑定PVC、PV对象：一个PVC必须与一个PV绑定后才能被应用使用，pv-controller会根据绑定条件和对象状态对PV、PVC进行Bound、Unbound操作