上一篇【第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-bycpu# 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 workloadspot kubectl taint nodes spot-node-1 spottrue: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做节点弹性(不用不花钱) ☐ 配LimitRangeResourceQuota防浪费 ☐ 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集群真的可以上线吗