1. 课程导论：网关Pod异常检测与自愈的背景、目标与整体架构概览
1.1 为什么需要网关Pod异常检测与自愈？
在云原生微服务架构中，API网关（如Kong、APISIX、Nginx Ingress Controller、Envoy Gateway）是所有外部流量的统一入口。网关Pod的健康状况直接决定了整个系统的可用性与吞吐能力。然而，生产环境中网关Pod面临多种异常风险：
- 流量突增导致OOM：突发流量峰值使Pod内存耗尽，触发OOMKill。
- 连接池耗尽：后端服务响应变慢，网关连接数打满，新请求被拒绝。
- 配置热重载失败：路由规则或插件更新导致进程卡死或崩溃。
- 慢启动与冷缓存：新扩出的Pod因缓存未预热，请求延迟飙升。
- 节点资源争抢：宿主机CPU/IO争抢导致网关Pod响应超时。
核心痛点：传统基于Kubernetes Liveness/Readiness探针的检测方式存在“探针盲区”——探针只能检测进程是否存活，无法感知网关内部的连接池状态、延迟劣化、配置一致性等业务级健康指标。
1.2 课程目标
本课程旨在构建一套基于Prometheus监控数据驱动的网关Pod异常检测与自愈体系，实现以下目标：
| 目标维度 | 具体描述 | 关键指标示例 |
|---|---|---|
| 实时检测 | 利用Prometheus指标（延迟、错误率、连接数、内存）在秒级发现异常 | p99延迟 > 500ms、5xx比例 > 1% |
| 精准定位 | 区分“Pod自身故障”与“后端服务故障”，避免误杀 | 连接池使用率 > 90% 且 后端延迟正常 |
| 自动自愈 | 通过Kubernetes API执行Pod优雅驱逐、滚动重启、弹性扩缩容 | 自愈成功率 > 95%，MTTR < 3分钟 |
| 可观测闭环 | 自愈动作自动记录为Prometheus事件，形成检测→决策→执行→反馈的闭环 | 自愈触发次数、自愈耗时、自愈后指标恢复曲线 |
1.3 整体架构概览
本课程设计的整体架构采用“数据采集 → 异常检测 → 决策引擎 → 自愈执行 → 反馈闭环”五层模型。下图展示了核心组件与数据流关系：
1.4 核心设计原则
本课程架构遵循以下设计原则，确保方案在生产环境中的健壮性与可维护性：
- 监控驱动：所有检测与自愈决策均基于Prometheus指标，不依赖外部黑盒探测。
- 分级自愈：根据异常严重程度执行不同策略（轻则重启Pod，重则驱逐并扩容）。
- 防抖与抑制：自愈动作触发后设置冷却期（Cooldown），避免频繁操作导致集群震荡。
- 可观测优先：每次自愈动作都记录为Prometheus事件，支持事后审计与SLA分析。
- 渐进式交付：从单一网关（如Kong）开始，逐步扩展到多网关类型。
1.5 课程知识体系与章节映射
下表展示了本课程30章内容如何映射到上述五层架构：
| 架构层 | 对应章节 | 核心内容 |
|---|---|---|
| ① 数据采集 | 第2-5章 | Prometheus部署、网关指标暴露、ServiceMonitor配置、指标质量优化 |
| ② 异常检测 | 第6-12章 | PromQL告警规则编写、基线算法、异常分类、误报抑制 |
| ③ 决策引擎 | 第13-18章 | Alertmanager路由、Webhook开发、决策树设计、策略编排 |
| ④ 自愈执行 | 第19-24章 | Kubernetes API调用、Pod优雅驱逐、滚动重启、HPA联动 |
| ⑤ 反馈闭环 | 第25-28章 | 自愈事件埋点、Grafana仪表盘、SLA监控、告警降噪 |
| 综合实战 | 第29-30章 | 端到端部署演练、混沌工程验证、故障复盘 |
学习建议：建议按照章节顺序学习，但如果你已有Prometheus基础，可以直接从第6章（异常检测）开始。每章末尾的“动手实验”环节是掌握自愈能力的关键，请务必在测试环境中完成。