Kubernetes 容器资源隔离与调优实践：从 requests 到 OOM 排查

在 Kubernetes 集群中，Pod 能否稳定运行，不只取决于应用代码，也取决于 CPU 和内存资源是否配置合理。requests 影响调度器对节点可用资源的判断，limits 则为容器设置资源使用上限。配置过低会引发争抢或内存终止，配置过高又会降低节点装箱率，增加集群成本。

本文以一个持续提供 HTTP 服务的应用为例，梳理资源配置的基本原则，以及如何结合监控和容器状态逐步定位问题。需要注意的是，具体参数应根据负载测试与生产观测调整，不能简单照搬示例数值。

理解 requests、limits 与 QoS

CPU request 表示调度时为容器预留的计算资源参考值，不是独占 CPU；CPU limit 则约束容器可使用的 CPU 配额，达到上限时可能受到节流，表现为延迟升高。内存 request 用于调度参考，内存 limit 是更严格的使用边界，超过上限时容器可能被内核 OOM 机制终止。

Kubernetes 根据资源请求与限制将 Pod 分为 Guaranteed、Burstable 和 BestEffort 等 QoS 类别。为关键业务设置合理且匹配的 CPU、内存请求和限制，通常比完全不声明资源更可控；但是否将 request 与 limit 设为相同值，应结合应用对突发流量的承受能力及节点资源规划决定。

用观测数据建立资源基线

不要仅凭开发环境的空闲状态设定生产资源。应在具有代表性的压测和实际业务流量下观察 CPU 使用率、工作集内存、请求延迟、重启次数与 OOM 事件。CPU 可关注一段时间内的使用趋势及限流情况；内存则应结合工作集和峰值评估，并为 GC、缓存增长及短时流量波动预留余量。

对于有明显业务峰谷的服务，可按峰值与稳定运行需求综合评估。若调整后出现 CPU throttling 增多，应检查 CPU limit 是否过紧；若 Pod 因 OOMKilled 退出，则需结合容器峰值内存、应用堆配置和节点压力判断原因，而不是盲目持续提高 limit。

配置示例与落地建议

下面的 Deployment 片段展示了资源声明方式。示例值仅用于说明字段含义，实际部署前应按应用画像和集群规格校准。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
        - name: web-api
          image: example.com/web-api:v1
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

上线时应分阶段调整，并通过滚动发布观察错误率、P95/P99 延迟、重启和节点余量。对于同一工作负载，保持副本间资源配置一致，有助于调度行为更加可预测。还应结合节点池规格、Pod 密度及系统组件预留资源，避免把节点可分配容量全部交给业务容器。

排查 CPU 节流与 OOM

发现延迟升高时，先确认应用请求量和线程、连接池等内部指标，再检查 CPU 是否接近 limit、是否存在明显节流，并比较不同副本的负载分布。若 CPU 使用低但延迟仍高，应继续检查下游依赖、锁竞争与网络，而不是只增加 CPU 配额。

排查内存问题时，可查看 Pod 的重启次数、上一容器状态中的退出原因以及事件信息，确认是否为 OOMKilled。随后对照容器监控曲线、应用堆与非堆内存指标、缓存策略和对象分配情况。修复根因后，再逐步调整资源限制，并设置告警覆盖持续高内存、频繁重启和节点内存压力。

总结

容器资源调优是一项持续治理工作：先通过压测和生产监控建立基线，再结合 requests、limits 与 QoS 明确调度和运行边界，最后通过分阶段变更验证效果。把资源配置纳入版本管理，并定期复核业务增长和节点容量，才能在稳定性与资源利用率之间取得平衡。