所属技术领域:
Kubernetes
|名词定义|
Requests是容器请求要使用的资源,Kubernetes 会保证 Pod 能使用到这么多的资源。请求的资源是调度的依据,只有当节点上的可用资源大于 Pod 请求的各种资源时,调度器才会把 Pod 调度到该节点上(如果 CPU 资源足够,内存资源不足,调度器也不会选择该节点)。
需要注意的是,调度器只关心节点上可分配的资源,以及节点上所有 Pods 请求的资源,而不关心节点资源的实际使用情况,换句话说,如果节点上的 Pods 申请的资源已经把节点上的资源用满,即使它们的使用率非常低,比如说 CPU 和内存使用率都低于 10%,调度器也不会继续调度 Pod 上去。
|技术特点|
通过 request 和 limit 的组合来确定我们想要的 QoS level。
- Guaranteed Pod
Kubernetes 里面有一个要求:如果你要创建出一个 Guaranteed Pod,那么你的基础资源(包括 CPU 和 memory),必须它的 request==limit,其他的资源可以不相等。只有在这种条件下,它创建出来的 pod 才是一种 Guaranteed Pod,否则它会属于 Burstable,或者是 BestEffort Pod。
- Burstable Pod
比如说上面的例子,可以不用填写 memory 的资源,只要填写 CPU 的资源,它就是一种 Burstable Pod。
- BestEffort Pod
第三类 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