如何优化集群成本并高效回收闲置资源？

在Kubernetes生产集群中，成本优化与资源利用率管理通常是平台团队最头疼的问题之一。很多集群为了保证业务高峰期稳定运行，预留了大量CPU和内存，但实际平均利用率不足30%，造成云资源严重浪费。本文围绕资源识别、弹性伸缩、混合实例和自动化回收四个层面，提供一套可落地的集群成本优化与闲置资源回收方案。

一、集群成本浪费的典型来源与量化识别

集群成本浪费很少来自单一原因，更多是多个配置习惯叠加的结果。最常见的是requests和limits设置不合理。很多团队在创建Deployment时，为了保险起见把requests写得很大，例如一个实际只消耗0.2核CPU的服务却请求了2核。Kubernetes调度器会按照requests为Pod预留资源，导致节点上出现大量已分配但实际未使用的空闲容量。与此同时，limits设置过高还会让个别Pod在突发流量时占用大量资源，影响其他租户。

另一个主要来源是节点规格与业务负载不匹配。例如业务Pod平均只需要2核4G，但节点选择的是8核32G实例，且没有开启自动缩容。当Pod调度分散时，每个节点都可能只跑少量Pod，整体利用率被拉低。此外，一些长期不用的测试环境、已下线的服务没有及时清理，也会留下不少僵尸工作负载。

要回收闲置资源，首先需要量化识别浪费点。通过metrics-server可以快速查看节点和Pod的实际使用情况。

kubectl top nodes
kubectl top pods -A --sort-by=cpu

如果节点CPU或内存的requests总和接近可分配容量，但实际使用率长期低于30%，说明存在过度预留。此时可以进一步用Prometheus记录container_cpu_usage_seconds_total和kube_pod_resource_request等指标，计算每个命名空间下请求值和实际使用值的差值。差值越大，代表可回收的资源越多。

例如某节点可分配8核32G，已请求6核24G，但实际只使用1.5核6G，那么该节点就有4.5核18G的调度资源被浪费。通过调整requests或重新调度Pod，完全可以把这些资源释放给其他业务，甚至直接缩容节点。

二、通过弹性伸缩与调度策略回收闲置资源

弹性伸缩是控制成本的第一道防线。Kubernetes提供两个层面的自动伸缩能力：Pod层面的HorizontalPodAutoscaler（HPA）和节点层面的cluster-autoscaler。HPA根据CPU、内存或自定义指标动态调整副本数，避免业务低峰期仍然维持大量Pod。配合cluster-autoscaler，当Pod数量减少后，多余的节点会被自动回收。

下面是一个典型的HPA配置，目标是将CPU平均利用率维持在60%左右。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-server
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

这里设置averageUtilization: 60意味着HPA会尝试让所有Pod的平均CPU使用率保持在60%。如果当前使用率只有10%，HPA会将副本数从10缩减到2，从而释放大量节点资源。需要注意的是，HPA计算基于requests，因此requests设置越贴近真实使用值，伸缩效果越好。如果requests虚高，HPA可能认为使用率很低而过度缩容。

节点层面的cluster-autoscaler则根据是否有Pending的Pod来决定扩容或缩容。当某个节点上的所有Pod都可以被调度到其他节点且节点空闲时间超过设定阈值时，cluster-autoscaler会将该节点从集群中移除。建议在部署cluster-autoscaler时配置合适的缩容冷却时间，例如10分钟，避免业务波动导致频繁创建和删除节点。

除了自动伸缩，调度策略也能帮助资源整合。使用podAntiAffinity可以避免同一个服务的副本集中在同一节点，但过度使用反亲和会导致节点无法充分利用。更合理的做法是让无状态服务尽量分散，保证高可用的同时，通过HPA控制副本数。对于批处理任务，可以使用nodeSelector和topologySpreadConstraints将任务集中到部分节点，完成后让其他节点进入空闲状态，再由cluster-autoscaler回收。

三、Spot实例与descheduler在成本回收中的实践

云厂商提供的Spot实例或抢占式实例是降低计算成本的有效手段，价格通常只有按需实例的1到5折。对于无状态Web服务、测试任务、数据处理等允许中断的工作负载，非常适合运行在Spot实例上。但Spot实例随时可能被云厂商回收，因此需要通过污点和容忍度将其与固定实例区分开。

先给Spot节点打上标签和污点，确保只有声明了相应容忍度的Pod才会被调度上去。

kubectl label node spot-node-1 node-type=spot
kubectl taint node spot-node-1 spot=true:NoSchedule

然后在Pod中配置容忍和节点亲和，让任务主动选择Spot节点。

apiVersion: v1
kind: Pod
metadata:
  name: batch-job
spec:
  tolerations:
  - key: "spot"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: "node-type"
            operator: In
            values:
            - "spot"
  containers:
  - name: batch-job
    image: busybox
    command: ["sh", "-c", "sleep 3600"]

这样固定节点上的资源留给核心业务，Spot节点承担可中断任务，整体成本显著下降。不过Spot回收会造成Pod突然终止，因此务必在Deployment中设置terminationGracePeriodSeconds并处理SIGTERM信号，尽量优雅退出。

另一个重要的回收工具是descheduler。它不像HPA那样调整副本数，而是根据策略驱逐已经运行的Pod，触发重新调度，从而改善集群资源分布。例如低利用率节点上的Pod会被驱逐并调度到其他节点，空出来的节点就可以被回收。

apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "RemoveDuplicates":
    enabled: true
  "LowNodeUtilization":
    enabled: true
    params:
      nodeResourceUtilizationThresholds:
        thresholds:
          "cpu": 20
          "memory": 20
        targetThresholds:
          "cpu": 50
          "memory": 50

上述策略表示当节点CPU和内存利用率低于20%时，descheduler会尝试驱逐该节点上的Pod，并希望目标节点的利用率达到50%。通过定期运行descheduler，可以有效避免节点负载不均衡造成的资源闲置，配合cluster-autoscaler实现自动缩容。

四、成本治理的落地步骤与监控指标

成本优化不是一次性项目，而是一个持续治理的过程。建议分四个阶段落地：第一阶段建立监控和资源台账，统计命名空间维度的资源请求、实际使用和成本占比；第二阶段调整requests和limits，开启HPA和cluster-autoscaler，消除明显的过度预留；第三阶段引入Spot实例和descheduler，进一步回收低利用率节点；第四阶段建立成本分摊机制，将集群费用按命名空间或标签归属到业务团队。

监控指标方面，至少需要跟踪以下四类：节点CPU和内存利用率、Pod的requests与实际使用值之差、节点空闲时间、Spot实例回收次数。利用Prometheus可以方便地聚合这些指标。

sum(rate(container_cpu_usage_seconds_total{namespace!="kube-system"}[5m])) by (namespace)
sum(kube_pod_resource_request{resource="cpu"}) by (namespace)

第一个PromQL统计每个命名空间的实际CPU使用速率，第二个统计请求值。两者对比可以快速识别哪些命名空间预留过多。还可以借助OpenCost或KubeCost等开源工具，自动计算每个命名空间、Deployment甚至Pod的成本，并将数据导出用于内部结算。

落地时务必关注业务稳定性。例如在调整requests时，可以先从非核心服务开始，设置较小的安全系数；在引入Spot实例时，优先选择无状态且允许中断的服务。通过灰度方式逐步扩大优化范围，同时保留足够的固定资源应对突发流量。长期来看，只有把资源使用率和成本数据透明化，才能推动团队主动治理闲置资源，形成成本优化的良性循环。

集群成本优化闲置资源回收Kubernetes资源调度修改时间：2026-08-28 17:07:50