Kubernetes 容器资源隔离与调优：基于 CCE 的 CPU 和内存治理实践

容器化并不意味着资源问题会自动消失。相反，多个工作负载共享节点后，CPU 争抢、内存耗尽和驱逐等现象可能相互影响。合理设置资源请求与限制，是保障 Kubernetes 集群稳定运行的重要基础。本文以华为云 CCE 为例，介绍一套从配置、观测到调优的实践方法。

先区分 requests 与 limits

requests 表示调度器为容器预留和评估的资源需求，影响 Pod 能否被放置到节点上；limits 则限制容器可使用的资源上限。CPU 超出限制时通常会被节流，表现为处理延迟上升；内存无法像 CPU 一样平滑限速，超过限制可能触发 OOM，容器被终止并重启。

对于稳定性要求较高的在线服务，建议结合历史监控和压测结果设置 requests，而不是直接填写节点容量的固定比例。limits 可以用于防止单个工作负载无限制争用资源，但限制过低同样会造成持续节流或频繁重启。

配置示例：为应用声明资源边界

下面的 Deployment 片段展示了容器资源配置方式。示例数值仅供参考，生产环境应根据应用实际峰值、实例数量和节点规格进行调整。

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

CPU 的 500m 表示半个 CPU 核，1 表示一个 CPU 核。为容器设置内存限制时，还应关注应用自身的堆内存、原生内存和运行时开销，避免将限制直接等同于业务堆大小。

结合监控识别瓶颈

在 CCE 中，可通过集群监控观察节点和工作负载的 CPU 使用率、内存使用量、重启次数及资源分配情况。排查时应把指标与业务延迟、错误率和流量变化结合起来分析：CPU 使用率偏高且延迟上升，可能说明存在计算压力或 CPU 节流；内存持续逼近限制并伴随重启，则需要检查内存泄漏、缓存增长或单实例负载过高。

不要只看某一时刻的平均值。建议关注业务高峰、发布过程和批处理任务期间的曲线，并结合容器事件确认是否发生过 OOMKilled 或驱逐。对于周期性负载，应留出足够余量，避免常态配置恰好贴近峰值。

按步骤进行调优

第一步，为关键工作负载补齐 requests 和 limits，避免无资源声明的容器在节点资源紧张时不可预测地争抢资源。第二步，基于一段时间的监控数据和代表性压测，校准 requests，使其能反映正常运行所需资源。第三步，逐步调整 limits，并通过灰度发布观察延迟、重启和节点余量变化。

如果 CPU 节流明显，可以评估提高 CPU limit、优化应用并行度，或增加副本分摊流量；如果出现内存 OOM，应先确认实际峰值和内存构成，再决定是扩容、增加容器限制还是修复应用问题。单纯提高 limit 可能只是推迟故障，也可能挤占同节点其他服务的资源。

让资源治理形成闭环

资源调优不是一次性设置。应用版本、请求量和业务逻辑变化都可能改变资源画像。建议将资源配置纳入部署清单和代码评审，并在发布后持续监控关键指标。对于多团队共享的 CCE 集群，还应结合命名空间配额与工作负载优先级，明确资源边界和保障策略。

通过合理使用 requests 与 limits，并以监控和压测验证配置，团队可以更准确地平衡服务稳定性与节点利用率。实践中应优先解决可观测到的瓶颈，再进行小步调整，避免凭经验盲目扩大资源配置。