所属技术领域：
Kubernetes
|名词定义|
Requests是容器请求要使用的资源，Kubernetes 会保证 Pod 能使用到这么多的资源。请求的资源是调度的依据，只有当节点上的可用资源大于 Pod 请求的各种资源时，调度器才会把 Pod 调度到该节点上（如果 CPU 资源足够，内存资源不足，调度器也不会选择该节点）。
需要注意的是，调度器只关心节点上可分配的资源，以及节点上所有 Pods 请求的资源，而不关心节点资源的实际使用情况，换句话说，如果节点上的 Pods 申请的资源已经把节点上的资源用满，即使它们的使用率非常低，比如说 CPU 和内存使用率都低于 10%，调度器也不会继续调度 Pod 上去。
|技术特点|
通过 request 和 limit 的组合来确定我们想要的 QoS level。
- Guaranteed Pod
Kubernetes必备知识： Kubernetes资源模型requests
Kubernetes 里面有一个要求：如果你要创建出一个 Guaranteed Pod，那么你的基础资源（包括 CPU 和 memory），必须它的 request==limit，其他的资源可以不相等。只有在这种条件下，它创建出来的 pod 才是一种 Guaranteed Pod，否则它会属于 Burstable，或者是 BestEffort Pod。
- Burstable Pod
Kubernetes必备知识： Kubernetes资源模型requests
比如说上面的例子，可以不用填写 memory 的资源，只要填写 CPU 的资源，它就是一种 Burstable Pod。
- BestEffort Pod
Kubernetes必备知识： Kubernetes资源模型requests
第三类 BestEffort Pod，它也是条件比较死的一种使用方式。它必须是所有资源的 request/limit 都不填，才是一种 BestEffort Pod。
不同的 QoS 表现
接下来，为大家介绍一下：不同的 QoS 在调度和底层表现有什么样的不同？不同的 QoS，它其实在调度和底层表现上都有一些不一样。比如说调度表现，调度器只会使用 request 进行调度，也就是说不管你配了多大的 limit，它都不会进行调度使用。
在底层上，不同的 Qos 表现更不相同。比如说 CPU，它是按 request 来划分权重的，不同的 QoS，它的 request 是完全不一样的，比如说像 Burstable 和 BestEffort，它可能 request 可以填很小的数字或者不填，这样的话，它的时间片权重其实是非常低的。像 BestEffort，它的权重可能只有 2，而 Burstable 或 Guaranteed，它的权重可以多到几千。
requests的特点
1.requests用于schedule阶段，在调度pod保证所有pod的requests总和小于node能提供的计算能力
2.requests.cpu被转成docker的--cpu-shares参数，与cgroup cpu.shares功能相同
设置容器的cpu的相对权重
该参数在CPU资源不足时生效，根据容器requests.cpu的比例来分配cpu资源
CPU资源充足时，requests.cpu不会限制container占用的最大值，container可以独占CPU
3.requests.memory没有对应的docker参数，作为k8s调度依据
4.使用requests来设置各容器需要的最小资源
关于Requests的底层实现机制：
|资料来源|
名词定义：
https://blog.51cto.com/dangzhiqiang/2298673技术特点：
https://blog.csdn.net/zhonglinzhang/article/details/80663249 https://blog.csdn.net/qq180782842/article/details/87719739