如何精确调整业务服务的资源 request 和 limit？

我之前代码分析过 1000 多个服务，手动不现实，运维最多把资源大盘搞出来，把成本分析发给各个业务部门，降本增效得联合开发一起搞。还有 limit 是你设置的，OOM 影响业务了，你没背锅？

说说我的想法：
把降本的 KPI 丢给研发，确定百万用户/成本，每万请求多少钱之类的指标，核算出一个业务的上限预算。
和业务部门确定服务分级，预估资源。 分配不同的 namespace ，通过 namespace 设置资源限制，再弄个预警机制，超限了让研发确认原因，核心服务不要限死 limit ，服务挂了被大锅。

自己学写程序，调用 api 调整

@isno 有个保底的自动扩容程序在，一个 pod oom 了自动扩 pod 到 hpa max 的 2 倍，说是网络波动搪塞过去了
我们一个组 20 几个后端研发，对 k8s 有概念的不超过 3 个，让他们自己接手资源调整和 hpa 调整得培训几次，不知道领导会不会觉得我在甩锅~

@pc10201 我举了几个例子，一个微服务业务上什么时候变得重要了，资源消耗多了少了我是无法知道的，也无法预测，滞后的调整为了稳定性得留下大量冗余，要么资源使用率上不去，要么稳定性受到影响

这么点研发上 limit ，折腾人，你们公司要裁员了吧

主要看这活是不是你的职责了
如果是你的职责，那你就做好，并计入工作成绩，别推脱太累
如果不是你的职责，你给个大概参考意见就行了

你这个明显要区分活动中的 deployment 和平时 deployment 的流量
搞活动需要提前扩容呀，扩容完就缩回去。