在Amazon Elastic Kubernetes Service（EKS）环境的上下文中，我目前管理着一个中等规模的开发集群，它的大小与我们的生产集群不同。在确定给定Pod的CPU资源分配时，如果我的开发集群需要1000 mCPU（mCPU），我是否应该为我的生产集群保留同等的CPU分配？1000 mCPU是不同集群大小的一致指标吗？
在回顾了几个信息资源后，我注意到CPU分配基本上与Pod被授予的总CPU时间有关。然而，重要的是要考虑到更强大的底层机器可以在相同的时间单位内处理更大的工作量。我可以安全地假设我对这个概念的解释是准确的吗？
2条答案
按热度按时间taor4pac1#
各种因素都会影响环境之间工作负载的资源消耗。
正如你提到的，其中之一是潜在的二手机器味道。
此外，应用程序上下文也可能影响例如数据类型、分析数据量等。
此外，每个节点上运行的Pod数量可能会有所不同，并导致更多/更少的CPU上下文切换，节流，并影响工作负载消耗的CPU量。
我建议采用数据驱动的方法来应对这一挑战。
您可以定期使用vpa或krr等工具来调整资源大小，请求和限制适合您的策略，希望它能有所帮助。
uyhoqukh2#
我是否应该为我的生产群集维护一个等效的CPU分配？
如果您需要一些类似于生产集群的测试结果，例如针对开发集群上的服务运行性能测试，以确保在升级到生产集群之前的工作负载，则应该这样做。
1000 mCPU是不同集群大小的一致指标吗？
不，它是，因为具有较高CPU频率的机器可以比较低CPU频率的机器处理更多的任务。
;tldr;
Kubernetes CPU限制是关于CPU时间，它使用Linux内核上的CFS带宽控制通过2个参数（cfs_peroid_ms，cfs_quota_ms）来管理它们
cfs_period_us是set to 100ms (100k microseconds) by defaultcfs_quota_us来自用户通过CPU限制值。因此，如果将CPU限制设置为1,000 m，则意味着1 vCPU或1，000 millicores（m）= 100，000微秒（us）= 100毫秒（ms）
如果应用程序运行的任务超过100毫秒，它将被限制，这意味着延迟增加。
您可以查询cAdvisor指标，例如
container_cpu_cfs_throttled_periods_total、container_cpu_cfs_throttled_seconds_total、container_cpu_cfs_periods_total。以查看限制。因此，让我们在查询指标和遇到节流问题时增加CPU限制。
引用
我希望这个答案可以帮助你。