2. 资源配额基础：Kubernetes ResourceQuota 与 LimitRange 原理、Flux 控制器默认资源请求与限制
2.1 为什么资源配额是 GitOps 的“第一道防线”
在 Flux 驱动的 GitOps 工作流中，控制器（source-controller、kustomize-controller、helm-controller 等）运行在集群内。如果不对这些控制器的资源消耗做限制，一旦出现配置错误、大规模资源同步或恶意 Manifest，可能导致控制平面资源耗尽，进而影响整个集群的稳定性。
Kubernetes 提供了两个核心资源管理原语：ResourceQuota 和 LimitRange。Flux 的官方部署清单也为其控制器设置了默认的 resource requests 和 limits。理解这些机制，是后续进行配额校准和瓶颈诊断的前提。
2.2 ResourceQuota：Namespace 级别的资源“天花板”
ResourceQuota 是一个 Namespace 级别的 API 对象，用于限制该 Namespace 内所有 Pod 的 聚合资源消耗。它定义了硬性上限（Hard）和可选的作用域（Scopes）。
2.2.1 工作原理
- 准入控制：当在 Namespace 中创建 Pod 时，Kubernetes 准入控制器会检查当前 Namespace 的累计资源使用量加上新 Pod 的请求量是否超过 ResourceQuota 的 Hard 限制。如果超过，则拒绝创建。
- 资源类型：可以限制 CPU、内存、存储（PVC）、以及对象数量（如 Pod、Service、ConfigMap 等）。
- 作用域：可以针对特定状态的 Pod（如 Terminating、NotTerminating、BestEffort、NotBestEffort）设置不同的配额。
2.2.2 典型配置示例
apiVersion: v1
kind: ResourceQuota
metadata:
name: flux-system-quota
namespace: flux-system
spec:
hard:
requests.cpu: "4"
requests.memory: "8Gi"
limits.cpu: "8"
limits.memory: "16Gi"
persistentvolumeclaims: "10"
pods: "50"
services: "20"
configmaps: "30"
secrets: "30"
scopeSelector:
matchExpressions:
- operator: In
scopeName: NotTerminating
2.2.3 关键参数对比
| 参数 | 含义 | 对 Flux 的影响 |
|---|---|---|
requests.cpu |
所有 Pod 的 CPU 请求总和上限 | 限制 Flux 控制器能调度的 CPU 总量 |
limits.memory |
所有 Pod 的内存限制总和上限 | 防止 Flux 控制器内存泄漏影响其他组件 |
pods |
Namespace 中允许的最大 Pod 数量 | 限制 Flux 控制器副本数及临时 Pod |
persistentvolumeclaims |
允许的 PVC 数量上限 | 限制 Flux 用于缓存或存储的 PVC 数量 |
2.3 LimitRange：Pod 级别的资源“护栏”
LimitRange 在 Namespace 级别设置 Pod 或容器的 默认资源请求/限制 以及 最小/最大约束。它确保每个 Pod 都遵循统一的资源规范，避免出现“超大 Pod”或“无限制 Pod”。
2.3.1 工作原理
- 默认值注入：如果 Pod 未指定 resource requests 或 limits，LimitRange 会自动注入默认值。
- 边界校验：如果 Pod 的请求或限制超出 LimitRange 定义的 min/max，则拒绝创建。
- 比例约束：可以设置 maxLimitRequestRatio，强制限制与请求的比例（如限制不能超过请求的 3 倍）。
2.3.2 典型配置示例
apiVersion: v1
kind: LimitRange
metadata:
name: flux-controller-limits
namespace: flux-system
spec:
limits:
- max:
cpu: "2"
memory: "2Gi"
min:
cpu: "100m"
memory: "128Mi"
default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "200m"
memory: "256Mi"
type: Container
2.3.3 LimitRange 与 ResourceQuota 的协同
| 维度 | ResourceQuota | LimitRange |
|---|---|---|
| 作用范围 | Namespace 聚合 | 单个 Pod/Container |
| 主要功能 | 设置资源上限 | 设置默认值、边界、比例 |
| 对 Flux 的意义 | 防止 Namespace 资源耗尽 | 确保每个控制器有合理的资源基线 |
| 冲突处理 | Pod 创建时检查配额 | Pod 创建时注入/校验 |
2.4 Flux 控制器默认资源请求与限制
Flux 官方提供的部署清单（如 gotk-components.yaml）为每个控制器设置了合理的默认资源请求和限制。这些值是经过社区实践验证的基线，但在生产环境中通常需要根据实际负载进行调整。
2.4.1 各控制器默认值一览
| 控制器 | CPU Request | CPU Limit | Memory Request | Memory Limit |
|---|---|---|---|---|
| source-controller | 100m | 500m | 64Mi | 512Mi |
| kustomize-controller | 100m | 500m | 64Mi | 512Mi |
| helm-controller | 100m | 500m | 64Mi | 512Mi |
| notification-controller | 50m | 250m | 32Mi | 256Mi |
| image-automation-controller | 100m | 500m | 64Mi | 512Mi |
| image-reflector-controller | 100m | 500m | 64Mi | 512Mi |
2.4.2 默认值的局限性
- 通用性：默认值适用于小规模集群和简单工作负载。对于管理数千个资源或频繁同步的大型集群，这些值可能不足。
- 内存泄漏风险：如果某个控制器出现内存泄漏，512Mi 的限制可能不足以触发 OOMKill，导致节点内存压力。
- CPU 突发：在初始同步或大规模资源变更时，500m 的 CPU 限制可能导致控制器处理延迟。
2.5 资源配额与 Flux 控制器的交互流程
下图展示了 ResourceQuota、LimitRange 与 Flux 控制器之间的交互关系，以及它们在 Pod 创建和运行阶段的作用。
2.6 常见陷阱与诊断思路
2.6.1 陷阱一：ResourceQuota 未设置导致“无限制”
如果 flux-system Namespace 没有 ResourceQuota，某个控制器的内存泄漏可能导致整个 Namespace 消耗大量节点内存，影响其他控制器甚至系统组件。
2.6.2 陷阱二：LimitRange 默认值过低
LimitRange 的 defaultRequest 如果设置过低（如 50m CPU），可能导致 Flux 控制器在负载高峰期 CPU 节流（Throttling），延长同步时间。
2.6.3 陷阱三：配额与控制器副本数不匹配
如果设置了 ResourceQuota 的 pods 上限为 10，但 Flux 控制器有 6 个，且每个控制器有 2 个副本，则总 Pod 数为 12，超过配额，导致部分副本无法创建。
kubectl describe quota -n flux-system 查看当前配额使用情况，使用 kubectl describe limitrange -n flux-system 查看默认值。对比实际 Pod 的 resource 字段，确认是否在配额范围内。
2.7 本章小结
- ResourceQuota 是 Namespace 级别的资源“天花板”，防止聚合资源超限。
- LimitRange 是 Pod 级别的资源“护栏”，确保每个容器有合理的资源基线。
- Flux 控制器的默认资源请求/限制适用于小规模场景，生产环境必须校准。
- 资源配额与 Flux 控制器的交互通过 Kubernetes 准入控制器实现，理解这一流程有助于快速定位资源相关故障。