3. 资源配额模型基础：Kubernetes ResourceQuota 与 LimitRange 机制
在云原生网关故障时间线中，资源配额模型是导致 Ingress 控制器异常退出的关键诱因之一。Kubernetes 通过 ResourceQuota 和 LimitRange 两个原生资源对象，构建了多租户场景下的资源管控边界。理解这两个机制的交互逻辑，是还原本次故障事件的前提。
3.1 ResourceQuota：命名空间级资源硬边界
ResourceQuota 为命名空间设置聚合资源上限，一旦总量超限，后续创建 Pod 的请求将被 API Server 拒绝。其核心管控维度包括：
| 资源维度 | 示例配置 | 作用范围 |
|---|---|---|
| CPU 请求（requests.cpu） | requests.cpu: "4" |
命名空间内所有 Pod 的 CPU 请求总和 |
| 内存请求（requests.memory） | requests.memory: "8Gi" |
命名空间内所有 Pod 的内存请求总和 |
| CPU 限制（limits.cpu） | limits.cpu: "8" |
命名空间内所有 Pod 的 CPU 限制总和 |
| 内存限制（limits.memory） | limits.memory: "16Gi" |
命名空间内所有 Pod 的内存限制总和 |
| 对象数量（count/*） | count/ingresses.extensions: "10" |
命名空间内 Ingress 资源实例数上限 |
故障关联点：当 Ingress 控制器所在命名空间配置了 ResourceQuota，且控制器 Deployment 的
requests 或 limits 未显式声明时，API Server 会依据 LimitRange 的默认值填充。若默认值超出 Quota 剩余容量，控制器 Pod 将无法调度，导致网关断流。
3.2 LimitRange：Pod 级资源默认值与约束
LimitRange 在命名空间级别为未显式设置资源请求/限制的 Pod 注入默认值，并设定每个容器可使用的资源上下界。其典型配置结构如下：
apiVersion: v1
kind: LimitRange
metadata:
name: ingress-controller-lr
namespace: ingress-system
spec:
limits:
- type: Container
default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "250m"
memory: "256Mi"
max:
cpu: "2"
memory: "2Gi"
min:
cpu: "50m"
memory: "64Mi"
关键字段说明：
- default：当容器未设置
resources.limits时，自动注入该值。 - defaultRequest：当容器未设置
resources.requests时，自动注入该值。 - max / min：强制约束每个容器的资源上限和下限，超出则拒绝创建。
3.3 配额校验流程与故障触发路径
下图展示了从 Pod 创建请求到 ResourceQuota 校验的完整链路，以及 LimitRange 在其中扮演的“默认值注入”角色：
3.4 配额冲突的典型场景
在本次故障时间线中，以下三种配额冲突模式直接导致了 Ingress 控制器不可用：
- 默认值超限：LimitRange 设置的
defaultRequest.memory: 512Mi，而 ResourceQuota 剩余内存仅 400Mi，导致控制器 Pod 无法调度。 - 对象计数配额：
count/ingresses.extensions设置为 50，但业务侧因配置错误创建了 60 个 Ingress 资源，超出配额后新 Ingress 无法生效。 - 资源范围冲突：LimitRange 的
max.cpu: "1"与控制器实际需要的limits.cpu: "2"矛盾，Pod 被准入控制拒绝。
3.5 最佳实践：避免配额导致的网关故障
推荐做法：
- 为 Ingress 控制器所在命名空间单独规划 ResourceQuota，预留 20% 的缓冲容量。
- 在控制器 Deployment 中显式声明
resources.requests和resources.limits，避免依赖 LimitRange 默认值。 - 定期使用
kubectl describe quota -n ingress-system监控配额使用率，设置告警阈值（如使用率 > 80%）。 - 将 Ingress 控制器与业务负载隔离到不同命名空间，避免业务配额波动影响网关。