Kubernetes大量非活跃Pod场景下CPU高效利用及资源请求配置问询

你的思路完全没问题——Kubernetes的自动扩缩容（HPA+节点自动扩缩容）确实是为了灵活分配资源、降低成本而生的，问题出在资源请求（request）的配置逻辑和扩缩容策略的搭配上，而不是不该设置request。下面我会一步步拆解可行的优化方案：

1. 重新定义CPU请求与限制，区分调度资源与运行上限 #

Kubernetes的requests是给调度器看的（决定Pod能被分配到哪个节点），limits才是Pod运行时能使用的资源上限。你之前的问题在于把非活跃服务的requests直接设为繁忙时的最低需求，导致调度器预留了大量闲置资源，节点数量居高不下。

针对不同服务的配置建议： #

• 非活跃服务：
  • requests.cpu：设为闲置时的实际占用值，比如50m（因为闲置时<0.1核=100m，取中间值即可）——这样调度器只会为每个Pod预留50m CPU资源，大大降低节点的预留负载。
  • limits.cpu：设为繁忙时的最大值300m——确保服务在短暂繁忙时能获取足够资源正常运行。
  • 示例Pod资源配置：

    resources:
      requests:
        cpu: "50m"
      limits:
        cpu: "300m"
    

• 繁忙服务：
  • requests.cpu：设为闲置时的平均占用值，比如第一类设100m，第二类设100m（对应闲置时0.1-0.5核、0.1-0.3核的区间下限）。
  • limits.cpu：设为繁忙时的最大值，第一类1000m，第二类800m。
  • 这样平时调度时占用的预留资源少，峰值时Pod可以burst到limits上限，同时HPA可以基于实际使用率触发扩容。

2. 优化HPA配置，精准触发扩缩容 #

HPA默认基于CPU使用率（相对于requests）触发，你需要针对服务的特性调整阈值和冷却时间：

非活跃服务的HPA配置： #

因为这类服务每日仅0-1小时繁忙，大部分时间闲置，建议：

• 目标CPU使用率设为70%（基于requests计算，即50m的70%=35m，当实际占用超过35m时触发扩容）。
• 缩容冷却时间（scaleDown.stabilizationWindowSeconds）设短一点，比如300秒（5分钟），这样闲置时能快速缩容到最小实例数（甚至可以设最小实例数为0，如果服务支持冷启动的话）。
• 示例HPA配置：

  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler
  metadata:
    name: inactive-service-hpa
  spec:
    scaleTargetRef:
      apiVersion: apps/v1
      kind: Deployment
      name: inactive-service
    minReplicas: 1 # 如果支持冷启动可设为0
    maxReplicas: 30
    metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    behavior:
      scaleDown:
        stabilizationWindowSeconds: 300
        policies:
        - type: Percent
          value: 50
          periodSeconds: 60
  

繁忙服务的HPA配置： #

针对每日8-12小时的繁忙期，建议：

• 目标CPU使用率设为80%，确保峰值时能及时扩容，同时避免不必要的扩缩容。
• 扩容冷却时间设长一点（比如900秒），缩容冷却时间设为600秒，适配较长的繁忙时段。

3. 调整节点自动扩缩容（Cluster Autoscaler）的参数 #

节点自动扩缩容是基于集群中所有Pod的requests总和加上节点预留资源来计算是否需要扩容的，优化requests后，你还可以调整Cluster Autoscaler的参数进一步控制节点数量：

• 扩容阈值：设置当节点的CPU请求使用率超过80%时触发扩容，避免过早扩容。
• 缩容阈值：设置当节点的CPU请求使用率低于40%时触发缩容，同时开启scale-down-unneeded-time（比如300秒），确保节点闲置一段时间后再缩容，避免频繁波动。
• 注意：确保Cluster Autoscaler的ignore-daemonsets-utilization等参数配置合理，避免DaemonSet占用的资源影响扩缩容判断。

4. 额外优化：考虑服务的冷启动与批量调度 #

如果非活跃服务支持冷启动（启动时间短，不影响业务），可以将HPA的minReplicas设为0，结合基于事件的自动扩缩容工具进一步优化——比如只有当有请求进入时才启动Pod，彻底释放闲置时的资源占用。

解答你的核心疑问 #

• 是否不该为非活跃服务设置CPU请求值？ 绝对不是！requests是Kubernetes调度的核心依据，没有requests的Pod会被标记为BestEffort QoS，在节点资源紧张时会被优先驱逐，反而会影响服务可用性。正确的做法是合理设置requests和limits，平衡调度效率和服务可用性。
• 为什么忽略非活跃服务仍会出现节点超过2台？ 大概率是繁忙服务的requests设置偏高，加上HPA扩容后的Podrequests总和超过了单节点的可用资源（节点通常会预留20%-30%的资源给系统组件）。优化繁忙服务的requests为闲置时的占用值，同时调高HPA的目标使用率，就能有效减少非峰值时段的节点数量。

内容的提问来源于stack exchange，提问作者Fulo Lin