Kubernetes 容器资源隔离与调优：从 requests 和 limits 到线上验证

在 Kubernetes 集群中，Pod 能否稳定运行，不只取决于应用代码，也取决于 CPU 和内存资源是否配置合理。requests 与 limits 设置过低，应用可能因资源竞争而出现延迟抖动；设置过高，则会造成节点装箱率下降，增加集群成本。有效的调优不是简单地把数值调大，而是依据工作负载特征持续测量和验证。

理解 requests、limits 与 QoS

requests 表示调度器为容器预留资源的参考值，调度时会据此判断节点是否有足够的可分配容量。limits 是运行时的资源上限：CPU 超出限制时通常会被节流，内存使用超出限制时则可能触发 OOM。两者的作用不同，不能把 requests 当作硬上限，也不能把 limits 当作资源预留。

Kubernetes 根据容器的 requests 和 limits 为 Pod 分配 QoS 类别。对于 CPU 和内存均配置且数值相等的容器，Pod 通常属于 Guaranteed；配置了 requests 但未满足 Guaranteed 条件时，通常属于 Burstable；未配置这些资源请求和限制时，则可能属于 BestEffort。发生节点内存压力时，QoS 会影响驱逐优先级，因此关键业务应避免长期处于资源配置完全缺失的状态。

从观测数据设定初始值

调优前先收集具有代表性的运行数据，例如工作日高峰期的 CPU 使用量、内存工作集、请求延迟和容器重启次数。不要只看瞬时峰值，也不要仅凭平均值设置资源：平均值可能掩盖突发负载，短暂峰值则未必需要永久预留。建议结合一段时间内的分位数与业务峰值分析，区分稳定需求、突发余量和不可接受的资源上限。

CPU requests 可参考稳定负载下的实际需求，并为并发波动留出余量。CPU limits 是否设置，应结合应用对延迟和突发能力的要求谨慎决定；过低的限制可能导致节流，即使节点仍有空闲 CPU。内存通常更需要关注工作集与峰值，因为容器不能像 CPU 一样通过节流平滑地处理超限。上线前还应通过压测观察扩容、缓存升温和批处理等场景。

资源配置示例

下面的 Deployment 示例为应用设置初始资源请求和限制。数值仅作示例，生产环境应根据实际监控、压测结果和节点规格调整，并确保镜像、探针及副本数符合业务要求。

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

结合监控验证效果

配置发布后，应同时检查 Pod 状态、节点水位和应用指标。可以使用 kubectl describe pod 查看调度事件与容器终止原因，使用 kubectl top pod 和 kubectl top node 快速观察当前资源用量；生产环境则建议通过 Prometheus、云监控或集群监控平台查看长周期趋势。重点关注 CPU throttling、内存工作集、OOMKilled、重启次数、请求延迟及错误率，而不只是资源使用百分比。

如果 CPU 使用频繁触及 limits，且延迟同步恶化，应评估提高上限、优化并发模型或进行水平扩容。若 Pod 经常因内存超限退出，应先确认是否存在泄漏或异常缓存增长，再根据工作集调整配置。反过来，若 requests 长期远高于实际需求，也可以在充分验证后下调，以改善调度与节点利用率。

建立可持续的调优闭环

资源调优应纳入发布与容量治理流程：先建立基线，再小范围变更，最后对比发布前后的延迟、错误率、驱逐和节点利用率。调整时避免同时修改多个关键参数，以便定位影响来源；同时为关键工作负载配置合理的副本数、探针和扩缩容策略。requests 与 limits 不是一次性答案，而是基于真实负载不断校准的运行参数。通过监控、压测与渐进式发布协同，才能在应用稳定性和集群成本之间取得平衡。