华为云CCE容器资源隔离与调优实践：从Requests到HPA的协同治理

容器化并不意味着资源会自动分配得恰到好处。在CCE集群里，Pod的资源请求会影响调度决策，资源限制则约束容器运行时可使用的资源。配置过低，可能出现CPU竞争、内存不足或频繁重启；配置过高，又会降低节点装箱率，增加集群成本。资源治理的关键，是结合实际负载观测，为调度、运行和弹性伸缩建立一致的资源基线。

一、先理解Requests与Limits的职责

requests表示容器调度时声明的资源需求。调度器会据此判断节点是否有足够的可分配资源，但它不是容器运行时的硬性资源上限。limits表示运行时允许使用的资源边界。对于CPU，超出限制通常会触发节流；对于内存，超过限制可能导致容器被OOM终止。因此，CPU限制偏紧容易造成延迟抖动，内存限制偏紧则可能直接引发重启。

QoS等级也与资源配置有关。容器的CPU和内存请求、限制均相等且非零时，Pod通常属于Guaranteed；设置了请求或限制、但不满足Guaranteed条件时，通常属于Burstable；未设置资源请求和限制时，通常属于BestEffort。节点发生资源压力时，QoS会影响驱逐优先级。它不能替代容量规划，但能帮助团队理解资源不足时的行为差异。

二、为工作负载建立可执行的资源基线

下面以Deployment为例。示例数值仅用于说明配置方式，生产环境应根据压测和线上监控调整。建议先设置合理的requests，再结合延迟、CPU节流和内存峰值确定limits，避免直接照搬其他服务的资源值。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
        - name: api
          image: example.com/api-service:v1
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

其中500m表示半个CPU核。若服务对响应时间敏感，可评估放宽CPU限制，或在确认集群容量充足后不设置CPU limits，降低节流风险；但这不等于可以忽略CPU requests，否则调度器难以准确评估节点承载能力。内存则需要更加谨慎：根据工作集、启动峰值和缓存需求设置requests与limits，并通过OOM事件验证是否留有余量。

三、用监控与事件定位资源问题

调优前先建立观测闭环。可以使用kubectl查看Pod状态、资源声明和事件；在CCE监控中结合容器CPU使用率、内存工作集、重启次数及节点资源水位，分析问题发生的时间窗口。CPU使用率高不一定意味着配置错误，还要区分持续计算负载与短时突发；若响应延迟上升且CPU节流明显，应重点检查CPU limits。内存接近限制、发生OOMKilled或重启次数增长，则应分析内存曲线和应用堆配置。

kubectl describe pod <pod-name>
kubectl get pod <pod-name> -o yaml
kubectl top pod <pod-name> --containers
kubectl get events --sort-by=.lastTimestamp

注意，kubectl top展示的是采样时的使用情况，不能单独代表峰值；也不能只依据瞬时CPU使用率调整requests。应结合业务高峰、压测结果、历史曲线和节点可分配资源进行判断。变更后采用小流量或分批发布，观察延迟、错误率、重启和节点水位，再决定是否扩大范围。

四、让HPA与资源请求协同工作

基于CPU利用率的HPA通常需要配置容器CPU requests，因为利用率的计算与资源请求相关。若requests设置得过高，利用率可能长期偏低，扩容不及时；设置得过低，则可能很快触发扩容，造成副本数波动。应同时检查HPA目标值、最小与最大副本数、扩缩容稳定策略，并确认集群有足够节点容量承接新增Pod。HPA增加副本只能缓解可水平扩展的负载，无法修复内存泄漏或单实例内部瓶颈。

五、落地建议

资源调优适合按服务逐步推进：先梳理关键工作负载，记录当前请求、限制与实际峰值；再通过压测和线上数据校准资源基线；随后在变更窗口中分批发布，并设置可回滚方案。对批处理、在线服务和基础组件应采用不同策略，避免用一套模板覆盖所有负载。最终目标不是把资源用满，而是在满足性能与稳定性要求的前提下，提高节点利用率，并让调度、运行限制和弹性伸缩能够相互配合。