3. 资源配额（ResourceQuota）与LimitRange基础概念回顾

在集群升级过程中，资源配额与LimitRange是保障集群稳定性的第一道防线。理解它们的核心机制、作用范围以及常见误用场景，是后续进行瓶颈分析与调优的前提。

3.1 ResourceQuota：命名空间级别的资源硬边界

ResourceQuota 是 Kubernetes 内置的准入控制机制，用于限制命名空间（Namespace）级别的资源消耗总量。它定义了该命名空间下所有 Pod、PVC、Service 等对象可使用的资源上限。

3.1.1 可限制的资源类型

3.1.2 典型配置示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    pods: "50"
    persistentvolumeclaims: "10"
    requests.storage: "500Gi"

3.2 LimitRange：Pod/容器级别的资源默认值与约束

LimitRange 在命名空间级别生效，为未显式设置资源请求/限制的 Pod 或容器提供默认值，并强制约束单个 Pod/容器的资源上下界。

3.2.1 LimitRange 的两种约束模式

• 默认值注入（Default）：当 Pod 未设置 resources.requests 或 resources.limits 时，LimitRange 自动注入默认值。
• 边界约束（Min/Max）：强制 Pod 的请求/限制必须在 min 和 max 之间，否则拒绝创建。

3.2.2 典型配置示例

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: production
spec:
  limits:
  - max:
      cpu: "4"
      memory: "8Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

3.3 ResourceQuota 与 LimitRange 的协同关系

两者共同构成命名空间资源治理的“双保险”：

• LimitRange 控制单个容器的资源上下界与默认值。
• ResourceQuota 控制命名空间内所有容器的资源总量上限。

若未配置 LimitRange，ResourceQuota 可能因 Pod 未设置资源请求而无法准确统计；若未配置 ResourceQuota，LimitRange 无法防止命名空间整体资源超卖。

3.4 升级场景中的关键差异对比

3.5 常见误用与避坑指南

• 误区一：只配 ResourceQuota 不配 LimitRange
  后果：未设置资源请求的 Pod 会被 ResourceQuota 拒绝，或导致统计失真。
• 误区二：LimitRange 的 max 值设置过小
  后果：升级后控制面组件（如 kube-controller-manager）因资源需求增加而无法启动。
• 误区三：ResourceQuota 的 pods 上限未考虑滚动更新
  后果：升级期间新旧 Pod 共存，总数超过 quota，更新流程中断。
• 误区四：升级前未使用 kubectl describe quota 检查余量
  后果：升级过程中才发现资源不足，回滚成本高。