给 pod 定义或不定义 CPU 限制是一个有争议的讨论。

对于复杂的应用程序来说，定义资源请求和限制并不容易，它需要大量的测试和监控。但是，有时我们可能会做出有根据的猜测并不时对其进行迭代，这种情况更符合实际。

问题是大多数人并不完全了解 Kubernetes 请求和限制的内部工作原理，这很好，我们没有时间精通 Kubernetes 和其他工具的每一个组件。这就是我写这篇文章的原因，这篇文章将关注 CPU 资源，关于内存后续有时间再进行阐述。

为什么有人说 CPU 限制不好

让我们从一个例子开始，我们有两个 Pod，A和B。Pod A的 CPU 总是很低，它使用从 100m 到 200m，而B是一个不断接收请求并保持CPU使用率中等到高的应用程序，从 300m 到500m。假设我们的节点总共有1000m 可用。

最坏的情况是 700m（A 200m + B 500m），我们有 300m 空闲。问题是，在不可预测的事件中，结果可能大相径庭，考虑以下场景：

1. A和B 没有任何要求或限制。如果 pod B开始占用大量CPU时间，比如 980m，那么 A 将只有 20m 可用，这样将导致应用程序的状态不稳定。
2. 我们将B的CPU限制设置为 500m，现在A不会存在资源不够，因为B有限制。但是如果A消耗 100m，B 消耗 500m，那么我们有 400m 未使用。
3. 现在限制A的资源，而 B 没有设置限制。现在A为 CPU 请求 200m，而B没有限制。当 B开始占用大量 CPU 时，A不会受到影响，因为可以保证它总是有 200m 供他使用。

始终设置 CPU 请求。这是基线，也是你唯一可以依靠的。 - Tim Hockin，Kubernetes 维护者

Pod 可以保证获得它们请求的 CPU 数量，它们可能会或可能不会获得额外的 CPU 时间（取决于正在运行的其他作业）。

如何定义 CPU 请求

我相信每个集群都会有空闲的 CPU 周期，并且每个 pod 同时出现峰值的概率很低。考虑到这一点，我们可以做出更好的决定。

这是一个权衡，它是关于成本与性能的。如果将它设置得太高，成本会很高，但你的 pod 总是有很多资源可以使用。如果你太低，充分利用资源，但你不会满足你的 SLOs。

【参考k8s测试小组的文档，
可以使用
SLI（Service Level indicators）和 SLO(Service Level Objectives)
来定义集群性能的衡量标准和集群性能要达到的目标】。

何时使用 CPU 限制

如果你想知道什么时候应该使用限制，应该将 CPU 请求限制为等于 CPU 限制，然后运行压力测试，找到最坏的情况，并根据需要优化成本与性能的权衡。