3. Kubernetes 资源配额基础：ResourceQuota、LimitRange、PriorityClass 的工作原理

在 Kubernetes 集群中，资源管理是保障多租户隔离、防止资源争抢、提升调度效率的核心手段。本章深入剖析三大原生资源管控组件：ResourceQuota、LimitRange 与 PriorityClass。理解它们的工作原理，是后续实现 Argo CD 资源配额自动校准的基石。

3.1 三大组件职责总览

下表从作用域、生效时机、管控对象三个维度对比三者的核心差异：

3.2 ResourceQuota：Namespace 资源总量硬约束

ResourceQuota 是一个 Namespace 级别的准入控制资源。当用户在该 Namespace 内创建 Pod、Service、PersistentVolumeClaim 等对象时，Kubernetes 准入控制器会检查当前 Namespace 已使用资源总量加上新请求资源量是否超过 Quota 限制。若超出，则拒绝创建。

3.2.1 核心字段与示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    limits.cpu: "16"
    limits.memory: "32Gi"
    persistentvolumeclaims: "10"
    pods: "50"
    count/services: "20"
    count/secrets: "50"

• requests.cpu / requests.memory：所有 Pod 的 request 总和上限。
• limits.cpu / limits.memory：所有 Pod 的 limit 总和上限。
• pods / persistentvolumeclaims：对象数量上限。
• count/<resource>：通用对象计数，支持 Service、ConfigMap、Secret 等。

3.2.2 资源配额与性能调优的关系

在 Argo CD 自动校准场景中，ResourceQuota 是“硬边界”。如果 Quota 设置过小，会导致 Pod 创建失败，影响应用发布；如果设置过大，则失去资源管控意义。性能调优的目标是：在 Quota 硬约束下，最大化资源利用率。

3.3 LimitRange：单体资源边界与默认值注入

LimitRange 同样作用于 Namespace 级别，但它管控的是单个 Pod 或 Container 的资源规格。它有两个核心职责：

1. 默认值注入：如果 Pod 未显式设置 request/limit，LimitRange 会自动注入默认值。
2. 边界校验：强制 Pod 的 request/limit 必须在指定范围内。

3.3.1 典型配置示例

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

• max / min：Container 的 limit 和 request 的边界。
• default：当 Container 未设置 limit 时，注入此值作为 limit。
• defaultRequest：当 Container 未设置 request 时，注入此值作为 request。

3.3.2 LimitRange 对性能的影响

LimitRange 的默认值直接影响 Pod 的 QoS 等级和调度决策。如果默认 request 设置过高，会导致节点资源碎片化；如果默认 limit 设置过低，可能引发 OOMKill。自动校准系统需要根据历史 Pod 实际资源使用数据，动态调整 LimitRange 的默认值。

3.4 PriorityClass：调度优先级与抢占行为

PriorityClass 是一个集群级别的资源，它定义了一个优先级数值（整型，值越大优先级越高）以及可选的抢占策略。Pod 通过 priorityClassName 字段引用 PriorityClass，从而获得对应的调度优先级。

3.4.1 优先级与资源配额的关系

ResourceQuota 和 LimitRange 管控的是资源数量，而 PriorityClass 管控的是资源分配顺序。当集群资源紧张时，高优先级 Pod 可以抢占低优先级 Pod 的资源。这种抢占行为会直接影响 Quota 的使用率：

• 高优先级 Pod 被调度后，可能驱逐低优先级 Pod，导致低优先级 Pod 的 Quota 被释放。
• 如果 PriorityClass 配置不当，高优先级 Pod 可能频繁抢占，造成低优先级应用不稳定。

3.4.2 典型配置示例

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "用于关键业务 Pod，允许抢占"
preemptionPolicy: PreemptLowerPriority

• value：优先级数值，Kubernetes 内置的默认优先级为 0。
• globalDefault：如果为 true，则未指定 priorityClassName 的 Pod 将使用此 PriorityClass。
• preemptionPolicy：PreemptLowerPriority 或 Never。前者允许抢占，后者禁止。

3.5 三组件协同工作流

下图展示了当用户提交一个 Pod 时，ResourceQuota、LimitRange、PriorityClass 三者的协同校验与注入流程：

3.6 性能调优视角下的关键指标

在 Argo CD 自动校准系统中，需要持续监控以下指标来驱动配额调整：

3.7 常见误区与避坑指南

• 误区一： 认为 ResourceQuota 只限制 CPU 和内存。实际上它还可以限制存储、对象数量（如 Service、ConfigMap），甚至自定义资源。
• 误区二： 在同一个 Namespace 中创建多个 ResourceQuota 对象。Kubernetes 会取所有 Quota 的并集作为硬限制，容易导致配置混乱。建议每个 Namespace 只维护一个 Quota。
• 误区三： 忽略 PriorityClass 的 globalDefault 设置。如果集群中只有一个 PriorityClass 且设置了 globalDefault: true，所有未显式指定优先级的 Pod 都会继承该优先级，可能导致非预期的抢占行为。
• 误区四： LimitRange 的 default 和 defaultRequest 设置相同值。这会导致 Pod 的 request 等于 limit，QoS 等级变为 Guaranteed，虽然稳定但资源利用率低。建议根据业务特性设置合理的 request/limit 比例。