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

[yyttrr]

两个月前为了降本增效，按照实际使用量 95%最大值的 1.35 倍给了 request ，3 倍给了 limit

完成之后的确释放了一波节点，月成本有下降

经过两个月的业务需求上线，很多 deployment 的 hpa 要么不伸缩，要么时不时的打到上限

看了看业务代码，有些是加了个全局 map 导致内存增大，有些是拆出去一个新微服务导致老微服务使用率很低，还有突然上线一个活动导致一个 deployment oom 了

几百个无状态微服务，我自己手动调整太累，让研发调整不太现实

[isno]

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

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

[pc10201]

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

[yyttrr]

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

[yyttrr]

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

[RatioPattern]

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

[julyclyde]

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

[caicaiwoshishui]

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