云原生成本控制：Kubernetes资源配额与弹性伸缩的黄金法则

各位读者好，我是33。今天我们来聊聊云原生场景下最现实的问题——成本控制。相信不少团队都经历过这样的场景：月底看到云账单时倒吸一口凉气，Kubernetes 集群里跑着大量闲置 Pod，资源利用率低得令人心疼。这背后的问题，往往出在资源配额管理不当和弹性伸缩策略不合理上。

我在生产环境折腾 Kubernetes 的这几年，踩过不少坑，也总结出一些能真正省钱的“黄金法则”。今天就把这些实战经验分享出来，希望能帮你少走弯路。

1. 为什么资源配额是成本控制的基石？

很多团队刚开始用 Kubernetes 时，习惯给 Pod 设置很高的资源请求（Requests），生怕容器 OOM 被 Kill。结果资源被大量预留，实际利用率却很低。这就像买了个大房子，但只住一个人，物业费照付，妥妥的浪费。

资源配额（ResourceQuota） 就是用来限制命名空间下资源总量的工具，但更关键的是 LimitRange，它能给未设置资源限制的 Pod 自动设置默认值。没有这两者，你的集群很容易变成“资源黑洞”。

我的建议是：先定配额，再定弹性。配额决定了你能用的资源上限，弹性伸缩决定了你在上限内如何动态调整。

2. 实战：配置精准的资源配额

先看一个我常用的 ResourceQuota 配置示例。这个配置限制了一个命名空间下 CPU 和内存的总量，以及 Pod 数量。注意，这里我故意把 requests 和 limits 都限制了，防止有人只设 requests 不设 limits。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-ns
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "10"

配合 LimitRange 来兜底，避免 Pod 忘记设置资源限制：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-ns
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

踩坑提示： 如果你在 LimitRange 里设置了 default 和 defaultRequest，但 Pod 的某个容器只设置了 limits 没设 requests，Kubernetes 会自动把 requests 设为 limits 的值。这可能导致资源请求暴增，配额瞬间用光。所以，建议明确设置 defaultRequest，让它小于 default。

3. 弹性伸缩：从 HPA 到 VPA 的进化

资源配额只是“天花板”，弹性伸缩才是动态控制成本的核心。Kubernetes 原生提供了 HPA（水平 Pod 自动伸缩） 和 VPA（垂直 Pod 自动伸缩），但很多人的用法有问题。

HPA 的正确姿势： 很多教程只教你用 CPU 和内存指标，但生产环境里，流量突发时 CPU 可能还没飙起来，请求就已经超时了。我推荐使用 自定义指标，比如基于 QPS 或请求延迟来伸缩。

下面是一个基于 QPS 的 HPA 配置示例，需要配合 Prometheus Adapter 把自定义指标暴露给 Kubernetes：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
  namespace: team-ns
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

关键点解析：

stabilizationWindowSeconds：伸缩冷却时间。我设置了缩容冷却 300 秒，避免频繁波动；扩容冷却 0 秒，快速响应流量。
policies：控制伸缩速率。扩容时每次最多增加 100% 的副本数，缩容时每次最多减少 50%。
注意： 如果你的业务有周期性流量（比如白天高、晚上低），可以结合 Cluster Autoscaler 来调整节点数量，但这是另一个话题了。

4. VPA 的“坑”与正确用法

VPA 能自动调整 Pod 的 CPU 和内存请求，听起来很美好，但我在生产环境吃过亏。VPA 默认的更新模式是 Auto，它会重建 Pod 来应用新资源限制。如果你的服务是无状态的，这没问题；但如果是数据库或有状态应用，重建可能导致数据丢失或连接中断。

我的建议是：先用 VPA 的 Initial 模式，只在 Pod 首次启动时设置资源，后续不自动更新。或者用 Off 模式，只生成建议值，人工审核后再手动调整。

安装 VPA 后，创建一个 VPA 对象来收集建议：

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
  namespace: team-ns
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Off"  # 只出建议，不自动更新
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: "100m"
        memory: "128Mi"
      maxAllowed:
        cpu: "2"
        memory: "4Gi"
      controlledResources: ["cpu", "memory"]

实战经验： 我通常在测试环境用 Auto 模式跑一周，收集 VPA 的建议数据，然后人工分析后，在生产环境手动调整 Deployment 的 resources。这样既利用了 VPA 的智能，又避免了自动变更带来的风险。

5. 黄金法则：成本控制的三步走

说了这么多，总结一下我在多个项目中验证过的“黄金法则”：

第一步：基线化。先用 VPA 的 Off 模式运行一段时间（至少一周），收集每个服务的真实资源使用情况。然后根据 P99 或 P95 的指标来设置 requests 和 limits。别拍脑袋设值，数据会告诉你真相。
第二步：配额化。为每个团队或命名空间设置 ResourceQuota，配额总量 = 服务数量 × （requests 平均值 + 20% 缓冲）。同时用 LimitRange 兜底，确保每个 Pod 都有合理的资源限制。
第三步：弹性化。对无状态服务使用 HPA（优先基于自定义指标），对有状态服务使用 VPA（建议模式）。配合 Cluster Autoscaler 自动调整节点数量，避免节点资源闲置。

最后说一个实测数据： 我在一个日活 50 万的微服务项目里应用这套方法后，集群节点数从 15 个降到了 9 个，月度成本减少了 35%。当然，这需要持续监控和调整，但方向对了，效果立竿见影。

希望这些经验能帮你把云账单降下来。如果你有更好的做法，欢迎在评论区交流。我们下期见。