我一直在阅读 kubernetes 文档https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container
但我仍然不清楚spec.containers[].resources.limits.cpu和spec.containers[].resources.requests.cpu之间的区别以及对资源限制的影响是什么
你能推荐一些用普通英语解释的读物或书籍吗？
提前致谢
【问题讨论】：
标签： kubernetes doc
当 Kubernetes pod 被调度在特定节点上时，它需要 pod 有足够的资源来运行。 Kubernetes 知道其节点的资源，但 Kubernetes 是如何知道 pod 需要多少资源才能在节点中有效调度它的。为此将使用requests。当我们指定资源的request 时，kubernetes 将保证 pod 将获得该数量的资源。
另一方面，limit 限制了 pod 的资源使用。 Kubernetes 不允许 Pod 占用比 limit 更多的资源。当涉及到 CPU 时，如果您请求更多 Kubernetes，则会人为地限制 pod CPU。如果 pod 超过 limit pod，它将被终止。为了简单起见，limit 总是比 request 大。
本示例将让您了解request 和limit。认为有一个 pod，您将其内存请求指定为 7GB，内存限制指定为 10GB。集群中有三个节点，其中 node1 有 2GB 内存，node2 有 8GB 内存，node3 有 16GB。您的 pod 永远不会被安排在 node1 上。但它会在 node2 或 node3 上调度，具体取决于 pod 当前内存使用情况。但是如果调度在node3上，在任何情况下都会被终止，超过10GB的内存使用量。
【讨论】：
简而言之： 对于 cpu 和内存请求：k8s 保证您在调度程序调度您的 pod 时所声明的内容。
对于 cpu & memory 的限制：k8s 保证你不能超过你设置的值。
您的 pod 超出限制时的结果：
【讨论】：
记忆有点难以理解。 requests 是有保证的，limits 是不能超过的。这也意味着，例如，当您发出kubectl describe nodes | tail -10 时，您可能会看到这样的短语：
"Total limits may be over 100 percent, i.e., overcommitted".
这意味着requests.memory的总和是100%（否则无法调度pod，这就是保证内存的意思）。同时，如果你看到一个值高于然后100%，这意味着limits.memory的总和可以超过100%（这是消息中的过度使用部分） .所以当一个节点尝试调度一个 pod 时，它只会检查requests.memory 看它是否有足够的内存。
如果更复杂的话，cpu 部分。
requests.cpu 转换为 cpu 份额，如果不查看节点上的所有 pod，说实话可能几乎没有意义。恕我直言，了解此属性的最简单方法是查看示例。
假设您在一个节点上有 100 个可用内核，您部署一个 pod 并设置 requests.cpu = 1000m。在这种情况下，您的 pod 可以使用 100 个 cpu、bot min 和 max。
您拥有同一台机器（100 个核心），但您使用 requests.cpu = 1000m 部署了两个 pod。在这种情况下，每个 pod 可以使用最少 50 个内核，最多 100 个内核。
同一个节点，4 个 pod (requests.cpu = 1000m)。每个 pod 最少可以使用 25 个 cpu，最多可以使用 100 个。
您了解情况，重要的是 所有 pod 为 requests.cpu 设置什么以获得总体情况。
limits.cpu 更有趣，它转换为 cgroup 上的 两个 属性：cpu period 和 cpu quota。这意味着您可以在某个时间范围（期间）内获得多少时间（配额）。一个例子也应该让这里的事情变得更简单。
period=100ms 和 quota=20ms 收到一个请求，该请求将在您的 pod 上的 50ms 中完成。这就是它的样子：
| 100ms || 100ms || 100ms |
| 20 ms ......|| 20 ms ......|| 10 ms ......|
因为处理请求需要50ms，而我们只有20ms 可用于每个100ms，所以总共需要300ms 来处理我们的请求。
话虽如此，还是有很多人建议根本不要设置cpu。谷歌工程师、zalando、monzo 等 - 包括我们。我们不这样做，这样做有充分的理由（超出了这个问题）。
【讨论】：