华为云 CCE 容器资源隔离与调优：从资源配置到 CPU 限流排查

容器化并不意味着资源天然隔离。多个工作负载运行在同一节点时，CPU、内存和磁盘等资源仍需由 Kubernetes 调度和 Linux 内核共同管理。对于华为云 CCE 集群，合理设置 requests 与 limits，既能帮助调度器规划节点容量，也能降低资源争抢对业务的影响。

理解 requests 与 limits 的职责

requests 表示容器调度所需的资源基线，调度器会据此判断节点是否有足够容量。它不是性能保证的全部，但会影响 Pod 放置和资源超卖程度。limits 则是容器可使用资源的上限：内存超过限制时，容器可能被 OOM Killer 终止；CPU 超过限制时，通常会被 cgroup 限流，而不是直接结束进程。

需要特别注意，CPU 限流会造成请求延迟抖动。若应用配置了较低的 CPU limit，即使节点整体仍有空闲 CPU，容器也可能因触及自身配额而被节流。因此，CPU limit 不应简单照搬内存 limit 的配置思路，建议结合业务延迟目标和实测负载设置。

为工作负载设置可解释的资源边界

以下示例适用于常见在线服务。示例中的数值只是起点，生产环境应根据压测结果、实际峰值和节点规格调整。requests 与 limits 相同的容器通常更容易获得稳定的资源边界；若业务需要突发能力，也可以在充分评估集群超卖风险后为 CPU 设置高于 request 的 limit。

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

不要只关注单个 Pod 的配置，还要结合副本数核算节点可调度容量。例如，三个副本各请求 500m CPU，理论上至少需要为这组工作负载预留 1.5 核的调度资源，此外还应为系统组件、监控采集和业务突发留出空间。CCE 节点的可分配资源并不等于虚拟机规格标称值，规划时应查看节点 allocatable，并考虑 DaemonSet 等常驻负载。

通过指标定位 CPU 限流和内存压力

排查 CPU 问题时，不要只看 CPU 使用率。建议同时观察容器 CPU 使用量、限流次数或限流时间，以及接口延迟和错误率。若使用量并不高但限流指标持续增长，可能是 CPU 配额过紧或请求集中造成短时突发。可以在压测中逐步提高 limit，观察限流和延迟是否同步改善，再决定是否调整 requests 或扩容副本。

内存方面，应结合工作集、容器重启次数和 OOM 事件分析。应用的缓存、堆外内存和运行时开销都可能使实际占用高于预期。对 Java 服务等有明确堆配置的应用，应为堆外内存和系统开销留出余量，避免把 limit 全部交给堆使用。发生 OOM 后，优先核对容器 limit、进程内存曲线和启动参数，而不是仅通过不断提高节点规格掩盖问题。

形成持续调优闭环

资源调优应以监控和压测数据为依据：先设置合理的 requests，保证调度与容量规划可控；再根据峰值和服务等级目标配置 limits；上线后持续观察延迟、限流、OOM 和节点利用率。调整一次只改变少量关键参数，并通过灰度发布验证效果。对关键业务，还应设置资源告警和容量水位检查，避免节点资源耗尽时才被动处理。

总之，CCE 容器资源隔离不是填写一组固定数值，而是结合调度容量、内核限流机制和应用行为持续校准。把资源配置纳入压测、监控与发布流程，才能在资源利用率和服务稳定性之间取得更好的平衡。