计算资源管理 QoS

了解pod QoS等级

假设有两个 pod, pod A 使用了节点内存的 90%, pod B 突然需要比之前更多的内存，这时节点无法提供足量内存，哪个容器将被杀掉呢？应该是 pod B 吗？因为节点无法满足它的内存请求， 或者应该是 pod A 吗？这样释放的内存就可以提供给pod B 了。
显然，这要分情况讨论。 Kubernetes 无法自己做出正确决策，因此就需要一种方式，通过这种方式可以指定哪种 pod 在该场景中优先级更高。
Kubernetes pod 划分为三种 QoS 等级

• BestEffort （优先级最低）
• Burstable
• Guaranteed （优先级最高）

定义 pod QoS 等级

QoS 等级来源 pod 所包含的容器的资源 requests 和 limits 的配置。

为 pod 分配 BestEffort 等级
最低优先级的 QoS 等级是 BestEffort 会分配给那些没有（为任何容器）设置任何 requests 和 limits pod 。在个等级运行的容器没有任何资源保证。在最坏情况下，它们分不到任何 CPU 时间，同时要为其他 pod 释放内存时， 这些容器会第一批被杀死，不过因为 BestEffortpod 没有配置内存 limits，当有充足的可用内存时，这些容器可以使用任意多的内存

为 pod 分配 Guaranteed 等级
与 Burstable 相对的是 Guaranteed 等级，会分配给那些所有资源 request 和 limits 相等的 pod。 对于一个 Guaranteed 级别的 pod ，有以下几个条件：

• CPU 和内存都要设置 requests 和 limits
• 每个容器都需要设置资源量
• 它们必须相等（每个容器的每种资源的 requests 和 limits 必须相等）

因为如果容器的资源 request 没有显式设置，默认与 limits 相同，所以只设置所有资源（pod 内每个容器的每种资源）的限制量就可以使 pod 的 QoS 等级为Guaranteed。这些 pod 容器可以使用它所申请的等额资源，但是无法消耗更多的资源（因为它们的 limits 和 requests 相等）。

为 pod 分配 Burstable 等级
Burstable QoS 级介于 BestEffort Guaranteed 之间。其他所有 pod 属于这个等级。 包括容器的 requests 和 limits 不相同的单容器 pod ，至少有一个容器只定义了 requests 但没有定义 limits 的pod ，以及一个容器的 request limits 相等，但是另一个容器不指定 requests 或 limits 的 pod。Burstable 可以获得它们所申请的等额资源，并可以使用额外的资源（不超过 imits）。

kubectl describe pod kubia
QoS Class:                   BestEffort


kubectl  get pod kubia -o yaml
status:
qosClass: BestEffort

内存不足时哪个进程会被杀死

在一个超卖的系统，QoS 等级决定着哪个容器第一个被杀掉， 这样释放出的资源可以提供给高优先级的 pod 使用。 BestEffort 等级的 pod 首先被杀掉， 其次是 Burstable pod, 最后是Guaranteed pod。 Guaranteed pod 只有在系统进程需要内存时才会被杀掉。

了解 QoS 等级的优先顺序

请看上图中的例子。 假设两个单容器的pod, 第一个属于BestEffort QoS 等级， 第二个属于 Burstable 等级。 当节点的全部内存已经用完， 还有进程尝试申请更多的内存时，系统必须杀死其中一个进程（甚至包括尝试申请额外内存的进程）以兑现内存分配请求。这种情况下， BestEffort 等级运行的进程会在 Burstable 等级的进程之前被系统杀掉。
显然， BestEffort pod 的进程会在 Guaranteed pod 的进程之前被杀掉 。 同样地，Burstable pod 的进程也先于 Guaranteed pod 的进程被杀掉 。 但如果只有两个 Burstable pod 会发生什么呢？很明显需要选择一个优先于另 一个的进程。

如何处理相同QoS等级的容器
每个运行中的进程都有一个称为 OutOfMemory (OOM)分数的值。 系统通过比较所有运行进程的 OOM 分数来选择要杀掉的进程。 当需要释放内存时， 分数最高的进程将被杀死。

OOM分数由两个参数计算得出：进程已消耗内存占可用内存的百分比， 与 一个基于 pod QoS等级和容器内存申请量固定的 OOM 分数调节因子。 对于两个属于 Burstable 等级的单容器的 pod ，系统会杀掉内存实际使用量占内存申请量比例更高的 pod。 这就是图中使用了内存申请量90%的 pod B 在 pod C（只使用了70%) 之前被杀掉的原因， 尽管 pod C 比 pod B 使用了更多兆字节的内存 。

这说明我们不仅要注意 requets 和 limits 之间的关系， 还要留心 requests 和预期实际消耗内存之间的关系。

__EOF__

本文作者：何时&明月
本文链接：https://www.cnblogs.com/kiyalone/p/15957133.html
关于博主：当你发现自己的才华支撑不起野心时，就请安静下来学习吧！
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！