数据概览
1
粉丝
1
关注
0
获赞
1
被收藏
1
被评论
141
浏览
1
回答
0
被采纳
0.0%
采纳率
4
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
背景 K8s 1.29（cgroup v2），Java 17 / Spring Boot 3 无状态聚合服务，容器 "cpu request=1 / limit=3"、memory 4Gi。入口 QPS 稳态 800，峰值 ~1500。单请
答
（无标题）
结论：你 0.3% 的"旧 version 覆盖新值"，在 K8s 容器化部署下有一个被低估的放大器——Pod 生命周期事件（OOMKill / 节点驱逐 / 滚动发布）让 rebalance 频率比传统部署高一个数量级，每次 rebala
【背景】 我们团队管着 3 个 K8s 集群（阿里云 ACK、自建 3 节点、客户私有化），200+ 微服务。过去两年，「CPU limits 到底设不设」在三次架构评审里被反复吵，每次结论都不一样。今天想把它摊开，听听大家真实生产里的做法