kubernetes/了解 CPU 资源限制 [英] kubernetes / understanding CPU resources limits
问题描述
多年来在裸机上运行 node/rails 应用程序；我曾经能够在一台机器上运行任意数量的应用程序(假设，基于正确的优化或相当低的流量，数字海洋的 2Go 可以轻松处理 10 个应用程序而无需担心)
Coming from numerous years of running node/rails apps on bare metal; i was used to be able to run as many apps as i wanted on a single machine (let's say, a 2Go at digital ocean could easily handle 10 apps without worrying, based on correct optimizations or fairly low amount of traffic)
问题是，使用 kubernetes，游戏听起来完全不同.我已经设置了一个带有 2 个标准虚拟机 (3.75Go) 的入门"集群.
Thing is, using kubernetes, the game sounds quite different. I've setup a "getting started" cluster with 2 standard vm (3.75Go).
使用以下内容为部署分配限制:
Assigned a limit on a deployment with the following :
resources:
requests:
cpu: "64m"
memory: "128Mi"
limits:
cpu: "128m"
memory: "256Mi"
然后见证以下内容:
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
--------- ---- ------------ ---------- --------------- -------------
default api 64m (6%) 128m (12%) 128Mi (3%) 256Mi (6%)
这 6% 指的是什么?
What does this 6% refers to ?
尝试降低 CPU 限制，例如 20Mi……应用确实启动了(显然，没有足够的资源).文档说它是 CPU 的百分比.那么，20% 的 3.75Go 机器?那么这6%是从哪里来的呢?
Tried to lower the CPU limit, to like, 20Mi… the app does to start (obviously, not enough resources). The docs says it is percentage of CPU. So, 20% of 3.75Go machine ? Then where this 6% comes from ?
然后将节点池的大小增加到 n1-standard-2，相同的 pod 有效地跨越了节点的 3%.这听起来合乎逻辑，但它实际上指的是什么?
Then increased the size of the node-pool to the n1-standard-2, the same pod effectively span 3% of node. That sounds logical, but what does it actually refers to ?
仍然想知道这部分需要考虑哪些指标.
Still wonder what is the metrics to be taken in account for this part.
该应用似乎在启动时需要大量内存，但随后它只使用了这 6% 的极小部分.然后我觉得我误解了某些东西，或者滥用了它
The app seems to need a large amount of memory on startup, but then it use only a minimal fraction of this 6%. I then feel like I misunderstanding something, or misusing it all
感谢任何有经验的提示/建议，以便更好地理解最好的
Thanks for any experienced tips/advices to have a better understanding Best
推荐答案
6% 的 CPU 意味着 6%(CPU 请求)的节点 CPU 时间是为这个 Pod 预留的.所以它保证它总是至少获得这个数量的 CPU 时间.如果还有剩余的 CPU 时间，它仍然可以达到 12%(CPU 限制).
The 6% of CPU means 6% (CPU requests) of the nodes CPU time is reserved for this pod. So it guaranteed that it always get at lease this amount of CPU time. It can still burst up to 12% (CPU limits), if there is still CPU time left.
这意味着如果限制非常低，您的应用程序将需要更多时间来启动.因此，活性探针可能会杀死 pod在它准备好之前，因为应用程序花费了太长时间.要解决这个问题，您可能需要增加活性探测器的 initialDelaySeconds 或 timeoutSeconds.
This means if the limit is very low, your application will take more time to start up. Therefore a liveness probe may kill the pod before it is ready, because the application took too long. To solve this you may have to increase the initialDelaySeconds or the timeoutSeconds of the liveness probe.
另请注意，资源请求和限制定义了您的 pod 分配的资源数量，而不是实际使用量.
Also note that the resource requests and limits define how many resources your pod allocates, and not the actual usage.
- 资源请求是保证您的 Pod 在节点上获得的资源.这意味着，请求的资源总和不得高于该节点上的 CPU/内存总量.
- 资源限制是您的 pod 允许使用的上限.这意味着这些资源的总和可能高于实际可用的 CPU/内存.
因此，百分比告诉您 Pod 分配的总资源的 CPU 和内存量.
Therefore the percentages tell you how much CPU and memory of the total resources your pod allocates.
文档链接:https://kubernetes.io/docs/user-指南/计算资源/
其他一些值得注意的事情:
Some other notable things:
- 如果您的 Pod 使用的内存超过限制中定义的内存，则会出现 OOMKilled(内存不足).
- 如果您的 pod 使用的内存多于请求中定义的内存，并且节点运行我们的内存，则 pod 可能会被 OOMKilled 以保证其他 pod 能够生存，这些 pod 使用的内存少于其请求的内存.
- 如果您的应用程序需要的 CPU 超过请求的数量，它可能会突然达到限制.
- 您的 pod 永远不会被杀死，因为它使用了过多的 CPU.
这篇关于kubernetes/了解 CPU 资源限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
