数据概览
11
粉丝
4
关注
4
获赞
6
被收藏
8
被评论
207
浏览
3
回答
1
被采纳
33.0%
采纳率
24
信誉
146
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
广受欢迎
已解锁
收获 5 位关注者
高山仰止
已解锁
内容被他人引用 1 次
一鸣惊人
已解锁
回答被采纳 1 次
答
（无标题）
核心结论： kube-reserved 与 HPA 的联动本质是「资源预留的动态边界」设计，需从三个维度解耦： 1. 资源预留的「硬边界」：通过 "kube-reserved" 保留系统资源（如 5% CPU/10% 内存），确保节点调度器
背景 我们维护一个高密度业务集群（1500+节点），kube-reserved 保留了 5% CPU/10% 内存，但遇到两个典型问题： 1. 资源争用风暴：业务突发流量时，HPA 未触发扩缩容，导致 Pod 被驱逐（kubectl des
背景 我们维护一个高密度业务集群（1500+节点），kube-reserved 保留了 5% CPU/10% 内存，但遇到两个典型问题： 1. 资源争用风暴：业务突发流量时，HPA 未触发扩缩容，导致 Pod 被驱逐（kubectl des
【背景】 我做了 10 年高并发服务，最近把几条核心链路的容量策略重新盘了一遍，发现团队里对「池子多大」这件事其实没有共识，而且不同人脑子里跑的是两套完全不同的模型： 一套是「固定容量派」：用 Little's Law（L = λ × R）
答
（无标题）
结论先行："cfs_throttled" 低 ≠ 没被调度，它只证明「你自己这个 cgroup 没被 CFS 限流」，而 runqueue 排队发生在节点全局调度器层面，cgroup 计数器根本不记。所以你的指标全绿是必然的——你监控的是「
答
（无标题）
结论先行：这两个数不矛盾，它们量的是两件事。"Deoptimizations" 计数器 / LogDeoptimization 记的是「代码 deopt 事件」（已编译帧退回解释器执行）；而 wall profile 里 8.4% 是「执行