理解kubernetes调度

K8s的资源分为两类，一类是可压缩资源（compressible resources），比如CPU，也就是当资源不足的时候Pod不会退出。另一类资源是不可压缩资源（incompassible resources），比如内存，其典型特点是当该资源不足的时候，Pod会因为OOM（Out Of Memory）被内核杀掉。
建议半个CPU配置用cpu=500m表示，而不是cpu=0.5（一个cpu=1000m，也就是cpu=1）1Mi=10241024；1M=10001000
request和limit区别是：在调度的时候，kube-scheduler 只会按照 requests 的值进行计算。而在真正设置 Cgroups 限制的时候，kubelet 则会按照 limits 的值来进行设置。
当宿主机资源紧张的时间kubelet就会对Pod进行Eviction（资源回收），这时候会运用到QoS划分：
第一个会删除的是BestEffort类Pod，也就是Pod 既没有设置 requests，也没有设置 limits。接下来第二个会删除的是Burstable类Pod。这是至少有一个 Container 设置了 requests。那么这个 Pod 就会被划分到 Burstable 类别最后一类会删除的Pod是Guaranteed，也就是设置了request和limit，或者只设置limit的Pod。
Eviction 在 Kubernetes 里分为 Soft 和 Hard 两种模式。Soft Eviction 允许你为 Eviction 过程设置一段“优雅时间”，比如文章里的例子里的 imagefs.available=2m，就意味着当 imagefs 不足的阈值达到 2 分钟之后，kubelet 才会开始 Eviction 的过程。而 Hard Eviction 模式下，Eviction 过程就会在阈值达到之后立刻开始。
Kubernetes 计算 Eviction 阈值的数据来源，主要依赖于从 Cgroups 读取到的值，以及使用 cAdvisor 监控到的数据。
当宿主机的 Eviction 阈值达到后，就会进入 MemoryPressure 或者 DiskPressure 状态，从而避免新的 Pod 被调度到这台宿主机上。它使用taint把node taint，就无法调度Pod到其node之上了。
cpuset 方式是生产环境里部署在线应用类型的 Pod 时，非常常用的一种方式。设置 cpuset 会把容器绑定到某个 CPU 的核上，而不是像 cpushare 那样共享 CPU 的计算能力，这样能大大减少CPU之间上下文切换次数，从而提高容器性能。设置cpuset的方式是，首先Pod 必须是 Guaranteed 的 QoS 类型；然后，你只需要将 Pod 的 CPU 资源的 requests 和 limits 设置为同一个相等的整数值即可
K8s项目中默认调度器的主要职责是就是为了新创建出来的Pod寻找一个最合适的Node。
调度器首先会调用一组叫Predicate的调度算法，来检每一个Node。然后再调用一组叫作Priority的调度算法来给上一步得到的结果里的每一个Node打分。最终的调度结果就是得分最高的那个Node。
Kubernetes 的调度器的核心，实际上就是两个相互独立的控制循环。第一个是Informer Path，主要是启动一系列Informer用来监听(Watch)Etcd中的Pod,Node, Service等与调度相关的API对象的变化。此外，Kubernetes 的默认调度器还要负责对调度器缓存（即：scheduler cache）进行更新。事实上，Kubernetes 调度部分进行性能优化的一个最根本原则，就是尽最大可能将集群信息 Cache 化，以便从根本上提高 Predicate 和 Priority 调度算法的执行效率。第二个控制循环是Scheduling Path，主要逻辑是不断从调度队列里调出Pod，然后用Predicates算法进行过滤，得到一组可以运行这个Pod的宿主机列表，然后再用Priority打分，得分高的称为Pod结果。

Predicates在调度过程中的作用，可以理解为Filter，也就是按照调度策略从当前的集群所有节点中“过滤”出一些符合条件的节点来运行调度的 Pod。
默认的调度策略有三种，一种是GerenalPredicates，负责最基础的调度策略，比如计算宿主机CPU和内存资源等是否够用的PodFitsResource；还有检查宿主机名字是否和Pod的spec.nodeName一致的PodFitsHost。第二类是和Volume相关的过滤规则，比如NoDiskConflict是检查多个Pod申明挂载的持久化Volume是否有冲突。第三类是宿主机相关的过滤条件，主要考察待调度的Pod是否满足Node本身条件，比PodToleratesNodeTaints，负责检查Node 的“污点”taint机制，而 NodeMemoryPressurePredicate，检查的是当前节点的内存是不是已经不够充足，如果是的话，那么待调度 Pod 就不能被调度到该节点上。第四种类型是和Pod相关的过滤规则，这一组规则，跟 GeneralPredicates 大多数是重合的。而比较特殊的，是 PodAffinityPredicate。在具体执行的时候， 当开始调度一个 Pod 时，Kubernetes 调度器会同时启动 16 个 Goroutine，来并发地为集群里的所有 Node 计算 Predicates，最后返回可以运行这个 Pod 的宿主机列表。
在 Predicates 阶段完成了节点的“过滤”之后，Priorities 阶段的工作就是为这些节点打分。这里打分的范围是 0-10 分，得分最高的节点就是最后被 Pod 绑定的最佳节点。Priorities 里最常用到的一个打分规则，是LeastRequestedPriority。这个算法实际上就是在选择空闲资源（CPU 和 Memory）最多的宿主机。此外，还有 NodeAffinityPriority、TaintTolerationPriority 和 InterPodAffinityPriority 这三种 Priority。在默认 Priorities 里，还有一个叫作 ImageLocalityPriority 的策略。它是在 Kubernetes v1.12 里新开启的调度规则，即：如果待调度 Pod 需要使用的镜像很大，并且已经存在于某些 Node 上，那么这些 Node 的得分就会比较高。

Kuberentes中可以为Pod设置优先级，高优先级的Pod可以： 1、在调度队列中先出队进行调度 2、调度失败时，触发抢占，调度器为其抢占低优先级Pod的资源。
Kuberentes默认调度器有两个调度队列：
activeQ：凡事在该队列里的Pod，都是下一个调度周期需要调度的
unschedulableQ: 存放调度失败的Pod，当里面的Pod更新后就会重新回到activeQ，进行“重新调度”
默认调度器的抢占过程： 确定要发生抢占 -> 调度器将所有节点信息复制一份，开始模拟抢占 -> 检查副本里的每一个节点，然后从该节点上逐个删除低优先级Pod，直到满足抢占者能运行 -> 找到一个能运行抢占者Pod的node -> 记录下这个Node名字和被删除Pod的列表 -> 模拟抢占结束 -> 开始真正抢占 -> 删除被抢占者的Pod，将抢占者调度到Node上

Kuberentes通过Extended Resource来支持自定义资源，比如GPU。为了让调度器知道这种自定义资源在各Node上的数量，需要的Node里添加自定义资源的数量。实际上，这些信息并不需要人工去维护，所有的硬件加速设备的管理都通过Device Plugin插件来支持，也包括对该硬件的Extended Resource进行汇报的逻辑。
Device Plugin 、kubelet、调度器如何协同工作：
汇报资源： Device Plugin通过gRPC与本机kubelet连接 -> Device Plugin定期向kubelet汇报设备信息，比如GPU的数量 -> kubelet 向APIServer发送的心跳中，以Extended Reousrce的方式加上这些设备信息，比如GPU的数量
调度： Pod申明需要一个GPU -> 调度器找到GPU数量满足条件的node -> Pod绑定到对应的Node上 -> kubelet发现需要拉起一个Pod，且该Pod需要GPU -> kubelet向 Device Plugin 发起 Allocate()请求 -> Device Plugin根据kubelet传递过来的需求，找到这些设备对应的设备路径和驱动目录，并返回给kubelet -> kubelet将这些信息追加在创建Pod所对应的CRI请求中 -> 容器创建完成之后，就会出现这个GPU设备（设备路径+驱动目录）-> 调度完成