Namespace CPU配额请求超出Pod CPU请求总和的原因排查

你提供的命名空间配额数据如下：

Namespace Quota:
Resource    Used     Hard
--------    ----     ----
count/pods  94       300
cpu         17800m   32
memory      66949Mi  192Gi

针对CPU配额使用量（17800m）与Pod CPU请求总和（约12核）的差异，以下是几个核心排查方向：

• Terminating状态的Pod未被及时清理
  Kubernetes会将处于Terminating状态的Pod资源请求持续计入配额，直到Pod完全被集群删除。你可以用以下命令查看这类Pod：

  kubectl get pods -n <你的命名空间> --field-selector=status.phase=Terminating
  

  这些Pod的CPU请求会被配额统计，但常规统计运行中Pod时会被排除在外。

• Failed状态的Pod残留
  未被垃圾回收机制清理的Failed状态Pod，其资源请求也会被纳入配额计算。检查命令：

  kubectl get pods -n <你的命名空间> --field-selector=status.phase=Failed
  

• Init容器的资源请求未被统计
  若你统计Pod CPU请求时只计算了主容器，忽略了init容器，会导致总和偏低。汇总所有init容器CPU请求的命令：

  kubectl get pods -n <你的命名空间> -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .spec.initContainers[*]}{.resources.requests.cpu}{"\n"}{end}{end}'
  

  将这部分数值加到主容器请求总和中，看是否与配额使用量匹配。

• Job/CronJob的残留Pod
  Job或CronJob创建的Pod，如果未配置TTL自动清理规则，任务完成后可能残留；处于暂停状态的Pod也会占用配额。先查看相关资源：

  kubectl get jobs -n <你的命名空间>
  kubectl get cronjobs -n <你的命名空间>
  

  再检查这些资源对应的Pod状态。

• 配额统计的是CPU Limits而非Requests
  虽然你看到的配额显示是cpu，但部分配额可能被配置为统计CPU Limits而非Requests。查看配额的具体配置：

  kubectl get resourcequota -n <你的命名空间> -o yaml
  

  确认是否是limits.cpu被纳入配额计算范围。

• 临时容器（Ephemeral Containers）的资源占用
  通过kubectl debug添加的临时容器，其资源请求会被计入配额，但常规Pod统计命令可能不会包含这些容器。检查命令：

  kubectl get pods -n <你的命名空间> -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{range .spec.ephemeralContainers[*]}{.resources.requests.cpu}{"\n"}{end}{end}'
  

内容的提问来源于stack exchange，提问作者Dimitri Danilov