2. 资源配额概念：什么是资源配额、在API网关中的重要性、与限流的区别
2.1 资源配额（Resource Quota）定义
资源配额是云原生环境中一种硬性资源上限控制机制，用于限制某个租户、命名空间或工作负载在特定维度上能够消耗的最大资源量。在Kong网关的语境下，资源配额通常指对CPU、内存、Pod数量、ConfigMap大小、Service数量等基础设施资源的分配上限。
资源配额的核心特征包括：
- 静态上限：在部署时预先设定，运行时不可动态突破。
- 全局作用域：通常作用于Kubernetes Namespace或Helm Release级别。
- 资源维度：关注计算、存储、网络等底层基础设施资源。
- 准入控制：在资源创建或更新时由Kubernetes Admission Controller强制执行。
关键概念：资源配额是“容量规划”工具，确保单个租户不会耗尽集群共享资源，保障多租户环境下的资源公平性和系统稳定性。
2.2 在API网关中的重要性
在Kong网关的Helm部署场景中，资源配额的重要性体现在以下四个维度：
| 维度 | 说明 | 典型配额项 |
|---|---|---|
| 多租户隔离 | 防止某个业务线或团队的网关实例抢占其他租户的资源 | 每个Namespace的CPU/内存上限 |
| 成本控制 | 限制每个部署环境的资源消耗上限，避免超支 | Pod数量、PVC存储大小 |
| 稳定性保障 | 避免单个网关Pod因内存泄漏或突发流量导致集群OOM | 每个Pod的memory limit |
| 运维可预测性 | 通过配额约束使资源使用量可量化、可审计 | ConfigMap数量、Service数量 |
常见误区：很多团队只关注Kong的Rate Limiting插件，却忽略了底层Resource Quota的配置。当网关Pod因资源不足被OOMKill时，Rate Limiting无法提供任何保护——因为Pod已经不存在了。
2.3 与限流（Rate Limiting）的区别
资源配额与限流是不同层次的流量/资源控制机制，二者在目标、作用域、粒度、执行时机上存在本质差异。以下表格清晰对比：
| 对比维度 | 资源配额（Resource Quota） | 限流（Rate Limiting） |
|---|---|---|
| 控制对象 | 基础设施资源（CPU、内存、存储、Pod数） | API请求速率（RPS、QPS、并发连接数） |
| 作用层级 | Kubernetes Namespace / 集群级别 | Kong Route / Service / Consumer 级别 |
| 执行时机 | 资源创建/更新时（Admission Controller） | 请求处理时（Kong Plugin 运行时） |
| 粒度 | 粗粒度（整个Namespace或Release） | 细粒度（按Consumer、IP、Header等） |
| 超限后果 | Pod无法调度、资源创建被拒绝 | 返回429 Too Many Requests |
| 典型场景 | 多团队共享集群时的资源公平分配 | 防止单个用户滥用API、保护后端服务 |
| 配置方式 | Kubernetes ResourceQuota YAML / Helm values | Kong Plugin 配置（rate-limiting / response-ratelimiting） |
下图展示了资源配额与限流在Kong网关架构中的不同作用位置：
2.4 协同工作模式
在实际生产环境中，资源配额与限流需要协同配置才能构建完整的网关防护体系：
- 资源配额：确保Kong网关Pod有足够的CPU和内存资源，避免因资源不足导致Pod被驱逐或OOMKill。
- 限流：在Pod正常运行的前提下，控制进入网关的请求速率，防止后端服务被突发流量压垮。
- 互补关系：资源配额解决“能不能运行”的问题，限流解决“能不能承受”的问题。
最佳实践：在Helm部署Kong时，建议同时配置：
values.yaml中的resources.requests和resources.limits- Kubernetes
ResourceQuota对象（通过Helm模板或独立YAML） - Kong
rate-limiting插件（按Consumer或Route配置）