《深入剖析Kubernetes》总结十：资源管理和调度

资源模型与资源管理

资源模型设计

CPU 和内存资源的限额要配置在每个 Container 的定义上，Pod 整体的资源配置，就由这些 Container 的配置值累加得到

Kubernetes 里为 CPU 设置的单位是“CPU 的个数”，，具体“1 个 CPU”在宿主机上如何解释，是 1 个 CPU 核心，还是 1 个 vCPU，还是 1 个 CPU 的超线程（Hyperthread），完全取决于宿主机的 CPU 实现方式

对于内存资源来说，它的单位就是 bytes

Kubernetes 里 Pod 的 CPU 和内存资源，实际上还要分为 limits 和 requests 两种情况：：在调度的时候，kube-scheduler 只会按照 requests 的值进行计算，而在真正设置 Cgroups 限制的时候，kubelet 则会按照 limits 的值来进行设置；
其设计思想参考了Brog：容器化作业在提交时所设置的资源边界，并不一定是调度系统所必须严格遵守的，这是因为在实际场景中，大多数作业使用到的资源其实远小于它所请求的资源限额，基于这种假设，在作业被提交后，可以主动减小它的资源限额配置，以便容纳更多的作业、 提升资源利用率。而当作业资源使用量增加到一定阈值时，可以通过“快速恢复”过程，还原作业原始的资源限额，防止出现异常情况

Kubernetes 的 requests+limits 的做法是Brog思路的一个简化版：用户在提交 Pod 时，可以声明一个相对较小的 requests 值供调度器使用，而 Kubernetes 真正设置给容器 Cgroups 的，则是相对较大的 limits 值

QoS模型

不同的 requests 和 limits 的设置方式，会将 Pod 划分到不同的 QoS 级别当中

当 Pod 里的每一个 Container 都同时设置了 requests 和 limits，并且 requests 和 limits 值相等的时候，这个 Pod 就属于 Guaranteed 类别

当 Pod 不满足 Guaranteed 的条件，但至少有一个 Container 设置了 requests，那么这 个 Pod 就会被划分到 Burstable 类别。

如果一个 Pod 既没有设置 requests，也没有设置 limits，那么它的 QoS 类别就是 BestEffort

QoS 划分的主要应用场景，是当宿主机资源紧张的时候，kubelet 对 Pod 进行 Eviction（即资源回收）时需要用到的：当 Kubernetes 所管理的宿主机上不可压缩资源短缺时，就有可能触发 Eviction，比 如，可用内存（memory.available）、可用的宿主机磁盘空间（nodefs.available），以及容器运行时镜像存储空间（imagefs.available）等等（CPU为可压缩，当可压缩资源不足时，Pod 只会“饥饿”，但不会退出）

Eviction 在 Kubernetes 里分为 Soft 和 Hard 两种模式：
Soft Eviction 模式允许开发者为 Eviction 过程设置一段“优雅时间”；
Hard Eviction 模式下，Eviction 过程就会在阈值达到之后立刻开始

当宿主机的 Eviction 阈值达到后，就会进入 MemoryPressure 或者 DiskPressure 状态，从而避免新的 Pod 被调度到这台宿主机上（给宿主机打了污点标记）

当 Eviction 发生的时候，kubelet 具体会挑选哪些 Pod 进行删除操作，就需要参考这些 Pod 的 QoS 类别了：

<