GKE集群Pod符合配额却调度失败及资源限制执行咨询

一、Pod调度失败原因分析及解决办法 #

你的报错信息must specify limits.cpu,limits.memory看起来矛盾，但其实大概率是下面几种情况之一：

1. 资源限制的缩进位置错误 #

仔细检查你的Deployment YAML，确保resources字段是嵌套在容器配置内部的。你提供的示例YAML缩进是正确的，但如果实际应用时不小心把resources和containers同级放置（而非每个容器的子字段），容器本身就没有配置任何资源限制，自然会触发Quota的强制要求。

正确的容器资源配置结构应该是：

containers:
- name: my-service
  # 其他容器配置...
  resources:
    requests:
      memory: "128Mi"
      cpu: "125m"
    limits:
      memory: "256Mi"
      cpu: "125m"

2. 存在未配置资源限制的额外容器 #

如果你的GKE集群启用了服务网格（比如Istio）、Cloud SQL Auth Proxy自动注入，或者Deployment里包含init容器，这些额外容器如果没有设置limits.cpu和limits.memory，就会违反ResourceQuota的强制要求——因为Quota要求命名空间内所有容器都必须配置这两个限制。

解决办法：

• 找到这些额外容器的配置，给它们添加对应的资源限制；
• 或者在该命名空间创建一个LimitRange，设置默认的CPU和内存限制，让未显式配置的容器自动继承默认值：

  apiVersion: v1
  kind: LimitRange
  metadata:
    name: default-limits
  spec:
    limits:
    - default:
        cpu: "100m"
        memory: "256Mi"
      defaultRequest:
        cpu: "50m"
        memory: "128Mi"
      type: Container
  

3. 命名空间不匹配 #

ResourceQuota是命名空间级别的资源，如果你把Quota应用到了A命名空间，但Deployment部署在B命名空间，Quota不会生效；不过这种情况通常不会触发你遇到的报错，你可以用kubectl get resourcequota -n <你的命名空间>和kubectl get deployment -n <你的命名空间>确认两者在同一个命名空间。

二、Pod超出资源限制时的管控逻辑 #

Kubernetes对CPU和内存的限制管控逻辑完全不同，因为两者属于不同类型的资源：

CPU资源（可压缩资源） #

当容器的CPU使用率超过limits.cpu时，Kubernetes会通过Linux的CFS带宽控制机制限制容器的CPU使用时间，简单来说就是“降速”——容器不会被杀死，但会被限制在配额内的CPU算力运行，性能会下降，但不会中断服务。

内存资源（不可压缩资源） #

内存是无法压缩的，当容器使用的内存超过limits.memory时，Linux内核会触发OOM Killer，直接杀死该容器。后续的行为取决于Pod的restartPolicy：

• 如果是Always或OnFailure，kubelet会尝试重启容器；
• 如果容器反复出现OOM，kubelet会启动重启退避机制，逐渐延长重启间隔。

另外，当节点整体内存不足时，kubelet会根据Pod的QoS等级（BestEffort > Burstable > Guaranteed）和资源使用情况，优先杀死优先级低、资源使用超过请求的Pod，以保证节点的稳定性。

内容的提问来源于stack exchange，提问作者Kalle Richter