这是一个创建于 515 天前的主题，其中的信息可能已经有所发展或是发生改变。
两个月前为了降本增效，按照实际使用量 95%最大值的 1.35 倍给了 request ，3 倍给了 limit
完成之后的确释放了一波节点，月成本有下降
经过两个月的业务需求上线，很多 deployment 的 hpa 要么不伸缩，要么时不时的打到上限
看了看业务代码，有些是加了个全局 map 导致内存增大，有些是拆出去一个新微服务导致老微服务使用率很低，还有突然上线一个活动导致一个 deployment oom 了
几百个无状态微服务，我自己手动调整太累，让研发调整不太现实
7 条回复 • 2023-08-25 16:21:53 +08:00
 |
1
isno 2023-07-31 20:29:31 +08:00  1
我之前代码分析过 1000 多个服务，手动不现实，运维最多把资源大盘搞出来，把成本分析发给各个业务部门，降本增效得联合开发一起搞。还有 limit 是你设置的，OOM 影响业务了，你没背锅？
说说我的想法： 把降本的 KPI 丢给研发，确定百万用户/成本，每万请求多少钱之类的指标，核算出一个业务的上限预算。 和业务部门确定服务分级，预估资源。 分配不同的 namespace ，通过 namespace 设置资源限制，再弄个预警机制，超限了让研发确认原因，核心服务不要限死 limit ，服务挂了被大锅。 |
 |
2
pc10201 2023-07-31 20:34:43 +08:00
自己学写程序，调用 api 调整
|
 |
3
yyttrr OP @isno 有个保底的自动扩容程序在，一个 pod oom 了自动扩 pod 到 hpa max 的 2 倍，说是网络波动搪塞过去了
我们一个组 20 几个后端研发，对 k8s 有概念的不超过 3 个，让他们自己接手资源调整和 hpa 调整得培训几次，不知道领导会不会觉得我在甩锅~ |
|
4
yyttrr OP @pc10201 我举了几个例子，一个微服务业务上什么时候变得重要了，资源消耗多了少了我是无法知道的，也无法预测，滞后的调整为了稳定性得留下大量冗余，要么资源使用率上不去，要么稳定性受到影响
|
 |
5
RatioPattern 2023-08-01 12:00:43 +08:00
这么点研发上 limit ，折腾人，你们公司要裁员了吧
|
 |
6
julyclyde 2023-08-02 13:54:46 +08:00
主要看这活是不是你的职责了
如果是你的职责，那你就做好，并计入工作成绩，别推脱太累 如果不是你的职责，你给个大概参考意见就行了 |
 |
7
caicaiwoshishui 2023-08-25 16:21:53 +08:00
你这个明显要区分活动中的 deployment 和平时 deployment 的流量
搞活动需要提前扩容呀，扩容完就缩回去。 |
Select Language