转自：https://testerhome.com/topics/31561?order_by=like&，https://fafucoder.github.io/2020/11/05/kubernetes-qos/

https://github.com/bmwx4/k8s-in-practice/blob/master/resource-quotas/pod-qos.md

1.资源模型

在k8s中，任何可以被申请、分配，最终被使用的对象，都是 kubernetes 中的资源，k8s 默认 只支持 CPU 和内存的定义。

所有的资源类型，可以被划分为两大类：可压缩和不可压缩的。

 K8s中pod 对资源的申请是以容器为最小单位进行的，针对每个容器，它都可以通过如下两个信息指定它所希望的资源量：

resources:  
 requests:    
   cpu: 2.5   
   memory: "40Mi"  
 limits:     
   cpu: 4.0    
   memory: "99Mi"

 request：

• 容器使用的最小资源需求， 作为容器调度时资源分配的判断依据
• 只有当前节点上可分配的资源 >= request 才允许将容器调度到该节点
• request参数不限制容器的最大可用资源
• 即便容器没有实际使用到这些资源， k8s 也会为容器预留好这些资源， 也就是说其他容器是无法申请这些资源的。

 limit：

• 容器能使用资源的最大值。如果容器使用的资源超过了这个值， 就会触发后续对应的操作。CPU是限速，内存是OOM。
• 设置为0表示对使用的资源不做限制，可无限的使用

 关系：request能保证pod有足够的资源来运行, 而limit则是防止某个pod无限制的使用资源, 导致其他pod崩溃. 两者的关系必须满足:

0 <= request <= limit <= Infinity

 limit 的资源限制是通过 cgroups 来进行限制的。 每个 POD，每个容器都会在/sys/fs/cgroup 下留有对应的记录：

2.超卖 

超卖比高简单理解就是，request低，limit高，那么针对一些不重要的服务，低优先级的，request设置就可以比limit小很多，如果是重要的，那么两者设置的一样大。

3.QoS服务质量

当kubernetes集群中某个节点上可用资源比较小时，kubernetes提供了资源回收策略来保证节点上POD正常运行。因为如果节点上的内存或者CPU资源耗尽时，这个节点上运行的POD就会变成不稳定。

原则是在保证服务质量的同时，尽量提高资源的利用率。

分为以下3个级别：

•  BestEffort：POD中的所有容器都没有指定CPU和内存的requests和limits；（优先级最低，最危险，首先被驱逐。因为它没有声明任何资源的使用， 包括 request 和 limit。 所以理论上它可以占用整个节点的资源。 ）
• Burstable：POD中只要有一个容器，这个容器requests和limits的设置同其他容器设置的不一致，那么这个POD的QoS就是Burstable级别；【超卖场景】
• Guaranteed：POD中所有容器都必须统一设置了limits，并且设置参数都一致，如果有一个容器要设置requests，那么所有容器都要设置，并设置参数同limits一致，那么这个POD的QoS就是Guaranteed级别。

被定义为 Guaranteed 的 POD 优先级是最高的，pod 明确了 request 和 limit 的数字并且是相等的， 等于告诉 k8s 不管什么情况， 我都要使用这么多资源。 而 k8s 会最优先保证这种 pod 的资源使用。

先驱逐谁： 

当节点资源紧张时，可以停止某些POD。BestEffort级别的会先被杀死，Guaranteed的最后被杀死，那么相同级别的杀死顺序：是依据它们已使用的资源占request比例来确定的，越高得分越高，先被杀死。对于两个同属于 Burstable 的 pod， 系统会先杀掉内存实际使用量占内存申请量的比例更高的pod。 所以pod B先被杀掉，尽管 pod C比pod B使用了更多的内存。

1. Kubernetes 自带的组件使用Guarantee
2. 重要的组件和应用，比如ZooKeeper、Redis，ES、用户服务等使用Guarantee
3. 普通的应用（Burstable）按照重要性分级，按重要程度CPU分为2，5，10三个超卖标准，10倍超卖适合访问量不高。（也就是超卖比越高，说明服务优先级越低）
4. 内存使用固定的1.5倍超卖标准。
5. 在生产环境中，不要使用 BestEffort 的方式，它会引发不确定的行为。