上一篇【第84篇】K8s排障手册——20个高频故障的排查思路，看完少熬十个通宵
下一篇【第86篇】生产就绪检查清单——你的K8s集群真的可以上线吗
摘要
很多公司的K8s账单贵得离谱——节点CPU平均利用率不到20%、一堆Pod设了超大的requests实际用不到10%、全用最贵的按需实例跑无状态任务。
成本优化不是"砍功能"，而是"把资源花在刀刃上"。这篇文章讲清成本优化的核心杠杆：合理设Requests/Limits（避免过度分配）、用VPA纠偏、用Spot实例跑无状态、用Cluster Autoscaler/Karpenter做节点弹性、用配额防浪费，以及FinOps落地。
一、钱都花哪了
1.1 三大浪费来源
【K8s 成本浪费的"三座大山"】 1. 过度分配(Over-requesting) • requests设得比实际用的大10倍 • 节点被"虚假占满", 不得不加节点 → 这是最常见的浪费! 2. 闲置资源(Idle) • 夜间/周末流量低, 但Pod副本数不变 • 节点CPU才用10%, 但24小时计费 → 时间维度上的浪费 3. 节点选型错误 • 无状态任务用最贵的按需实例 • 没用Spot/抢占式(便宜60-90%) • 节点规格不匹配(大节点跑小Pod)要点：成本优化的第一杠杆是治"过度分配"。很多团队为了"保险"把requests设得巨大，结果节点被虚假占用，被迫扩容节点——而节点是按规格计费的，设1核和设4核占的"调度坑位"不同但直接决定要不要加机器。用实际监控数据（第075篇）来定requests才是正道。
二、Requests/Limits合理配置
2.1 基于数据，不是拍脑袋
【错误 vs 正确】 错误(拍脑袋): resources: requests: {cpu: 2, memory: 4Gi} # 反正设大点保险 # 实际用: 0.2核 800Mi → 浪费90%! 正确(看监控): • 看Prometheus里该Pod的 cpu使用率 P99 内存使用峰值 • requests = 峰值 × 1.15(留余量) • limits = requests × 1.5~2(防突发)# 用kubectl top看实际用量(数据源Metrics Server, 第025篇)kubectltoppods-nprod --sort-by=cpu# NAME CPU MEMORY# web-xxx 213m 842Mi ← 实际用量, 据此调requests三、VPA：垂直自动伸缩
3.1 自动纠偏
【VPA (Vertical Pod Autoscaler)】 作用: 根据历史用量自动调整Pod的requests/limits 模式: • Off: 只建议不执行(看报告用) • Auto: 自动改(会重建Pod!) • Recreate: 重建时改 • Initial: 创建时改一次 适合: 无法简单水平扩展的单体应用 不适合: 配合HPA(会冲突, 第025篇)apiVersion:autoscaling.k8s.io/v1kind:VerticalPodAutoscalermetadata:name:web-vpaspec:targetRef:apiVersion:apps/v1kind:Deploymentname:webupdatePolicy:updateMode:Auto# 自动调整resourcePolicy:containerPolicies:-containerName:appminAllowed:{cpu:100m,memory:128Mi}maxAllowed:{cpu:2,memory:4Gi}四、Spot/抢占式实例
4.1 便宜60-90%
【按需 vs Spot】 按需(On-demand): 随时可用, 贵 Spot(抢占式): 闲时余量, 便宜60-90%, 但可能被回收 适合Spot的负载: • 无状态应用(挂了能重建, 第013篇) • 批处理/CI(第024篇 Job) • 开发/测试环境 • 有HPA平滑承接(第025篇) 不适合Spot: • 有状态/不能中断(数据库) • 关键业务(除非有多副本+快速迁移)# 用nodeSelector/taint把无状态Pod调度到Spot节点池# Spot节点打label + taintkubectl label node spot-node-1 workload=spot kubectl taint nodes spot-node-1 spot=true:NoSchedule# Pod容忍并偏好Spottolerations:-key:spotoperator:Existseffect:NoSchedule五、节点弹性伸缩
5.1 Cluster Autoscaler vs Karpenter
【节点级弹性】 Cluster Autoscaler (经典): • Pod因资源不足Pending → 加节点 • 节点利用率低 → 缩节点 • 基于节点组(ASG/MIG)扩缩 • 成熟稳定 Karpenter (新秀, AWS首发): • 更智能: 看Pod需求直接选"最合适的实例类型" • 不依赖预定义节点组 • 启动更快、bin-packing更优(省节点) • 省钱效果更明显# Cluster Autoscaler 触发逻辑# Pod Pending(因资源) → CA看能否加节点容纳 → 调云API加节点# 节点<某利用率持续N分钟 → 驱逐Pod → 删节点# Karpenter: 定义Provisioner, 它自动选实例# 省去了"预定义节点组"这一步, 更灵活省钱六、配额与治理
6.1 用LimitRange/ResourceQuota防浪费
【命名空间级成本护栏(第031/032篇)】 LimitRange: 给ns里Pod设默认requests/limits → 防止有人不设requests(占满节点) ResourceQuota: 限制ns总资源 → 防止某团队无节制申请拖垮预算 → 多团队共享集群时必备(成本分摊基础)七、FinOps落地
【FinOps —— "财务+工程"的协作】 原则: 谁用谁买单(Showback/Chargeback) 实践: 1. 按namespace/团队打成本标签 2. 用kubecost等工具算每个团队花多少 3. 定期出成本报告, 暴露浪费 4. 设预算上限, 超了告警 5. 把节省纳入团队KPI 效果: 成本可见 → 团队有动力优化 → 账单下降八、优化清单
【K8s 成本优化 Checklist】 ☐ 基于监控(Prometheus)设置requests, 不拍脑袋 ☐ 用VPA纠偏长期偏差大的Pod ☐ 无状态/批处理用Spot实例(省60-90%) ☐ 用CA/Karpenter做节点弹性(不用不花钱) ☐ 配LimitRange+ResourceQuota防浪费 ☐ HPA按流量缩容(夜间降副本, 第025篇) ☐ 定期清理僵尸资源(没人用的Deployment/PVC) ☐ 用kubecost做成本可视化+分摊 ☐ 选对节点规格(大节点跑多Pod更省)本篇小结
K8s成本优化的核心杠杆：治"过度分配"（按Prometheus实际用量设requests，不拍脑袋）、用VPA自动纠偏、无状态/批处理用Spot实例（省60-90%）、用Cluster Autoscaler/Karpenter做节点弹性（不用不花钱）、用LimitRange/ResourceQuota防浪费、HPA按流量缩容（夜间降副本）。
关键是FinOps——成本可见、按团队分摊、定期审计、把节省当KPI。大多数集群有30-50%的浪费空间，照着清单做一遍，老板真可能给你加鸡腿。下篇是运维模块收官——生产就绪检查清单。
上一篇【第84篇】K8s排障手册——20个高频故障的排查思路，看完少熬十个通宵
下一篇【第86篇】生产就绪检查清单——你的K8s集群真的可以上线吗
