华为云 CCE 容器资源隔离与调优：从 requests、limits 到稳定性验证

容器资源配置看起来只是几行 YAML，却直接影响 Pod 能否被调度、应用是否会被限流，以及节点在资源紧张时如何处置工作负载。在华为云 CCE 集群中，合理设置 CPU 与内存 requests、limits，是提升集群资源利用率和应用稳定性的基础。本文以常见的无状态服务为例，说明如何制定配置并通过运行数据验证效果。

先区分调度预留与运行上限

requests 表示 Kubernetes 调度器为容器计算资源需求时采用的参考值。调度器会综合节点可分配资源与 Pod 的 requests，判断 Pod 是否能够放置到节点上。它不是容器在任何时刻都只能使用的硬上限。limits 则用于约束容器实际资源使用：CPU 超过 limit 时通常会受到限流；内存无法像 CPU 一样平滑限速，持续超过 limit 可能导致容器被终止并出现 OOM。

因此，不能简单地把 requests 和 limits 都设成越小越好，也不宜不看负载就统一设为相同值。requests 过低会让节点超卖加剧，多个 Pod 同时繁忙时可能互相争抢；requests 过高则会降低调度空间，造成节点有实际余量却无法接纳新 Pod。limit 过低会限制突发流量下的 CPU 使用，内存 limit 过高则可能放大节点内存压力。

为典型无状态服务设置资源基线

下面的示例仅用于说明配置结构，数值应根据应用语言、并发模型、压测结果和生产监控进行调整。对于启动较慢或有明显流量峰值的服务，可以在观测数据基础上为 CPU 保留一定突发空间；内存则应重点关注峰值、垃圾回收行为和容器重启记录。

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"

这里的 CPU 单位 m 表示千分之一核，500m 即半个 CPU 核；内存使用二进制单位 Mi 和 Gi。示例中的三个副本会分别参与资源计算，规划节点容量时还要为系统组件、DaemonSet、滚动更新期间的新旧 Pod 共存，以及其他工作负载预留空间。

结合 QoS 与调度风险制定策略

Kubernetes 会根据 Pod 中容器的 requests 和 limits 等配置划分 QoS 类别。容器资源约束符合 Guaranteed 条件时，Pod 可获得 Guaranteed 类别；配置不满足该条件但设置了资源请求或限制时，通常属于 Burstable；未设置相关资源约束的 Pod 通常属于 BestEffort。节点内存压力出现时，QoS 类别会影响驱逐优先级，但它不是应用永不被驱逐的保证。对于关键业务，仍需配合副本数、反亲和策略、探针和容量规划共同设计。

CPU limit 并非所有工作负载都必须配置。对延迟敏感、容易受 CPU 限流影响的服务，应特别关注限流指标和请求延迟；如果业务需要限制单个容器对节点的最大 CPU 消耗，可以设置 limit，并以压测确认不会造成明显尾延迟。内存 limit 则应谨慎设置，避免将正常峰值误判为异常。资源配额和 LimitRange 也可用于命名空间治理，减少单个团队无约束申请资源带来的风险。

在 CCE 中验证配置是否有效

发布前先通过压测覆盖正常负载、峰值负载和冷启动场景，记录 CPU 使用率、CPU 限流、内存工作集、重启次数及接口延迟。发布后，可使用集群监控与容器指标观察趋势，并结合 kubectl describe pod 查看调度事件和容器状态，使用 kubectl top pod 获取即时资源使用概况。即时值不能替代历史峰值分析，建议结合监控平台的时间序列数据判断配置是否留有足够余量。

如果 Pod 长期远低于 requests，可在评估业务峰值后逐步下调；如果 CPU 限流频繁且延迟同步上升，应检查 CPU limit 是否过紧，并通过压测验证调整结果。若出现 OOMKilled，应结合内存曲线、应用堆配置和日志分析根因，而不是只增加 limit。采用小批量发布、观察指标再扩大范围，可以降低资源配置变更的风险。

总结

容器资源调优的目标不是追求最低 requests 或最高利用率，而是在可调度性、资源成本与故障风险之间取得平衡。以实际负载确定 requests，用压测评估 limits，持续关注 CPU 限流和内存峰值，并将应用副本、节点容量及命名空间治理纳入统一规划，才能让华为云 CCE 上的工作负载更加稳定、可预测。