3.2.4 QoS设置
在处理的过去问题当中，很多情况下对于pod的Qos方面，没有投入过多的关注，但是pod 的qos对于pod的调度和驱逐策略方面来说非常重要。
Pod的QoS主要分为三个等级
•Guaranteed（优先级最高）：
Pod中每个容器都必须包含内存和CPU的request和limits；
request和limits需要相等；
•Burstable：
Pod不符合Guaranteed的QoS
Pod中至少一个容器具有内存和CPU的request或limits
•BestEffffort（优先级最低）：
Pod中的容器没有设置内存和CPU的request或limits
我们知道k8s允许节点超买，即节点上所有的limits总和允许大于ECS的分配资源，但是request一定是小于ECS的分配资源，这时候会产生一种场景，假如节点上的pod在同时需要大量资源，这时候必然会造成节点层面的资源超限，那么对于K8s来说，是如何处理这种场景呢？假如节点上现在有两个pod：pod A和pod B。Pod A使用了节点的内存的95%。这时候pod B突然由于应用使用，需要比之前更多的内存，这时候节点无法满足总的内存需求，这时候k8s选择是kill pod A 还是pod B呢？显然，k8s无法自己做出判断这时候需要的就是上面所说的Qos机制了。
图：Pod QoS示意图
在一个超卖的系统，QoS等级决定着哪个容器第一个被杀掉，这样释放出的资源可以提供给高优先级的pod使用。BestEffffort等级的pod首先被杀掉，其次是Burstable pod，最后是Guaranteed pod。Guaranteed pod只有在系统进程需要内存时才会被杀掉。
图：Pod Kill示意图
那么就产生一个疑问，k8s是如何处理相同QoS等级的容器呢？
每个运行中的进程都有一个称为OutOfMemory（OOM）分数的值。系统通过比较所有运行进程的OOM分数来选择要杀掉的进程。
当需要释放内存时，分数最高的进程将被杀死。 OOM分数由两个参数计算得出：进程已消耗内存占可用内存的百分比，与一个基于pod QoS等级和容器内存申请量固定的OOM分数调节因子。对于两个属于Burstable等级的单容器的pod，系统会杀掉内存实际使用量占内存申请量比例更高的pod。这就是上图中使用了内存申请量 90% 的pod B在pod C（只使用了70%）之前被杀掉的原因，尽管pod C比pod B使
用了更多兆字节的内存。
这说明我们不仅要注意requets和limits之间的关系，还要留心requests和预期实消耗内存之间的关系。
既然上面已经提到了相关的request和limits，及时节点上所有的pod都设置了limits，也建议一个节点上的limits不要超卖太多，以防大部分pod在同一时间承受高业务流量，造成节点上的资源被打满，或者把业务高峰期的pod错开放置在不同节点上，以实现资源利用最大化同时，不影响节点上的其他应用，这个需要在应用部署的时候结合业务行为指定部署的最优解。
