1 云原生弹性与成本要回答什么
订单 API 在夜间可能很安静，在促销开始后却突然繁忙。始终保留高峰所需的计算资源，会让大量资源在低谷等待；等用户已经遇到超时再临时加机器，又可能来不及。云原生弹性要回答的，是如何让可用容量跟随需求变化，并把等待时间、故障风险和费用放在同一张决策表上。弹性意味着资源可以调整，不意味着资源立即到位，也不意味着用了自动扩缩就会便宜。
先把服务画完整。用户通过入口和服务网络访问订单 API，API 以多个副本运行，每个副本通常放在 Pod 中。Pod 是 Kubernetes 调度应用的基本单位，可以把它理解为共同运行的一组容器。Pod 依赖工作节点提供 CPU 和内存，还要连接数据库、缓存等数据服务。入口、网络、存储和日志也可能计费，所以“副本减少了”只是成本变化的线索，不能直接证明总账单下降。
部署时，应用应通过工作负载身份获得访问数据服务的必要权限，避免把长期密钥打进镜像。新增副本必须沿用正确身份、网络访问规则和配置，否则自动扩出来的只是不能工作的进程。就绪检查应确认副本能够接收请求，入口才把流量交给它。扩缩策略虽然看起来是资源配置，实际结果取决于部署、身份、网络和数据依赖是否共同准备好。
本课用订单 API 说明关系，但不假定每种服务都适合按同样指标扩缩。处理图片的服务可能先遇到 CPU 瓶颈，保存会话的服务可能受内存约束，访问数据库较多的 API 也可能先耗尽连接。先确定用户可感知的目标，例如成功请求比例和尾延迟，再决定需要多少容量。尾延迟描述较慢那部分请求的耗时，常用 p95 或 p99 表示；平均延迟正常时，少量用户仍可能等得很久。
衡量成本也要给出范围和时间。比较同样持续时间、相近请求类型下的总费用，才容易解释差异。成功处理 100 万次请求用了多少计算费用，可以作为效率指标，但不能替代总费用：业务增长可能让单位费用下降而总费用上升。反过来，拒绝大量请求也可能让账单变小，却没有完成服务目标。弹性策略的目标应是以可接受的费用持续提供约定服务。
2 HPA、VPA 与集群自动扩缩
HPA 是水平 Pod 自动扩缩，主要调整副本数。例如已有 2 个订单 API 副本，持续忙碌后增加到 5 个，让更多副本共同处理请求。它根据周期性取得的指标做判断，常见指标有 CPU 利用率，也可以使用合适的业务指标。按 CPU 利用率扩缩时，目标通常相对于容器的 CPU requests 计算。因此，同样实际 CPU 用量，在不同请求配置下可能得到不同利用率，进而产生不同扩缩决定。
VPA 是垂直 Pod 自动调整，关注单个 Pod 应该申请多少 CPU、内存。它可以提供资源建议，也可以按配置应用调整。应用建议是否需要重新创建或重启 Pod，取决于集群能力和更新方式，不能预设完全无感。入门阶段可以先使用建议模式，观察建议与实际峰值的关系，再在可接受的维护安排中调整。VPA 的价值是帮助校准单副本大小，并不直接等于减少节点费用。
集群自动扩缩关注工作节点。当新 Pod 因为现有节点资源不足而无法调度时，它可能增加节点，让这些 Pod 有地方运行；低负载时，也可能在满足条件后移走工作负载并释放节点。它不保证解决所有等待调度问题。配额不足、节点池达到上限、网络地址不足，或 Pod 的调度条件没有任何节点能够满足，都可能使扩容无法完成。必须读取具体事件，不能把“等待中”都解释为节点暂时没买到。
这 3 类机制处理的是不同尺度的问题：HPA 管副本数量，VPA 管单副本资源，集群自动扩缩管承载副本的节点。常见过程是先增加期望副本，调度发现没有空间，再准备节点，随后启动应用。每段都有延迟。镜像下载、程序预热、数据连接建立和就绪检查都发生在用户真正获得新增容量之前，所以监控必须区分期望副本数与就绪副本数。
同时启用机制还要检查是否相互影响。例如 VPA 改变 CPU requests 后，HPA 看到的 CPU 利用率基准也变了。入门方案宜先明确每个控制器负责的指标与范围，避免多个机制围绕同一信号反复调整。缩容通常也需要稳定观察，防止短暂下降触发回收、随后又重新扩容。稳定窗口、最小副本和最大副本共同限定行为，但这些设置不能消除外部依赖的容量上限。
3 请求、限制与浪费边界
requests 是调度时使用的资源请求，limits 是运行时的资源限制，实际用量则是应用真正消耗的资源。可以把 requests 理解为安排座位时申报的空间，把 limits 理解为运行中允许触及的边界；这个比喻只帮助理解职责，不代表所有资源都具有相同的强制方式。对普通容器资源请求来说，调度器需要根据节点剩余可分配资源判断能否放置，不能只看节点此刻看起来空闲。
假设每个订单 API 副本请求 500m CPU 和 1 GiB 内存。500m 表示 0.5 个 CPU 的计算份额。8 个副本的请求合计为 4 个 CPU 和 8 GiB 内存。若节点扣除系统及其他工作负载后只剩 3 个 CPU，即使监控显示当前应用只用了 1 个 CPU，也不能据此认定这 8 个副本都能调度进去。请求表达的是容量安排依据，当前用量只是某个时刻的状态。
CPU 和内存限制也不能混为一谈。CPU 使用达到限制时，应用可能被限制执行速度，表现为响应变慢；内存超过限制时，容器可能被终止，随后按工作负载策略重新启动。提高内存限制可能让某次峰值不再终止，也可能只是延后泄漏暴露的时间。降低 CPU 限制后出现的延迟，并不一定能靠增加副本有效解决，仍要判断应用是否受限以及请求是否能够分散处理。
浪费边界由请求配置、实际峰值和服务余量共同决定。请求远高于长期需要，会让节点留下难以利用的空间；请求过低，又可能让多个忙碌副本集中在同一节点上，竞争资源。合理做法是同时观察稳定负载、突发负载和启动阶段，按副本查看分布，并给出余量的理由。不能仅凭 1 次低谷截图就把所有请求减半，也不应把“多留一些总没错”当作永久配置依据。
资源请求通常也不是独立账单项目。在按节点计费的集群里，请求降低后，如果节点数量和计费时长没有变化，计算费用可能完全不变；采用按工作负载资源计费的运行方式时，请求配置则可能直接影响费用。应先确认购买和计费单位，再讨论节省。节点碎片、系统开销、必须常驻的组件，以及故障时保留的容量，都可能造成“用量低于购买量”，其中有些是浪费，有些是有意承担的保障成本。
4 动手：对照一次扩缩与账单
选择隔离的测试环境，准备能够安全创建测试订单的接口，并为测试数据设置明确清理方式。先确认入口可达、工作负载身份可访问测试数据库、监控能够采集资源与服务指标。使用相同应用版本、相同请求类型和相同测试数据规模完成对照，避免把缓存差异或代码变化误判成弹性收益。测试负载应有停止条件，例如错误率持续超过约定范围就中止，防止无意义地堆积请求。
可以先设置 2 个最小副本、8 个最大副本，并把 CPU 利用率目标设为 60%，作为教学起点。这些数字不是生产推荐值；还要确认 requests 已配置、指标可读取，并且最大副本对应的数据库连接数可以承受。若每个副本最多建立 20 个连接，8 个副本就可能使用 160 个连接，还需要考虑部署时临时增加的副本、其他服务和运维连接。不能把数据库全部连接额度都分给日常 API。
把负载按时间分段，例如先以 50 次/秒运行 10 分钟，再升到 200 次/秒保持 15 分钟，最后回到 50 次/秒并继续观察 20 分钟。若节点准备或缩容需要更久，就延长观察直到相关事件结束。记录负载工具实际发出的请求和成功数，不能只记计划值。测试工具自身达到瓶颈时，目标请求率可能根本没有到达服务，此时无法用结果证明服务容量足够。
在统一时间轴记录请求率、p95 延迟、错误率、CPU、内存、期望副本、就绪副本以及节点数。重点标出负载上升、HPA 改变期望值、新 Pod 等待调度、新节点就绪和 Pod 开始接流量的时间。还要看 CPU 受限、容器重启、数据库延迟与连接数。这样才能判断新增容量卡在哪段，以及扩容后服务是否真的恢复，而不是只看到副本曲线上升便宣布成功。
随后用同一观察窗口整理计算资源使用时长、数据服务费用、网络流量和可观测性费用。某些账单按小时、天或更长周期汇总，明细也可能延迟出现；无法即时拿到时，先保留事件和资源记录，明确写成估算。对照实验应采用相同计价口径，注明折扣、最低计费粒度和测试之外的固定费用。短实验可以证明动作链路，不能自动代表整月节省比例。
最后比较固定副本方案与自动扩缩方案。报告既要写总费用，也要写成功请求数和是否满足服务目标，并解释预热是否一致。若自动扩缩在高峰前 60 秒产生大量错误，即使费用更低，也只能说明它用了更少资源，不能说明方案更优。保留配置、时间线和结论，使其他人能够复现相同条件并讨论取舍，后续再据此调整范围。
5 弹性速度与成本取舍
弹性速度可以拆成发现变化、作出决定、获得资源、应用就绪这几段。降低指标采集间隔只能影响其中部分时间，不能让节点或应用瞬间完成准备。若突发只持续 30 秒，而新增容量需要 90 秒才能接流量，单纯依赖事后扩容很可能赶不上。可预测的活动可以提前扩容；不可预测的突发则需要常驻余量、适当排队或限流，并明确超出容量时如何保护系统。
最小副本数体现空闲费用与响应准备之间的取舍。常驻副本较多，可以直接接住更多突发，也为副本故障留出余地；常驻副本较少，低谷成本可能更低，却更依赖扩容速度。副本所在的位置也很重要：4 个副本都在同一故障范围内，并不等于获得了理想的可用性。副本分布要求可能增加所需节点和闲置空间，应在成本解释中写清用途。
交互把每个副本的安全容量暂定为 50 次/秒，突发设为 400 次/秒，用固定的等待时间展示容量缺口。滑块升高时，缺口缩小而简化费用增加。这里的“安全容量”必须来自满足延迟和错误率要求的测试，不能用压测最高吞吐替代。图中未覆盖的请求可能排队、等待或被拒绝，其实际结果取决于超时和入口策略；不能把阴影面积直接当作真实错误数。
真实成本还受节点放置和计费粒度影响。减少 1 个副本，可能没有释放任何节点；释放节点后，也可能由于最低计费时长，短时间内看不到相同比例的费用下降。相反，保留部分空闲节点能缩短下次扩容的等待，但会持续付费。因此，最小副本和节点预留需要共同评估，按所购买的资源计算，而不是只把副本数乘上想象中的单价。
缩得太快也可能增加费用和故障风险。负载稍降就回收、稍升又扩容，会反复下载镜像、启动应用、重建连接，并造成容量抖动。稳定观察的意义是减少这种来回变化，代价是在低谷开始后多付一段费用。对可预测日周期、随机突发和长时间高峰，应分别选择策略。没有脱离服务目标的最低成本配置，只有在明确假设下可以接受的取舍。
6 常见坑：无限扩掩盖程序泄漏
程序泄漏的典型线索，是请求率已经稳定，单个副本的内存却随运行时间持续上升，且未在合理范围内稳定下来。也可能是缓存没有边界、队列积压或某种正常的延迟释放，因此不能看见上涨就断言泄漏。需要结合运行时长、成功请求数、队列长度和回收后的变化判断。尤其应保留单副本曲线，因为不同启动时间的副本混在平均值里，很容易隐藏趋势。
若配置了按内存指标扩缩的 HPA，新增副本的初始内存较低，可能暂时拉低平均值，让看板变得好看。原副本仍可能继续上涨并触及限制，重启后又从低位开始。最终表现为节点和费用持续增加、重启反复发生，而成功请求数没有相应增长。按 CPU 扩缩的 HPA 则未必对内存上涨作出反应，不能以“没有扩容”排除泄漏，也不能假定自动扩缩会替你发现所有异常。
遇到这类现象，先判断增长是否与真实业务需求对应，再检查每个成功请求的资源消耗。把发布版本、请求类型变化、重试量、单副本内存和重启时间对齐，确认问题从何时开始。若数据库变慢引发请求堆积，API 内存上涨可能只是下游瓶颈的结果；继续增加 API 副本还会建立更多连接，让数据库更忙。此时应检查连接池、请求超时、重试和入口保护，而不是不断抬高上限。
最大副本、节点上限和预算告警是边界，不是修复。预算告警通常不会自动停掉资源，容量上限也可能让服务在高峰时不足，必须配合错误率和延迟告警。止损时可按既定流程限流、回退有问题的版本，并保留诊断所需证据。修复后要用足够长的固定负载观察内存是否趋稳，再恢复和校准扩缩策略。单次重启后内存下降，不能作为泄漏已经解决的证据。
7 案例：闲置副本撑高月账单
某订单 API 为活动准备了 12 个最小副本，活动结束后只降低了最大副本，最小副本仍保持原值。夜间请求较少，单副本 CPU 长期很低，团队便认为集群自动扩缩会自行省钱。但 Pod 仍然存在，requests 仍占用调度空间，节点没有足够条件退出。这个问题没有明显报错：服务正常，扩缩控制器也按配置工作，异常出现在“活动配置没有退出机制”与“费用目标没有被复核”的交界处。
调查时先排除必须保留的故障余量，再检查是否有其他工作负载阻碍节点释放。假设每个工作节点扣除系统开销后有 4 个 CPU、8 GiB 内存可供这项服务使用，每个副本请求 1 个 CPU、2 GiB 内存。忽略额外调度约束时，12 个副本至少需要 3 个这样的节点。即使实际 CPU 合计只有 1 个 CPU，集群也不能凭这个瞬时用量把全部请求塞进 1 个节点。
团队通过负载测试和故障目标评审，将低谷最小副本分阶段降到 4，并保留高峰扩容能力。先观察低谷，再验证突发和发布过程，确认 p95 延迟、错误率及下游连接正常。4 个副本在上述简化资源条件下可以放入 1 个节点，但实际方案还要求副本跨故障范围分布，因此不能直接把 1 个节点作为生产目标。最终释放多少节点，要结合共享工作负载和部署约束确认。
为了理解时间的影响，再看独立的理想计算：若确实能在每天 16 小时低谷释放 2 个节点，每节点价格按 0.8 元/小时计算，30 天的计算费用差额为 2 × 16 × 30 × 0.8 = 768 元。这只是特定节点费用的估算，不包含高峰时长变化、最低计费单位、折扣或其他服务费用。若节点始终没有退出，768 元就只是纸面潜力，不能写成已实现收益。
改进后的报告应同时给出配置变化、实际释放的节点时长、服务目标结果和费用明细。还应记录活动结束的责任人和恢复低谷配置的时间，防止下次再次遗留。这个案例说明，成本问题未必来自复杂算法；正确设置最小副本、知道谁负责收尾，并验证释放动作到达了计费资源层，往往比继续增加自动化参数更有价值。
8 把弹性策略写进成本方案
成本方案首先描述服务边界：订单 API 承担哪些请求，使用哪些计算、数据、网络和观测资源，由谁维护。随后给出工作日低谷、日常高峰和活动突发的负载假设，以及可接受的延迟和错误率。没有这些前提，“将资源降低 30%”无法评审，因为读者不知道削减后是否还能完成业务。假设应注明证据来源和有效期限，业务变化后重新测试，而不是永久沿用旧容量结论。
接着写清副本与节点的控制范围。HPA 使用什么指标、最小与最大副本是多少，VPA 只给建议还是会应用变更，节点池最多提供多少资源；每个值都应对应容量、可用性或预算理由。还要注明应用启动时间、节点准备时间和下游容量边界。若高峰需要提前扩容，写明触发条件、操作责任和完成时点，避免把“支持弹性”误写成“高峰自然会被接住”。
费用部分按购买单位展开，至少区分常驻计算、随负载增长的计算，以及数据、网络、日志等其他费用。给出低谷、常态和高峰的估算范围，并标注哪些来自真实账单，哪些来自试验或假设。将成功请求数与总费用放在一起，让读者能区分业务增长和资源效率变化。折扣可以改变价格，但不能证明容量配置合理，应保留用量层面的解释。
最后写验收和运行闭环：用什么负载验证扩容及时性，怎样确认缩容后节点停止计费，出现哪些延迟、错误、重启或费用异常时需要处理，由谁处理。配置变更应可回退，验收应覆盖高峰及回落，而不是只截取扩容成功的瞬间。对尚未验证的前提直接标为待验证，并安排时间与负责人，这比给出看似精确却没有依据的整月节省承诺更便于执行。
9 从云原生弹性与成本走向SRE 实践（C51）
本课已经把容量、服务表现和费用连接起来，但真实服务还需要长期运行中的判断规则。SRE 实践将进一步讨论如何定义服务等级指标与目标，如何根据用户受到的影响设置告警，以及发生故障时怎样响应和复盘。弹性是帮助服务实现目标的手段，不能替代目标本身。即使副本数和 CPU 曲线都很平稳，用户也可能因为入口错误或数据库超时而无法完成订单。
进入下一课之前，可以整理 1 份小型证据包：服务依赖图、当前资源请求与限制、扩缩范围、负载测试时间线和同口径费用对照。它让可靠性讨论有事实依据。例如某次突发的前 90 秒延迟超标，就可以进一步讨论是否提前扩容、保留余量或调整入口保护；某段低谷节点没有退出，则可以检查保留容量是否有明确用途。先解释现象，再选择动作。
例如，缩容释放节点时，需要先把该节点上的 Pod 安全迁走。若订单 API 只有 2 个就绪副本，并要求至少保留 2 个可用副本，驱逐约束可能阻止节点回收；此时低谷账单不降有明确的可用性原因。若为了省钱直接放宽约束，又可能在迁移期间只剩 1 个副本承接全部请求。应测试迁移时的剩余吞吐、连接排空和请求完成情况，并记录节点为何未退出。Pod 中断预算可以约束部分主动驱逐，但不能阻止节点突然故障，因此仍需验证故障时的容量余量。
还要保留资源边界与用户边界的区别。最大副本保护预算，却可能限制成功吞吐；内存限制保护节点，却可能导致容器重启；多保留节点增加支出，却可能缩短恢复时间。这些都不是孤立参数的好坏，而是需要团队共同承担的运行选择。带着这些具体取舍进入 C51，才能把自动扩缩从“配置成功”推进到“持续满足服务承诺”。
放进方案里
在订单 API 的成本方案中，先写清服务范围与计费边界：入口负责接收请求，API 副本负责业务处理，数据库保存订单，工作负载身份限定数据访问权限，监控记录服务表现。费用分别列出工作节点、数据服务、网络与日志。以最近 30 天的负载记录区分低谷和高峰，注明请求类型及活动假设，避免用当前安静时段代表整月需求。
弹性策略应列明 HPA 指标、最小和最大副本，给出资源请求、限制及其测试依据。VPA 初期提供建议，由负责人审核后调整；集群自动扩缩负责补充和释放节点，并设置明确上限。记录应用就绪与节点准备的实测时间，说明突发期间依靠多少常驻余量。最大副本对应的连接数必须落在数据库预算内，还要留出发布和其他工作负载所需空间。
验收使用相同版本和相近请求类型，对照固定容量与弹性容量的负载上升、持续和回落过程。报告请求率、成功数、p95 延迟、错误率、期望及就绪副本，并标出节点变化。费用按相同时间窗口和计价口径比较，账单尚未到齐时标为估算。只有节点实际释放且明细支持时，才把潜在节省改写为已实现节省。
运行安排中写明告警接收人与处置责任：副本持续到顶、单副本内存持续上涨、重启增多或费用偏离预测时，先关联负载与发布事件，再决定限流、回退或扩容。预算告警不作为自动止损的保证。活动结束后由指定负责人恢复低谷策略，按月复核服务目标和费用；所有调整保留配置、证据和回退方式，让节省具有可追溯的依据。
10 小结：下一步SRE 实践（C51）
HPA 调副本，VPA 调单副本资源，集群自动扩缩调节点。requests 影响容量安排，limits 形成运行边界，实际用量帮助判断需求；它们都需要与购买单位和计费规则对照。扩容成功应以新增副本开始健康接流量为依据，缩容省钱应以计费资源实际减少为依据。
可以用 3 个问题检查理解：期望副本增加而就绪副本不变，应从哪些环节找证据？请求率稳定而副本内存持续上涨，为什么不能只提高上限？副本减少但账单没降，应该核对哪些资源与时间范围？带着负载、服务表现和费用的共同证据进入 C51，再把这些判断组织成可持续执行的 SRE 实践。