Kubernetes 弹性伸缩全场景解析（一）：概念延伸与组件布局( 三 )_：Kubernetes弹性伸缩全场景解析（一）

在 Kubernetes 中是通过 Request 和 Limit 的方式进行设置，Request 表示资源的申请值，Limit 表示资源的限制值。既然 Request 和 Limit 才是容量规划的对等概念，那么这就代表着资源的实际计算规则要根据 Request 和 Limit 才更加准确。而对于每个节点预留资源阈值而言，很有可能会造成小节点的预留无法满足调度，大节点的预留又调度不完的场景。

3. 资源利用率困境

集群的资源利用率是否可以真的代表当前的集群状态呢？当一个 Pod 的资源利用率很低的时候，不代表就可以侵占它所申请的资源。在大部分的生产集群中，资源利用率都不会保持在一个非常高的水位，但从调度来讲，资源的调度水位应该保持在一个比较高的水位。这样才能既保证集群的稳定可用，又不过于浪费资源。

如果没有设置 Request 与 Limit，而集群的整体资源利用率很高这意味着什么？这表示所有的 Pod 都在被以真实负载为单元进行调度，相互之间存在非常严重的争抢，而且简单的加入节点也丝毫无法解决问题，因为对于一个已调度的 Pod 而言，除了手动调度与驱逐之外没有任何方式可以将这个 Pod 从高负载的节点中移走。那如果我们设置了 Request 与 Limit 而节点的资源利用率又非常高的时候说明了什么呢？很可惜这在大部分的场景下都是不可能的，因为不同的应用不同的负载在不同的时刻资源的利用率也会有所差异，大概率的情况是集群还没有触发设置的阈值就已经无法调度 Pod 了。