1. 课程导论：Requests Limits 治理的背景、配置漂移的定义与危害、审计方法的必要性
1.1 云原生网关资源配额治理背景
在云原生架构中，云原生网关（如 Kong、APISIX、Envoy、Istio Ingress Gateway）已成为南北向与东西向流量的统一入口。网关的 Requests（请求数）与 Limits（限制） 是资源配额模型的核心参数，直接决定服务能否获得稳定的连接池、并发处理能力与熔断保护。
随着微服务数量从几十个增长到上千个，网关配置规模呈指数级膨胀。手动维护每个路由、上游、插件的 requests/limits 参数变得不可持续，配置漂移问题日益突出。
核心痛点： 生产环境中，超过 60% 的网关故障根因可追溯到 requests/limits 配置与预期模型不一致，而非代码逻辑缺陷。
1.2 配置漂移的定义与分类
配置漂移（Configuration Drift）是指网关运行时实际生效的 requests/limits 参数与基线模型（Git 仓库、CMDB 或 IaC 模板）中定义的期望状态之间产生偏差的现象。根据漂移来源，可分为以下三类：
| 漂移类型 | 定义 | 典型场景 | 风险等级 |
|---|---|---|---|
| 手动漂移 | 运维人员通过 Dashboard 或 API 直接修改，未同步至 IaC | 紧急扩容时临时调高 limits，事后忘记回写 | 高 |
| 版本漂移 | CI/CD 流水线部署了与基线不一致的配置版本 | 分支合并冲突导致旧配置覆盖新配置 | 中 |
| 环境漂移 | 不同环境（开发/预发/生产）的 requests/limits 参数不一致 | 预发环境使用 100 QPS 限制，生产环境实际为 500 QPS | 高 |
审计警示： 手动漂移是配置漂移中最常见且最难追溯的类型。一次未记录的临时修改，可能在数周后引发级联故障，且根因定位平均耗时超过 4 小时。
1.3 配置漂移的危害
配置漂移对云原生网关的稳定性、安全性与可审计性构成直接威胁，具体危害包括：
- 容量过载： limits 被意外调低，导致正常流量触发限流熔断，影响 SLO。
- 资源浪费： requests 被调高但未同步，造成网关节点资源闲置，成本上升。
- 安全漏洞： 漂移后的配置可能绕过速率限制，为 DDoS 攻击打开缺口。
- 审计盲区： 缺乏配置变更的完整时间线，无法通过合规审查（如 SOC 2、PCI DSS）。
- 回滚困难： 漂移后的配置与 IaC 模板脱节，回滚操作可能导致二次故障。
1.4 审计方法的必要性
传统的“人工巡检 + 事后复盘”模式已无法应对云原生网关的动态性与规模。引入系统化的 配置漂移审计方法 具有以下不可替代的价值：
- 持续合规： 自动比对运行时配置与基线模型，确保每次变更可追溯、可回滚。
- 故障预防： 在漂移引发故障前发出告警，将 MTTR（平均修复时间）从小时级压缩到分钟级。
- 成本优化： 通过审计发现资源过度配置的漂移项，每年可节省 15%-30% 的网关资源成本。
- 安全加固： 检测到 limits 被意外放宽时自动阻断，防止速率限制被绕过。
- 团队协作： 审计报告作为 IaC 与运维团队之间的“事实来源”，消除信息孤岛。
最佳实践： 将审计方法嵌入 CI/CD 流水线，在配置部署前执行“预审计”检查，从源头减少漂移进入生产环境的概率。
1.5 课程核心框架预览
本课程将围绕以下四个阶段构建完整的 requests/limits 配置漂移审计体系：
| 阶段 | 核心内容 | 交付物 |
|---|---|---|
| 基线建模 | 定义 requests/limits 的期望状态模型（YAML/CRD） | 基线模板库 + 版本控制策略 |
| 漂移检测 | 运行时配置采集、差异计算、漂移分类与优先级排序 | 漂移检测引擎 + 告警规则 |
| 审计追溯 | 配置变更时间线构建、责任人定位、影响范围分析 | 审计日志 + 可视化时间线 |
| 修复与预防 | 自动修复策略、IaC 同步、漂移预防护栏 | 修复 Playbook + 护栏策略 |
通过本课程的学习，你将掌握从“被动救火”到“主动审计”的范式转变，构建可量化、可自动化、可合规的 requests/limits 治理体系。