华为云 CCE 工作负载资源隔离与调优：从 requests、limits 到节点水位

容器化并不意味着资源问题会自动消失。多个工作负载共享节点时，如果没有合理设置 CPU 和内存边界，突发流量可能造成争抢，某个容器的内存增长也可能触发节点压力，影响同机服务。本文以华为云 CCE 上的 Kubernetes 工作负载为例，介绍一套可逐步落地的资源隔离与调优方法。

理解 requests 与 limits 的职责

requests 表示容器运行所需的资源基线，调度器据此判断节点是否有足够的可分配资源；它不是容器的实际占用，也不意味着节点会为容器预留一块物理内存。limits 则定义容器可使用的上限。CPU 超过限制时通常会被节流，内存超过限制时则可能触发 OOM 终止。两者应依据应用实测数据配置，不能简单地将所有容器统一设成相同数值。

从工作负载模板建立资源基线

以下 Deployment 示例适用于无状态服务的初始配置。数值仅供说明，生产环境应结合业务压测、监控曲线和副本数量进行调整。应用启动阶段若存在明显的内存峰值，也要将其纳入验证，避免只按稳定运行时的平均占用设限。

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:1.0
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

示例中，调度器会按每个副本 500 毫核 CPU 和 512 MiB 内存评估节点容量。CPU 上限为 1 核，内存上限为 1 GiB。上线前可先在测试环境观察容器实际使用量，再评估是否需要调整 requests；对于延迟敏感服务，还应关注 CPU 节流指标，避免过低的 CPU limit 在高峰期造成响应时间抖动。

关注 QoS、节点水位与驱逐风险

Kubernetes 会依据容器资源请求与限制为 Pod 归类 QoS：BestEffort、Burstable 和 Guaranteed。只设置部分资源请求或限制的 Pod 通常属于 Burstable；当 CPU、内存的 requests 与 limits 均设置且相等时，才可能满足 Guaranteed 条件。QoS 并非性能保证，但会影响节点资源紧张时的驱逐优先级判断。对于关键服务，应结合优先级、Pod 分布和副本冗余共同设计，而不是只依靠 QoS 等级。

在 CCE 中，建议同时查看工作负载的容器指标、节点 CPU 与内存水位，以及 Pod 重启和事件信息。若出现频繁重启，先通过 Pod 状态与事件确认是否为 OOM；若延迟升高但没有 OOM，则检查 CPU 节流、节点负载和调度分布。扩容节点或增加副本前，应先辨别瓶颈属于资源总量不足、单容器配置不合理，还是流量集中在少数实例。

建立可验证的调优闭环

资源调优应从采集数据开始：选取覆盖业务高峰的观察周期，记录 CPU、内存峰值、重启次数和请求延迟；随后一次只调整一种配置，并通过压测或灰度发布比较结果。对于批处理任务，可以接受较高的 CPU 使用率，但需避免挤压在线服务；对于内存使用随请求量增长的应用，应确认存在可靠的内存上界，并留出运行时开销。

最后，将验证有效的配置纳入 Deployment 或 Helm 等版本化模板，并设置变更审核与回滚路径。合理的 requests 有助于提高调度准确性，审慎的 limits 则能控制单个容器的资源影响范围。结合监控、容量评估和持续验证，才能让 CCE 集群在资源利用率与服务稳定性之间取得平衡。