华为云CCE容器资源隔离与调优实践：从requests和limits到稳定运行

在共享节点的Kubernetes集群中，容器并不是天然隔离的。一个服务突发消耗CPU，可能拖慢同节点上的其他业务；内存使用失控，则可能触发节点压力驱逐，甚至导致容器被OOM终止。在华为云CCE上，合理配置容器资源请求与限制，是保障工作负载稳定运行的基础。

先理解requests和limits的区别

requests表示容器申请的资源量，调度器主要依据它判断Pod能否放入某个节点。若requests设置明显偏低，节点看起来仍有可用容量，却可能在实际运行时发生资源争用。limits则约束容器可使用的资源上限：CPU超过限制时通常会被节流，内存超过限制时则可能触发OOM。CPU和内存的行为并不相同，配置时不能把二者简单等同。

一般建议先依据服务在代表性负载下的观测结果设置requests，再结合峰值和服务承受能力设置limits。CPU通常可以根据延迟目标留出突发空间；内存则要重点关注工作集、缓存以及启动过程的峰值，避免把上限设得过紧。

在工作负载中声明资源边界

以下示例适用于普通Deployment，可根据业务压测结果调整数值。配置更新后，应观察Pod重建、调度结果和容器实际使用情况，而不是只依据YAML中的数值判断容量是否充足。

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

示例中，调度器会按每个副本申请的CPU和内存评估节点容量。CPU的500m相当于半个CPU核，limits允许容器在有资源可用时使用更多CPU，但实际执行仍受节点竞争和CPU节流机制影响。内存上限为1Gi，超过后容器可能被终止，因此上线前应验证启动、流量峰值和缓存增长期间的内存表现。

用命名空间配额防止资源失控

仅为单个工作负载设置资源，并不能避免团队在命名空间中创建过多Pod。可以配合ResourceQuota限制命名空间可使用的资源总量，并通过LimitRange提供默认值或单容器边界。这样既能防止误配置无限扩容，也能降低未声明资源请求的工作负载对调度预期造成的影响。配额数值应结合集群容量、业务优先级和预留空间制定，不宜直接填满节点可分配资源。

结合指标验证调优效果

在CCE集群中，可结合云监控、Prometheus或集群监控能力观察CPU使用率、内存工作集、重启次数、Pod调度失败和节点压力事件。若CPU长期接近limit且延迟同步升高，应检查CPU节流并评估调整资源或扩容；若内存持续逼近limit，应分析堆、缓存和非堆内存，而不是简单放大上限。requests若远高于实际需求，会造成资源碎片和调度困难；过低则可能令节点超卖风险上升。

落地建议

资源调优应形成“基线测量、配置请求与限制、逐步发布、观察指标、再次校准”的闭环。生产变更可先选择少量副本进行验证，同时检查节点可分配资源和业务SLO。对延迟敏感服务，还应综合考虑副本数、探针、拓扑分布和自动扩缩容策略。通过细粒度资源隔离与持续观测，才能让CCE集群在共享节点场景下兼顾利用率与服务稳定性。