这是我参与「第四届青训营」笔记创作活动的第 16天
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 上。什么是合适呢？
- 1、首先要满足 pod 的资源要求；
- 2、其次要满足 pod 的一些特殊关系的要求；
- 3、再次要满足 node 的一些限制条件的要求；
- 4、最后还要做到整个集群资源的合理利用。
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 方案里面的资源，还是能成功的。
