我在Kubernetes中部署了一项服务，并且我正在尝试优化requested cpu resources。
[目前，我已经部署了10个实例，并根据“平均”使用率将spec.containers[].resources.limits.cpu设置为0.1。但是，很明显，该平均值在实践中几乎没有用，因为在恒定负载下，负载显着增加（据我所知达到0.3-0.4）。
因此，当在同一节点上部署多个实例时，该节点将严重过载；吊舱不再响应，被杀死并重新启动等。
寻找最佳价值的最佳实践是什么？我目前的最佳猜测是将请求的cpu增加到0.3或0.4；我正在查看Grafana可视化效果，并看到负载较重的节点上的容器在连续负载下会聚在此处。但是，如何知道如果节点过载，它们是否会在响应之前就使用更多负载呢？
实际上，我实际上是在试图了解如何解决这个问题。我希望“理想”服务（假定它是针对CPU的）在没有负载时使用接近0.0的值，而在不断有请求进入时使用接近1.0的值。在这种假设下，我应该设置[C0 ]到cpu.requests，以假设实际恒定使用量为视角？
[我读过一些1.0，但是似乎没有一个比“找到平均值”更深入地讨论如何为cpu请求设置实际值。
基本上给出一个数字，该数字是您对该进程运行多少的较低可接受范围。设置为Kubernetes best practice guides的请求意味着您可以接受进程的下限，大约每隔1秒钟的壁垒时间运行0.1秒。通常，这应该是某种平均利用率，通常是几天或几周内的P99或P95值。我个人通常查看30天的P99，P80和P50（中位数）图表，然后使用该图表来确定值。
限制是另一种野兽，它们正在设置您的CPU时间片配额。 Linux中的该子系统有一些持续存在的错误，因此，除非您特别检查内核是否正确，否则不建议将其用于除最恶意的程序之外的任何程序。
简而言之：主要目标是了解Pod可以处理多少流量以及为此消耗的资源。
CPU限制很难理解，可能有害，您可能想要为避免它们，请参见100m和static policy documentation。
要确定您的CPU请求的大小，您首先需要了解在高负载下Pod会消耗多少。为此，您可以：
您最终将获得比率locust。您可以假设该关系为线性（（如果您的工作负载复杂度为O（n ^ 2），且连接的客户端数量为n，则可能不正确，但这不是正常情况）。
然后您可以选择一个与此编号有关的请求，例如，如果您消耗1.2 cpu的速度每秒处理1000个请求，那么您知道可以给每个Pod分配1 cpu的速度，它每秒最多可以处理800个请求。
现在，您知道Pod在最大负载下可以消耗多少，您可以开始设置基于CPU的自动缩放，如果遇到延迟或Pod不能足够快速地自动缩放等问题，可以将70％作为首选目标。如果负载增加，这将避免您的节点用尽cpu。
有一些陷阱，例如单线程应用程序不能消耗更多的CPU。因此，如果您给它1.5 cpu，它将用完cpu，但是您将无法从指标中看到它，因为您会认为它仍然会消耗0.5 cpu。