Kubernetes 资源治理与成本优化：从 LimitRange 到 FinOps

Kubernetes 很容易让资源成本失控。应用团队提交一个过高的 requests，节点池就会提前扩容；批任务没有限制，可能挤压在线服务；namespace 没有配额，某个团队的实验服务会占满集群。资源治理的目标不是单纯省钱，而是在稳定性和成本之间建立透明、可执行的规则。

生产级资源治理需要同时管理四件事：资源声明、命名空间边界、节点池成本、团队归属。

requests 是成本语言

调度器根据 requests 判断 Pod 能否放到节点上。因此 requests 不只是技术字段，也是容量和成本语言。一个服务声明 4 核 CPU requests，即使实际只用 0.2 核，也会在调度层占用 4 核容量。

常见问题：

• requests 缺失，导致服务在资源竞争中没有保障。
• requests 过高，导致节点利用率低。
• limits 过低，导致 CPU throttling 或 OOM。
• 所有环境使用同一套资源配置，开发环境浪费严重。

建议基于历史 p95 或 p99 使用量设置 requests，再结合业务峰值和启动开销调整。新服务可以先用保守基线，运行一段时间后根据 VPA recommendation 修正。

LimitRange

LimitRange 可以为 namespace 设置默认 requests 和 limits，避免没有资源声明的 Pod 直接进入集群。

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
    - type: Container
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      default:
        cpu: 500m
        memory: 512Mi

默认值应按 namespace 类型调整。生产业务、开发环境、批处理环境不应使用同一套默认值。

ResourceQuota

ResourceQuota 控制 namespace 总资源上限。它可以限制 CPU、内存、PVC、Service、LoadBalancer、对象数量等。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "40"
    requests.memory: 80Gi
    limits.memory: 160Gi
    persistentvolumeclaims: "20"

配额不是为了卡团队，而是让资源申请显性化。超过配额时，团队需要说明业务需求，平台团队再扩容或调整节点池。

HPA 与资源配置

HPA 依赖指标计算扩缩容。如果 requests 设置不合理，CPU 利用率型 HPA 就会失真。例如 requests 过大，CPU 利用率长期很低，HPA 不扩容；requests 过小，HPA 过早扩容。

对核心服务，可以结合多指标扩缩容：

• CPU 利用率。
• 内存使用。
• QPS。
• 队列长度。
• p95 延迟。

业务指标比单纯 CPU 更贴近用户体验。例如消费队列服务按队列积压扩容，通常比按 CPU 扩容更有效。

批处理任务治理

批处理和在线服务混跑，是资源事故高发场景。批任务可能短时间拉高 CPU、内存、磁盘 IO 和网络。建议：

• 批任务使用独立 namespace 和节点池。
• 设置低 PriorityClass。
• 配置 ResourceQuota。
• 限制并发 Job 数。
• 使用 TTL 清理完成的 Job。
• 对大任务设置 activeDeadlineSeconds。

在线业务节点池应避免被低优先级任务占满。

节点池成本优化

节点池是成本治理的重要维度。可以按负载类型选择不同规格：

• 在线服务：稳定、通用规格，保留余量。
• 批处理：可使用更高利用率策略，必要时使用竞价实例。
• 内存型服务：选择高内存节点，避免普通节点碎片化。
• 系统组件：小规模独立节点池，避免被业务干扰。

节点规格太小会导致 DaemonSet 开销占比高、Pod 数限制更早到达；规格太大则故障影响面扩大。要根据工作负载密度和故障域权衡。

成本归属

没有归属，就没有治理。建议统一标签：

labels:
  app: checkout
  team: payments
  env: prod
  cost-center: cc-1001

成本系统可以按 namespace、team、app、env 归集 CPU、内存、存储、网络和负载均衡成本。即使一开始无法做到完全精准，也要让成本趋势可见。

团队看到自己的资源消耗后，优化动力会明显提升。

闲置资源清理

常见浪费来源：

• 已下线服务仍保留副本。
• 开发环境夜间持续运行。
• 未使用 PVC 长期占用云盘。
• 旧 LoadBalancer 未删除。
• 大量失败 Job 和历史日志堆积。
• 镜像缓存和 emptyDir 占满节点磁盘。

可以建立定期扫描报表，对无流量、无 owner、长时间未变更的资源进行提醒。

稳定性优先级

成本优化不能以牺牲稳定性为代价。对核心链路，要保留足够容量余量，避免节点故障或流量突增时没有缓冲。FinOps 不是把资源压到极限，而是让每一份资源投入有业务解释。

总结

K8s 资源治理是一套组织能力。requests、limits、LimitRange、ResourceQuota、HPA、节点池和标签只是工具。真正有效的治理要让资源申请有边界、成本有归属、优化有数据、稳定性有底线。最好的结果不是账单最低，而是团队知道钱花在哪里、风险在哪里、下一步该优化哪里。