一、了解Pod Qos等级
一个节点不一定能提供所有pod所指定的资源limits之和那么多的资源量。
假设有两个pod,pod A使用了节点内存的 90%,pod B突然需要比之前更多的内存，这时节点无法提供足量内存，哪个容器将被杀掉呢？应该是pod B吗？因为节点无法满足它的内存请求。或者应该是pod A吗？这样释放的内存就可以提供给pod B了。
显然，这要分情况讨论。Kubernetes无法自己做出正确决策，因此就需要一种方式，我们通过这种方式可以指定哪种pod在该场景中优先级更高。Kubernetes将pod划分为3种QoS等级：
- BestEffort（优先级最低）
- Burstable
- Guaranteed（优先级最高
1.1 定义pod的Qos等级
QoS等级来源于pod所包含的容器的资源requests和limits的配置。下面介绍分配QoS等级的方法。
为pod分配BestEffort等级
最低优先级的QoS等级是BestEffort。会分配给那些没有（为任何容器）设置任何requests和limits的pod。在这个等级运行的容器没有任何资源保证。在最坏情况下，它们分不到任何CPU时间，同时在需要为其他pod释放内存时，这些容器会第一批被杀死。不过因为BestEffort pod没有配置内存limits，当有充足的可用内存时，这些容器可以使用任意多的内存。
为pod分配Guaranteed等级
与Burstable相对的是Guaranteed等级，会分配给那些所有资源request和limits相等的pod。对于一个Guaranteed级别的pod，有以下几个条件：
- CPU和内存都要设置requests和limits
- 每个容器都需要设置资源量
- 它们必须相等（每个容器的每种资源的requests和limits必须相等）
因为如果容器的资源requests没有显式设置，默认与limits相同，所以只设置所有资源（pod内每个容器的每种资源）的限制量就可以使pod的QoS等级为Guaranteed。这些pod的容器可以使用它所申请的等额资源，但是无法消耗更多的资源（因为它们的limits和requests相等）。
为pod分配Burstable等级
Burstable QoS等级介于BestEffort和Guaranteed之间。其他所有的pod都属于这个等级。
1. 容器的requests和limits不相同的单容器pod，
2. 至少有一个容器只定义了requests但没有定义limits的pod，
3. 一个容器的requests和limits相等，但是另一个容器不指定requests或limits的pod。
Burstable pod可以获得它们所申请的等额资源，并可以使用额外的资源（不超过limits）。
requests和limits之间的关系如何定义QoS等级
举例：3个QoS等级和它们与requests和limits之间的关系
资源的requests、limits和QoS等级
考虑一个pod应该属于哪个QoS等级足以令人脑袋快速运转，因为它涉及多个容器、多种资源，以及requests和limits之间所有可能的关系。如果一开始从容器级别考虑QoS（尽管它并不是容器的属性，而是pod的属性），然后从容器QoS推导出pod QoS，这样可能更容易理解。
1.2 明白容器的QOS等级
基于资源requests和limits如何为单个容器定义QoS等级。对于单容器pod，容器的QoS等级也适用于pod。
基于资源请求量和限制量的单容器pod的QoS等级
注意 如果设置了requests而没有设置limits，参考表中requests小于limits那一行。如果设置了limits,requests默认与limits相等，因此参考request等于limits那一行。
了解多容器pod的QoS等级
对于多容器pod，如果所有的容器的QoS等级相同，那么这个等级就是pod的QoS等级. 如果至少有一个容器的QoS等级与其他不同，无论这个容器是什么等级，这个pod的QoS等级都是Burstable等级。
由容器的QoS等级推导出pod 的QoS等级
注意 运行 kubectl describe pod 以及通过pod的YAML/JSON描述的status.qosClass 字段都可以查看pod的QoS等级。
1.3 Qos根据等级杀掉容器
1.3.1 内存不足时，哪个进程会被杀
QoS等级决定着哪个容器第一个被杀掉，这样释放出的资源可以提供给高优先级的pod使用。BestEffort等级的pod首先被杀掉，其次是Burstable pod，最后是Guaranteed pod。Guaranteed pod只有在系统进程需要内存时才会被杀掉。
杀死顺序：BestEffort Pod--->Burstable Pod--->Guaranteed Pod
1.3.2 了解QoS等级的优先顺序
假设两个单容器的pod，第一个属于BestEffort QoS等级，第二个属于Burstable等级。当节点的全部内存已经用完，还有进程尝试申请更多的内存时，系统必须杀死其中一个进程（甚至包括尝试申请额外内存的进程）以兑现内存分配请求。这种情况下，BestEffort等级运行的进程会在Burstable等级的进程之前被系统杀掉。
显然，BestEffort pod的进程会在Guaranteed pod的进程之前被杀掉。同样地，Burstable pod的进程也先于Guaranteed pod的进程被杀掉。但如果只有两个Burstable pod会发生什么呢？很明显需要选择一个优先于另一个的进程。
1.3.3 如何处理相同QoS等级的容器
每个运行中的进程都有一个称为OutOfMemory（OOM）分数的值，系统通过比较所有运行进程的OOM分数来选择要杀掉的进程。当需要释放内存时，分数最高的进程将被杀死。
OOM分数由两个参数计算得出：进程已消耗内存占可用内存的百分比，与一个基于pod QoS等级和容器内存申请量固定的OOM分数调节因子。对于两个属于Burstable等级的单容器的pod，系统会杀掉内存实际使用量占内存申请量比例更高的pod。
使用了内存申请量 90% 的pod B在pod C（只使用了70%）之前被杀掉的原因，尽管pod C比pod B使用了更多兆字节的内存。
转自：https://zhuanlan.zhihu.com/p/359854581
标签：容器,QoS,limits,pod,requests,等级 From： https://www.cnblogs.com/yangmeichong/p/16636317.html