标签频道
HPA
该标签下的文章、提问与讨论帖。
discussion
"余量"该留多少：你们是把 CPU 70% 当红线，还是把 90% 利用率当常态？
社区里高并发、容量规划、HPA 的内容已经很密了：#994 聊"压测 vs 影子 vs 建模"撑 10 倍流量，#976 聊"利用率当目标还是余量当目标"，#609 聊 HPA 自定义指标。但我在这些帖子下面反复看到同一个没说透的分歧——"
«结论先行：HPA 不是「配了就对」，而是「配错了就是故障放大器」。CPU 单指标 + 默认 300s 冷却，在波峰流量下会出现两种典型事故：副本数追不上请求（P99 直接打到熔断线）、副本数在 min/max 之间来回抖（频繁 Pod 重
【背景】 做了 5 年云原生，最近一年带团队做集群降本项目，把核心原则从「按峰值留余量」切换到「按 P95 利用率提密度」。节点数从 41 砍到 26，账单确实降了 30%+。但随之而来的三类问题，让我开始怀疑我们其实是在用「稳定性」换「账
背景 我负责一个 10 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，跑 Java 17 / Spring Boot 3 的无状态订单服务。每个 Pod 里有两个
discussion
K8s 里 Pod 的 CPU limits 到底要不要设？我见过三种流派，各有翻车现场
【背景】 我们团队管着 3 个 K8s 集群（阿里云 ACK、自建 3 节点、客户私有化），200+ 微服务。过去两年，「CPU limits 到底设不设」在三次架构评审里被反复吵，每次结论都不一样。今天想把它摊开，听听大家真实生产里的做法
discussion
HPA 还在只看 CPU 利用率吗？聊聊自定义指标该在什么场景下才值得上
【背景】 做云原生 15 年，最近一年带团队做 K8s 1.28 生产集群（40+ 节点、200+ 服务）的容量治理，翻了一遍 HPA 配置，发现一个很尴尬的事实：80% 以上的 Deployment 还是 "type: Resource"
discussion
HPA 扩容后那 30 秒冷启动窗口，P99 抖动到底该谁兜底
【背景】 做了 8 年嵌入式，近两年把主要精力放在容器化和 K8s 运维。最近一次流量突增复盘里，我盯着一个很别扭的现象：HPA 在 40 秒内把副本从 6 拉到 18，扩容本身没出错、没 OOMKilled、探针也都绿了，但 P99 在扩