华为云 CCE 容器资源隔离与调优：从 requests、limits 到运行时验证

容器化应用上线后，CPU 使用率看似正常，却出现响应延迟；或者节点仍有可用内存，Pod 却因为调度条件无法部署。这些现象往往与容器资源配置有关。在华为云 CCE 中，requests 和 limits 不只是填写在 YAML 中的数字，它们会影响 Pod 调度、资源隔离以及容器运行时的行为。

本文以一个普通业务容器为例，说明如何为资源设置合理的起点，如何理解 CPU 与内存限制的差异，以及如何结合监控和运行结果逐步调优。具体数值需根据应用负载、节点规格和压测结果调整，不能直接套用到所有生产环境。

一、requests 与 limits 分别解决什么问题

requests 表示容器申请的资源量。调度器会据此判断节点是否有足够的可分配资源，因此它影响 Pod 能否被放置到某个节点，也影响集群的资源预留。若 requests 明显高于应用的稳定需求，可能造成节点资源碎片；若设置过低，可能让节点承载过多工作负载，增加资源争抢风险。

limits 表示容器可使用的资源上限。CPU 超过 limit 时通常会受到节流，表现为处理延迟升高；内存则不能像 CPU 一样简单地“限速”，当容器持续超过内存限制时，可能被内核终止并出现 OOM。实践中，CPU limit 是否设置以及设置多高，需要结合延迟目标和集群隔离要求评估；内存 limit 则应覆盖应用正常峰值，并预留合理余量。

二、从可观测数据确定配置起点

不要只依据开发环境的启动占用来设定生产资源。建议在接近真实流量的压测或灰度期间，观察容器 CPU 使用量、内存工作集、重启次数、CPU 节流指标以及业务延迟。对于有明显日常波动的服务，还要区分稳定基线、短时峰值和异常增长，避免把一次偶发尖峰当成常态，也不要忽视周期性批处理造成的资源高峰。

初始配置可以将 requests 设为稳定运行时的资源需求，将内存 limit 设为经过压测验证的峰值上方，并为堆外内存、缓存和运行时开销留出空间。CPU 的 requests 与 limit 可根据业务对突发能力和公平隔离的要求分别设定。对于 JVM 等运行时，还需确保进程内存预算小于容器内存上限，否则即使堆大小看似合理，也可能因直接内存或线程栈占用而 OOM。

三、Deployment 配置示例

下面的示例为应用设置 CPU 和内存请求及上限，并配置探针与滚动更新。资源值仅用于说明字段含义；上线前应结合应用压测结果、CCE 节点规格和监控数据进行校准。探针路径也应替换为应用实际提供的健康检查接口。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-api
  template:
    metadata:
      labels:
        app: order-api
    spec:
      containers:
        - name: app
          image: example.com/order-api:v1.2.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10

requests 和 limits 的资源单位需要准确理解：CPU 的 500m 表示半个 CPU 核，内存单位 Mi、Gi 表示二进制量级。生产环境中还应检查副本数与节点可分配资源是否匹配，并为系统组件、DaemonSet 和节点自身开销保留空间，避免只按机器标称容量计算 Pod 密度。

四、部署后如何验证调优效果

部署后可使用 kubectl describe pod 检查资源配置、调度事件和容器重启原因，使用 kubectl top pod 查看即时 CPU 与内存使用情况。生产分析应以持续监控为准，因为瞬时采样无法代表高峰期表现。若 CPU 使用量不高但延迟明显升高，应进一步检查 CPU throttling、线程池排队和下游依赖，而不是盲目提高 limit。

若出现 OOMKilled，应检查容器内存曲线、应用堆与堆外内存占用、重启前日志及节点压力，并区分是 limit 太低、内存泄漏还是流量突增。若 Pod 长期使用远低于 requests 的资源，可在确认峰值和弹性余量后适当下调；若频繁触顶，则应先判断是容量不足还是应用效率问题，再决定扩容副本、增加资源或优化代码。

五、形成持续优化闭环

资源调优不是一次性填写 YAML，而是“测量、调整、验证、回滚”的持续过程。建议为关键服务设置资源使用和重启告警，将资源配置纳入版本管理，并在每次发布或流量结构变化后复核。对于不同优先级的工作负载，可结合命名空间配额、LimitRange 和 Pod 优先级完善隔离策略，避免单个团队或异常任务挤占共享集群资源。

最终目标并非让所有容器都配置相同的 requests 和 limits，而是在调度效率、性能稳定性与资源成本之间取得平衡。利用 CCE 监控数据、真实负载测试和容器运行状态持续校准，才能让资源配置真正服务于业务的稳定运行。