4. 配额管理基础：Kubernetes ResourceQuota 与 LimitRange 原理、命名空间级别配额、节点池级别配额映射

在 GitOps 交付节点池的巡检与校准场景中，配额管理是保障集群稳定性和资源公平性的第一道防线。本章深入剖析 Kubernetes 原生配额机制的核心原理，并建立从命名空间配额到节点池资源映射的完整知识体系。

4.1 ResourceQuota：命名空间资源上限的硬边界

ResourceQuota 是 Kubernetes 内置的准入控制机制，用于限制命名空间内所有 Pod 的资源总和上限。它定义了两种类型的配额：计算资源配额（CPU、内存）和对象数量配额（Pod、Service、PVC 等）。

4.1.1 ResourceQuota 关键字段与示例

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

4.2 LimitRange：Pod 级别的资源约束与默认值

LimitRange 在 Pod 级别施加约束，确保每个 Pod 的资源请求和限制在合理范围内。它解决了两个关键问题：防止单个 Pod 过度占用资源，以及为未显式设置资源请求的 Pod 提供默认值。

4.2.1 LimitRange 的三种约束类型

• Min / Max：定义 Pod 或容器资源请求和限制的最小/最大值。超出范围的 Pod 创建请求会被拒绝。
• Default：当 Pod 未设置资源限制（Limit）时，自动注入默认值。
• DefaultRequest：当 Pod 未设置资源请求（Request）时，自动注入默认值。
• MaxLimitRequestRatio：限制 Limit 与 Request 的最大比例，防止资源超卖过度。

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

4.3 命名空间级别配额与节点池级别配额的映射关系

在 GitOps 交付节点池的场景中，配额管理需要从命名空间维度映射到节点池维度。这种映射是巡检校准的核心逻辑之一。

4.4 配额映射的巡检校准策略

在 GitOps 工作流中，配额映射的巡检校准需要遵循以下步骤：

1. 采集命名空间配额数据：通过 kubectl get resourcequota -n <namespace> -o yaml 获取当前配额配置和使用量。
2. 计算节点池容量：汇总节点池内所有节点的可分配资源（Allocatable），排除系统预留和 DaemonSet 开销。
3. 建立映射关系：根据命名空间标签、调度策略或亲和性规则，确定命名空间与节点池的对应关系。
4. 执行配额校验：比较命名空间配额总和与节点池容量，计算超卖比例和剩余容量。
5. 生成校准建议：当超卖比例超过阈值（如 1.5x）或配额使用率超过 80% 时，触发 GitOps 自动校准流程。

4.5 配额管理在 GitOps 交付中的实践要点