本文介绍下K8s的三种服务质量等级：

给容器配置申请资源（cpu或内存）request和最大使用资源limit的方式，

requests是需要使用的集群资源的大小，limits是使用的集群资源上限；

Mi是M*1024 byte，标准值是64M；

k8s把cpu分成了1000份，250m为0.25cpu，也可以写1.0或0.5；

requests和limits设定值的不同会影响到pod在集群中的生存周期和服务质量等级。

Guaranteed(可保证的)

requests和limits值一样是可保证的服务质量等级，等级是最高的，资源是可保证的；把pod下的所有的容器加起来requests=limits，才是这种pod等级。

如果在集群当中只有一个node（cpu 16核，内存64G），node上的2个pod都是一样的配置（cpu 8核，内存 32G），把这2个pod调度到这个节点上之后，这两个pod申请的资源正好是节点所占用的，当然这个节点就不可以被其他pod所使用了，pod自身没有crash的时候，就永远运行在这个节点之上，集群可以保证这两个pod的资源一旦被集群的节点所分配，就永远使用。

缺点是可能存在资源浪费：

在实际使用中大部分情况是只使用一部分资源 ，大部分pod所申请的资源都是浪费的。

Burstable(突发的)

requests小于limits或者只有requests没有limits，表示突发的服务质量等级，一般或默认的情况下使用requests设定的资源，极端的情况使用limit设定的资源；

先申请requests，大部分情况下都是使用这么多资源，极限的情况下，可能会使用更多的资源，但不会超过limits限制。

把节点上可分配的资源定义成free：节点可分配资源-节点所申请的资源=剩余的内存和cpu，系统上的所有资源减去在节点上运行的系统的进程，比如kubelet进程（这个进程可能会保留一部分资源，但是非常少），剩下的资源就是可分配的资源。

集群会按pod申请的资源，把pod调度到这个节点上；

pod requests资源来决定空闲的资源剩余是否足够大，如果足够大的话，才会把pod调度到这个节点上即pod能否调度到这个节点上运行是根据requests资源决定的。

当request小于limit或根本没有limit，使用实际的cpu或内存可能就会超过所设定的limit值；

当request资源小于limit资源的时候，在极端情况下或特殊情况下，cpu实际使用量会超过request，内存的实际使用量也可能会超过request，当出现这两种情况下的时候k8s如何处理的pod？

cpu实际使用未达到limit或没有limit

cpu的实际使用超过了request但没有超过limit或者没有limit，当需要更多的cpu的时候，k8s按request量等比例分配分配空闲的资源，集群允许pod把节点上所有的cpu资源给用了，反正闲着也是闲着。

cpu实际使用达到limit

如果实际使用的cpu超过了limit，pod1获取1个cpu +0.5cpu=1.5cpu，这个是pod1的上限，pod2理论上可以获取剩下的2个cpu，但它的上限是2个cpu，所以它最多可以获的1个cpu达到limit。

任何情况下都按照request和free分配pod

这个时候又有一个新的pod，pod3依然是可以被调度到这个节点，因为k8s是以request量作为使用标准，保证pod使用的资源量；在没有其他pod的时候，pod1和pod2按照剩余资源的比例进行分配；有新的pod的时候，剩余资源就会被使用，pod1和pod2虽然程序需要更多的cpu，但是没有更多的cpu可以使用了，虽然limit=1.5但实际上没有那么多cpu供使用，就变成了pod1、pod2、pod3共同使用。

内存实际使用的超过了request，只要应用需要更多的内存，只要有空闲的内存，可持续使用空闲内存直到limit。

overcommit

2个pod对内存的需求已经超过了节点的剩余内存空间，k8s允许limits超过节点可用内存，超过的部分叫overcommit。

cpu是可压缩资源（内存是不可压缩资源），所以集群可以控制cpu的使用，比如程序使用2个cpu，但实际上可能使用不到2个cpu，内存不一样，比如程序需要使用32g，但如果只给8个g，这个情况下会OOM；允许overcommit的原因是k8s在赌所有的容器不会同时达到limit内存；极端的情况下，所有的容器都达到了极限，

在这种情况下，其中的pod将会被驱离，由于内存是不可压缩资源，当内存产生压力时，k8s会将pod从节点上移除以获得空闲内存，牺牲某个或某些pod，让剩下的pod得以继续运行，驱离的pod在当前节点上被kill，但是集群会选择其他的资源够的节点再把它重新启动起来，如果没有其他可用的节点，服务就宕了。

BestEffort(尽力而为的)

这种情况是request和limit都不设定，

BestEffort是服务等级最低的情况，只要具备空闲cpu或空闲内存的节点上，pod都会被调度过去：

1、以低优先级获得cpu资源，在极端情况下无法获取cpu资源，其他的pod把cpu用完的时候，BestEffort这样的pod就获取不到任何的cpu资源；

2、当内存产生压力时最先被驱离

小结

三种不同的服务质量等级其实面向三种不同的应用场景：

Guaranteed适合面向服务型应用

集群需要保证申请的资源，pod只要调度到节点上，就不会因为系统资源问题被驱离或被终止这样的情况产生；

Burstable适合面向中型应用

• 只有request的资源可以被保证

• 在节点内存吃紧时可能被驱离

BestEffort适合面向任务型应用

比如计算任务或日志分析类型，有资源就启动，没有资源被驱离

• 以低优先级获取空闲cpu资源

• 在极端的情况下会无cpu使用

• 在节点内存吃紧时优先被驱离