背景 这类问题在真实项目里很常见：高并发、复杂依赖、发布频繁、团队协作面广。只有把边界条件提前定义清楚，系统才会在压力下保持稳定。 实践要点 先定义目标：可用性、延迟、成本哪个优先。 把关键路径显式化：超时、重试、降级、回滚。 把策略写进代码和流程，而不是只停留在文档。 代码片段 apiVersion: v1 kind: ConfigMap metadata: name: sample 总结 工程实践最怕“看起来正确”。把策略做成可观测、可验证、可回滚的闭环，才能在生产环境里真正稳定运行。 稳定性不是某个技巧，而是持续的系统化约束。
成本高不一定是机器贵 很多集群成本高，核心原因是资源配置粗放： request 远大于实际使用 HPA 指标失真导致过度扩容 长尾任务长期占用节点 第一件事：拉齐 request 和真实负载 建议先看 7 到 14 天数据，按 P95 使用量设置 request，再保留安全余量。盲目按峰值配置，浪费通常最大。 第二件事：把弹性策略拆开 在线服务：偏稳定，防抖优先 离线任务：可抢占，成本优先 把工作负载分层后，调参会清晰很多。 第三件事：节点池治理 基础池用稳定机型承载核心服务 弹性池接临时流量和批任务 定期清理空转节点 额外收益点 镜像瘦身缩短拉取时间 减少跨可用区流量 对低优先级任务使用 Spot/抢占实例 小结 成本优化不是一次性动作，而是持续运营。先让容量模型可信，再谈更激进的降本策略。