1. 课程导入

在传统数据中心里，资源利用率通常以“服务器是否跑满”来衡量；而在云原生环境中，这个指标被彻底重构。Kubernetes 等编排系统把 CPU、内存、存储、网络抽象成可声明、可调度、可弹性伸缩的资源对象，应用以容器为单位被反复创建、迁移和销毁。于是，资源利用率不再只是“用了多少”，而是“申请了多少、实际用了多少、被限制了多少、浪费了多少”这一组相互牵制的关系。本课程要解决的核心问题，就是让这套关系从“粗放占用”走向“精细匹配”。

一、核心目标：在可靠性与成本之间找到可量化的平衡点

云原生资源利用率优化不是单纯把 CPU 使用率拉高。它至少包含四个可观测目标：其一，降低资源浪费率，即节点上已分配但未被实际使用的 CPU/内存比例；其二，提升装箱密度，让单位节点承载更多有效工作负载；其三，控制性能风险，避免因过度压缩资源导致延迟上升、OOMKilled 或请求排队；其四，保持弹性能力，使突发流量到来时仍能快速扩容。四者之间存在天然张力：密度越高，风险越大；预留越多，浪费越多。因此优化的本质是在给定 SLO 约束下，寻找资源申请量、限制值与实际负载之间的最优匹配。

二、工程挑战：为什么“调小一点”往往并不奏效

实际工程中，资源优化面临几类典型阻力。第一，申请与使用脱节：开发者为避免上线故障，习惯把 requests 设得远高于真实需求，导致调度器按虚高申请量分配，节点看似满载、实则空转。第二，指标口径不统一：CPU 有 request、limit、usage、throttling 四个关键量，内存有 working set、RSS、cache 之分，若混用指标做决策，结论会完全相反。第三，负载具有时变性：白天高峰、夜间低谷，固定 request 无法同时满足两端。第四，多租户与优先级干扰：高优先级任务抢占、DaemonSet 常驻、系统组件预留，都会让“可优化空间”被压缩。第五，变更风险：一次错误的 limit 下调可能引发连锁重启，因此优化必须可灰度、可回滚、可观测。

三、整体方法论：从“拍脑袋”到“数据驱动”的五步闭环

资源优化不是一次性动作，而是一个持续闭环。第一步是观测：在集群中部署指标采集，至少覆盖容器 CPU 使用量、内存 working set、CPU throttling 次数、OOM 事件、节点分配率。第二步是画像：按服务维度统计 P50、P95、P99 使用量，区分“稳态基线”和“峰值需求”。例如某 Java 服务 P95 CPU 为 0.35 核、P99 为 0.6 核，而当前 request 为 1 核，则存在明显下调空间。第三步是调参：将 request 向 P95 靠拢，limit 保留在 P99 之上并留出安全余量，同时结合 HPA 处理突发。第四步是验证：通过灰度发布观察延迟、错误率、重启次数，确认 SLO 未退化。第五步是固化：把有效策略写入准入校验、CI 检查或自动调优控制器，避免人工回退。

四、学习路径：本课程将带你走完的完整链路

后续章节将沿着“认知—度量—优化—验证—工程化”的路径展开。你会先理解 Kubernetes 资源模型与调度机制，再掌握 CPU、内存、网络、存储等不同维度的度量方法；随后进入具体优化手段，包括 requests/limits 调优、HPA/VPA 弹性策略、节点装箱与碎片整理、混部与优先级控制；最后落到工程实践，如基于 Prometheus 的容量画像、灰度验证流程、成本分摊与持续巡检。每一部分都围绕真实对象、真实参数和可判断的结果展开，而不是停留在概念层面。

资源利用率优化的最终价值，不是让仪表盘上的数字更好看，而是让每一份被申请的资源都真正服务于业务，同时让系统在流量波动和故障场景下依然稳定。理解目标、约束与方法之间的关系，是后续所有具体技术手段能够正确落地的前提。