2、核心概念解析：GitOps 工作流、声明式配置、资源配额（ResourceQuota）、LimitRange

在构建资源配额校准平台之前，必须透彻理解支撑其运行的四个核心概念。它们共同构成了从“声明期望状态”到“自动执行与边界控制”的完整闭环。下面逐一拆解其定义、关系与实战价值。

2.1 GitOps 工作流：以 Git 为单一事实来源

GitOps 是一种以 Git 仓库作为声明式基础设施和应用程序的单一事实来源（Single Source of Truth）的运维模式。其核心工作流遵循“Pull 而非 Push”原则。

2.2 声明式配置：描述“最终状态”而非“操作步骤”

声明式配置（Declarative Configuration）是 Kubernetes 和 GitOps 的基石。你只需在 YAML 文件中描述资源的“最终期望状态”，系统会自动计算并执行达到该状态所需的操作。

# 声明式配置示例：ResourceQuota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    pods: "20"

2.3 ResourceQuota：命名空间的资源“天花板”

ResourceQuota 是 Kubernetes 内置的准入控制机制，用于限制一个命名空间内所有 Pod 的资源消耗总量。它是防止单个团队或应用“抢占”集群全部资源的第一道防线。

ResourceQuota 核心字段

2.4 LimitRange：单个 Pod 的资源“边界”

LimitRange 是 ResourceQuota 的“搭档”。它定义了命名空间内单个容器或 Pod 的资源请求与限制的默认值及取值范围。没有 LimitRange，ResourceQuota 可能被一个“巨型”Pod 瞬间耗尽。

# LimitRange 配置示例
apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "256Mi"
    type: Container

2.5 四者关系总结