kubernets之了解Qos等级
一 Qos的种类
- BestEffort(优先级最低)
- Burstable(中等优先级)
- Guaranteed(最高优先级)
二 Qos的作用
众所周知，节点上面的limits允许超卖，当节点上面的内存总值大于100的时候，就必须要对某个容器删除，从而为其他容器腾出来内存空间，以上的Qos等级就决定着当出现上述情况的时候，优先杀死哪些pod里面的容器，这便是Pod的Qos的作用。
三 如何评定一个pod的Qos等级
3.1 为pod分配Guaranteed等级
这个等级是pod的最高优先级，而如果需要能够分配这个等级的pod需要具备几下几个条件
-
- cpu和内存都要设置requests和limits
- 每个容器都要设置资源值
- 他们必须相等(每个容器的每种资源的requests和limits必须相等)
因为如果容器的资源requests没有显示设置，默认与limits相等，所以只设置所有资源的限制量就可以使pod的Qos等级为Guaranteed,这些pod的容器可以使用它所申请的等额资源，但无法消耗更多，因为它们的requests和limits值相等
3.2 为pod分配Burstable等级
这个Qos等级介于BestEffort和Guaranteed之间，requests和limits值为一下情况
-
- pod里面的容器设置了requests或者limits，但是他们的数值不相等的单容器pod
- 多容器pod里面的至少有一个pod未设置limits值，或者未设置requests值(这个和未设置requests效果一样)
因为pod可以申请节点上面的requests值，并且可以使用系统额外的值
3.3 为pod分配BestEffort等级
这个等级是pod的最低等级，这个pod里面的容器的requests和limits的值是如下情况
-
- pod里面的所有的容器的requests和limits值都未被设置
- 这个pod的里面的容器在系统的内存出现超卖的时候会优先被kill
- 这个pod的里面的容器在系统资源充足的时候，可任由pod里面的容器对系统的资源进行访问
3.4 让我们来通过一幅图来更直观和贴切的描述requests和limits的设置是如何决定pod的Qos等级
3.5 通过评定容器的Qos等级从而判定pod的Qos等级
申明一下，容器实际上并没有Qos这一说法的，我们是以评定pod的方式来评定容器的Qos，进而通过pod里面的容器的Qos来评定Pod的Qos等级，这里给出一张列表
-
- 如果设置了requests而为设置limits，则参考Requests<limits一列
- 如果设置了limits，而没有设置requests的话，则参考Requests=Limits这一列
- 单容器的pod，容器的Qos就等于pod的Qos
3.6 多容器的pod的Qos则由pod里面的所有容器的Qos来决定，可以参考下表进而得到结论，这里假设以2个容器的pod为例
- 总结起来正正得正，负负得负，正负则取中间态
- 当两个容器的的Qos都为BestEffort则pod的Qos也为BestEffort
- 当两个容器的Qos都为Guaranteed则pod的Qos也为Guaranteed
- 如果一个为BestEffort，另一个为Guaranteed则pod的Qos为Burstable
四 了解在超卖系统中，哪个进程优先会被杀死
4.1 在超卖系统中，Qos等级决定着哪个pod会优先被杀掉，BestEffort最先会被干掉，其次是Burstable，最后才会是Guaranteed的pod被干掉(Guaranteed只有当系统级别的pod的资源不足才会被干掉)，我们通过一幅图来展示并对其中哪个优先级会被杀死来说明。
- 当系统中的资源超卖的时候，被优先处理的顺序是BestEffort > Burstable > Guaranteed
- 当释放完所有的BestEffort的pod的时候仍然节点内存依然不足的情况下，就会考虑释放Burstable的pod
- 由于系统中处于Burstable的pod较多，仍然需要一个比较规则，来决定超卖的时候先处理哪个pod，可能让你惊讶的是，系统并不是根据谁使用的内存量多的优先处理谁，而是根据资源使用量比上实际使用量的比值，优先处理更大的比值
- 综上所述，我们在为pod的容器分配requests和limits的时候不仅仅需要注意两个的值，同时还需要还要留意requests和实际使用的内存资源大小的关系
