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和实际使用的内存资源大小的关系