各位工作的公司生产 k8s 是怎么维护应用的 request 和 limit 的？

我印象中 request 还不能太小，忘了啥原因。

我们之前是所有 pod 固定的 request 和 limit （ request:2 limit:8 ），靠 pod 数量来伸缩，极个别特殊的 pod 手动调整。

@mooyo 当机器的 cpu 打满了，会按这台机器的 pod 的 request 比例去分 cpu

用不明白，就设置一样😁

初始化一般业务评估就行，业务对自己的业务量应该有点数。
然后监控使用率，使用率太低，推进调低，使用率高，推荐提高。

用 vpa 给你推荐下资源配置

@xavi818 这个可以，但是第一次上线的时候好像推荐不出来吧
@vkillwucy 我们就是差不多都一样的，但是其实资源使用率差的挺多的
@ZSeptember 业务根本不懂这些，也不管，所以都得靠我们运维推，太难了

很难搞，我们还因为 req 设置不合理出过线上故障

设置好 hpa 和 autoscaler

刚上线的时候会设置一个大概的 request 和 limit 。（自己决定哦。同时得配合 hpa ）
后续有一个 tuned request 和 limit 会附加上去。（这块应该是 infra 组来做的。来根据历史来帮你调整。能节省不少资源）
同时后续应用不停上线 cpu 也不会急剧上升。👆会自己帮你调整。当然你得设置好 hpa 来应对突发情况。

之前维护的比较多的是 Java 项目，Java 项目很多启动的时候会给你一个默认的资源需求参数，稍稍加大一点设置为 request 就好。Limit 的就得看你自己的经验和在测试环境里的压测评估结果来预估了。
之前公司的开发都是外包给三方团队的，代码很垃圾，最夸张的一个 Java 项目启动要四分半才能起来。一开始是让那些开发自己估（毕竟开发才是最清楚自己写的是一堆什么 shit ），结果估了几次给出的参数都是非常离谱的。

这个在每个公司都是难点，可以一开始设置大一些，后续看监控数据再慢慢缩

limit 一般是 Request 的两倍到四倍，太高超卖谁也用不高
Request 大概估个范围 + HPA

HPA 还可以基于自定义指标，比如 QPS ，这样后续维护只需要关注每个请求的资源变化就可以了

Limit 一般可不用设置。设置了会影响瞬时处理器资源分配。特别是对于有低延迟需求的服务来说，会极大拉长 p95 以上的延迟。这方面有很多文档在讲解，可以谷歌看看
Request 一般是跑压力测试综合性能指标评估下单 pod 负载。找到一个合理的，适合扩容缩容的资源。

刚说的是 cpu 的配置，如果有个别服务处理器资源占用比较厉害的，可能影响整个集群其它服务的，还是需要限制，具体问题具体分析。

至于内存配置看情况，limit 一定要设置，而且多数情况 Request = Limit ，这样能保证内存分配可用性。具体多少还是压力测试来