📚 课程目录第3章 Kubernetes配额管理基础

3. Kubernetes 配额管理基础：ResourceQuota、LimitRange、PodDisruptionBudget 概念、配额与升级的关系

在集群升级过程中，配额管理是保障集群稳定性的第一道防线。ResourceQuota、LimitRange 和 PodDisruptionBudget 是 Kubernetes 内置的三种核心配额控制机制，它们分别从资源总量、单个 Pod 规格、以及 Pod 可用性三个维度对集群行为进行约束。理解这三者的工作原理及其与升级的关联，是后续进行 OPA 策略冲突排查的前提。

3.1 三种配额机制概述

机制	作用域	控制对象	核心作用
ResourceQuota	Namespace	资源总量（CPU/内存/PVC/对象数）	防止单个 Namespace 耗尽集群资源
LimitRange	Namespace	单个 Pod/Container 的资源请求与限制	约束 Pod 规格，避免资源碎片或超限
PodDisruptionBudget	Namespace	Pod 最小可用数 / 最大不可用数	保障应用在主动干扰（升级、驱逐）期间的可用性

关键认知： ResourceQuota 是“总量锁”，LimitRange 是“规格锁”，PDB 是“可用性锁”。升级时三者必须同时满足，否则升级操作会被拒绝或导致 Pod 无法调度。

3.2 ResourceQuota：Namespace 资源总量控制

ResourceQuota 定义了一个 Namespace 内所有 Pod 可消耗的资源上限。当配额耗尽时，后续的 Pod 创建请求将被 API Server 拒绝。

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

升级陷阱： 如果升级过程中 Deployment 的 replicas 增加，或新版本 Pod 的 requests/limits 比旧版本大，可能瞬间突破 ResourceQuota 上限，导致部分 Pod 创建失败。升级前必须计算新版本的总资源需求是否在配额范围内。

3.3 LimitRange：Pod 规格约束与默认值

LimitRange 在 Namespace 级别为 Pod 或 Container 设置默认的 requests/limits，并强制最小/最大规格。它解决了“未显式设置资源限制的 Pod 可能抢占过多资源”的问题。

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

  与升级的关联： 升级时如果新镜像的默认资源需求与 LimitRange 冲突（例如新版本要求最小 256Mi 内存，但 LimitRange 的 defaultRequest 只有 128Mi），Pod 可能无法通过准入检查。OPA 策略在此处常与 LimitRange 产生叠加约束。

3.4 PodDisruptionBudget：主动干扰下的可用性保障

PodDisruptionBudget（PDB）用于控制自愿性中断（如节点维护、集群升级、Deployment 更新）期间，同一应用中最多允许多少 Pod 同时不可用。它不保护非自愿性中断（如节点宕机）。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

PDB 有两种表达方式：minAvailable（最小可用 Pod 数）和 maxUnavailable（最大不可用 Pod 数）。两者互斥，只能选其一。

升级中的 PDB 行为： 当集群升级触发节点排水（drain）时，kubelet 会检查目标节点上的 Pod 是否受 PDB 保护。如果驱逐 Pod 会导致可用 Pod 数低于 PDB 阈值，排水操作将被阻塞，直到超时或手动干预。这是升级卡顿的常见原因之一。

3.5 配额与升级的关系：冲突链路图

下图展示了升级过程中三种配额机制如何协同或冲突，以及 OPA 策略的介入点。

3.6 升级前配额检查清单

计算新版本资源需求： 对比新旧 Deployment 的 requests/limits 总和，确认不超过 ResourceQuota 的 hard 值。
验证 Pod 规格边界： 检查新 Pod 的 CPU/内存是否在 LimitRange 的 min/max 范围内。
评估 PDB 影响： 确认升级策略（如 maxSurge、maxUnavailable）与 PDB 的 minAvailable 不冲突。
模拟 OPA 策略： 使用 opa eval 或 kubectl dry-run 测试新 Deployment 是否通过 OPA 规则。
预留缓冲配额： 在 ResourceQuota 中保留 10%-20% 的余量，应对升级过程中的临时资源波动。

  实战建议： 在升级前使用 kubectl describe quota -n <namespace> 查看当前配额使用率，使用 kubectl get pdb -n <namespace> 确认 PDB 状态。如果配额使用率超过 80%，建议先扩容配额或清理闲置资源，再执行升级。