系统迁移到 Kubernetes 后，云账单比以前高了，是否说明选型失败？先别急着下结论。新环境可能增加了副本、监控、测试环境和容灾能力，也可能存在资源申请偏大、闲置资源未清理等问题。需要把新增能力与低效投入分别识别出来。
一、先统一比较口径
选择相近的统计周期，记录业务请求量、活跃客户、环境数量和可用性要求。原来只有一套单实例生产环境，改造后有多个副本及独立测试环境，直接比较总账单并不能说明资源利用率变差。
可以同时保留总成本与业务单位成本，例如每个活跃租户或每批任务的基础设施成本。指标选择要与业务相关，并说明未计入的项目，避免用流量增长掩盖闲置，也避免把必要的可靠性投入误判为浪费。
二、核对资源配置与真实使用
Kubernetes 使用资源请求参与调度，资源限制则约束容器可使用的资源。申请量、实际消耗和可用容量需要结合观察，不能只看某个时刻的 CPU 利用率。参见Kubernetes 资源管理文档。
对 .NET 应用，应覆盖启动、稳定运行、批处理和业务高峰等阶段观察内存与 CPU，再讨论配置。直接按平均值压低限制，可能引入节流或内存不足问题；没有证据地统一扩大申请量，也可能影响资源利用。
三、把账单拆成五类
| 类别 | 建议核查的内容 |
|---|---|
| 计算与预留容量 | 节点、应用副本、峰值余量、扩缩容后的空闲节点 |
| 数据库与存储 | 数据库实例、持久卷、备份、快照及保留周期 |
| 网络与入口 | 负载均衡、跨区域或跨可用区流量、外网流量 |
| 可观测性 | 日志采集量、指标规模、链路采样和数据保留 |
| 环境与维护 | 长期闲置的测试环境、平台升级、值班和故障处理投入 |
四、调整之前，确认资源为什么存在
一个低利用率副本可能承担故障切换能力，一份快照可能用于恢复验证。建议为待调整项目记录所有者、业务目的、当前配置、观测依据与变更风险。缺少所有者的资源需要核实，而不是直接删除。
可以先从有证据的低风险项目开始，例如已经结束且确认不再需要的临时环境，或超出约定保留周期的数据。生产容量、备份和故障余量的调整需要单独评审，并保留恢复办法。
五、用小范围验证替代一次性压缩
选择一个负载稳定的服务调整配置，在约定观察窗口比较响应时间、错误、重启和资源消耗。若涉及节点规模，还需要检查调度是否可行。把成本变化和业务质量指标一起记录，才能判断调整是否有效。
对于服务数量有限、团队运维资源紧张的系统，也可以重新比较当前平台与更简单的部署方式。比较应包含迁移成本和维护责任，而不是只比较月度服务器费用。
如果团队希望评估云原生投入是否合理，可以从部署与运行现状梳理开始，形成资源清单、成本来源和分阶段调整建议。是否继续扩大 Kubernetes 的使用范围，应由实际收益与维护能力共同决定。