虽然 Kubernetes 运行时可以为 Pod 提供比“请求”更多的 CPU 直至“限制”，但由于当时的节点 CPU 状况，无法保证这种情况会发生。也许所有 CPU 都被其他 Pod 和进程使用。
如果我增加CPU“请求”，那么它有两个缺点：
1- Pod 部署可能更具挑战性，因为应该存在具有足够 CPU 的节点，因此部署可能需要时间或失败
2-我为 Pod 预留和分配了不必要的 CPU 量，该 Pod 只需要一点点 CPU 即可启动和工作，并且在高负载/高峰时间可能/将需要更多 CPU。
如果我设置了一个小的 CPU“请求”，那么无法保证 Kubernetes 是否可以在稍后高峰时间和高负载期间需要时为 pod 提供足够的所需 CPU。
另一个问题是我想在监控仪表板中设置 CPU 使用率警报。
如果我观察“请求”的 CPU 使用百分比并设置警报，这是没有意义的，因为 K8s 通常会在高峰时间为 pod 提供它想要的东西。
如果我不这样做，而是查看“限制”的CPU使用率百分比，那么也许K8s无法提供足够的CPU，并且Pod在我不知情的情况下大多数时候都会遇到麻烦。
我不知道该怎么办。不确定我是否理解它是如何工作的，或者我完全错了。
CPU是一种可压缩资源，这意味着它可以以安全的方式进行限制，如果节点受到压力，它将开始限制容器使用的CPU，但不会杀死它们。如果节点中有足够的CPU，它将开始根据用作权重的节点的预留CPU来共享剩余的CPU，预留的越多，未使用的CPU份额就越大。
如果您的应用程序具有一致的行为，您应该能够将请求/限制数量调整为相当好的估计，这应该限制每个节点的限制，但它不能保证您的容器不会受到限制，除非你设置请求==限制；那么你在山谷时段的处境就很糟糕了。
集群自动缩放是峰值利用率的一个很好的解决方案，它会查找由于资源限制而无法运行的 pod 中的问题，并根据需要调整集群的大小，无论是向上还是向下：https://github.com/kubernetes /自动缩放器/树/主/集群自动缩放器
如果您想了解更多信息，这是有关 QoS 的相关设计方案的链接：