4. Envoy 网关基础：架构与动态配置机制
Envoy 是 CNCF 毕业的高性能七层代理，也是 Istio、Ambassador、Gloo 等主流服务网格和 API 网关的数据面核心。理解 Envoy 的架构组件、xDS 协议以及动态配置更新机制，是进行 GitOps 交付资源校准和网关故障排查的前提。
4.1 Envoy 核心架构组件
Envoy 的架构围绕四个核心抽象构建：Listener（监听器）、Cluster（集群）、Route（路由）和 Filter（过滤器）。它们共同定义了流量如何进入、处理并转发到后端。
4.1.1 Listener（监听器）
Listener 定义了 Envoy 在哪个 IP 和端口上监听入站流量。每个 Listener 可以绑定一个或多个 Filter Chain，用于处理不同协议或 TLS 场景的流量。
- 核心属性：地址（address）、端口（port）、协议（TCP/UDP）、TLS 上下文。
- 典型场景：一个 Envoy 实例可以同时监听 80（HTTP）和 443（HTTPS）两个 Listener。
4.1.2 Cluster（集群）
Cluster 定义了 Envoy 将流量转发到的后端服务组。它包含连接池、负载均衡策略、健康检查、断路器等配置。
| 集群类型 | 说明 | 典型用途 |
|---|---|---|
| STRICT_DNS | 通过 DNS 解析获取端点，周期性刷新 | Kubernetes Headless Service |
| LOGICAL_DNS | 仅解析一次，使用单个 IP 连接 | 外部 API 网关 |
| STATIC | 静态配置端点列表 | 测试或固定后端 |
| EDS | 通过 xDS 动态获取端点 | 服务网格、大规模动态环境 |
4.1.3 Route（路由）
Route 定义了请求匹配规则（域名、路径、Header、Query 参数）以及匹配后转发到的目标 Cluster。路由配置通过 RDS（Route Discovery Service） 动态下发。
4.1.4 Filter（过滤器）
Filter 是 Envoy 处理请求/响应的插件化单元，分为 L4（网络层）和 L7（HTTP 层）两类。多个 Filter 串联形成 Filter Chain，按顺序执行。
- L4 Filter：TCP Proxy、TLS Inspector、Original Destination。
- L7 Filter：HTTP Connection Manager（HCM）、Router、RBAC、Rate Limit、CORS、gRPC-Web。
4.2 xDS 协议：控制面与数据面的通信桥梁
xDS 是 Envoy 与控制面之间的一组发现服务协议。控制面通过 xDS 将配置动态推送给 Envoy 实例，实现无需重启的配置更新。xDS 是 GitOps 交付中“声明式配置 → 运行时生效”的关键技术基础。
4.2.1 主要 xDS 协议
| 协议 | 全称 | 资源内容 | 更新触发场景 |
|---|---|---|---|
| LDS | Listener Discovery Service | 监听器地址、端口、Filter Chain | 新增/删除网关端口 |
| RDS | Route Discovery Service | 域名、路径匹配规则、目标集群 | 修改路由规则、灰度发布 |
| CDS | Cluster Discovery Service | 集群名称、连接池、负载均衡策略 | 新增/删除后端服务 |
| EDS | Endpoint Discovery Service | 后端实例 IP:Port、权重、健康状态 | Pod 扩缩容、滚动更新 |
| SDS | Secret Discovery Service | TLS 证书、私钥 | 证书轮换 |
4.2.2 SOTW 与 Delta 推送模式
- SOTW（State of the World）：全量推送。每次更新时，控制面将当前所有相关资源一次性发送给 Envoy。简单可靠，但大规模集群下网络开销大。
- Delta（增量推送）：仅推送变更部分。Envoy 本地维护资源版本，控制面只发送新增、修改或删除的资源。节省带宽，适合大规模动态环境。
4.3 动态配置更新机制
Envoy 的动态配置更新机制使其能够在不停机的情况下完成配置变更，这是实现 GitOps 持续交付的核心能力。更新流程遵循严格的依赖顺序和版本校验。
4.3.1 更新依赖顺序
控制面推送配置时，必须按照 LDS → RDS → CDS → EDS 的顺序进行。Envoy 在收到 LDS 更新后，才会请求新的 RDS；收到 CDS 后，才会请求对应的 EDS。这种依赖关系保证了配置的一致性。
4.3.2 热加载与优雅关闭
Envoy 通过 热重启（Hot Restart） 机制实现配置更新。新进程启动并接管监听 socket，旧进程继续处理已有连接直到超时或完成，然后优雅退出。在 xDS 模式下，热重启不再是必需，因为 xDS 支持原地更新。
- 原地更新（In-Place Update）：Envoy 在同一个进程中直接应用新配置，Worker 线程重新加载 Filter Chain 和路由表。
- 连接迁移：对于 TCP 连接，Envoy 支持连接级别的优雅迁移，确保长连接业务不受影响。
4.3.3 配置版本与 ACK/NACK
每次 xDS 推送都携带一个 版本号（version_info）。Envoy 成功应用配置后，会返回 ACK（确认）响应，包含当前版本号。如果配置校验失败（如路由规则语法错误、集群不存在），Envoy 返回 NACK（拒绝）响应，并附带错误信息。
4.3.4 配置更新流程示例
1. 开发者修改 Git 仓库中的 Gateway API 资源（如 HTTPRoute）。
2. GitOps Operator 检测到变更，同步到 Kubernetes 集群。
3. 控制面（如 Istiod）监听到资源变化，生成新的 xDS 配置。
4. 控制面通过 gRPC 流推送 LDS 更新（新增/修改 Listener）。
5. Envoy 收到 LDS，校验通过后返回 ACK，并请求新的 RDS。
6. 控制面推送 RDS 更新（修改路由规则）。
7. Envoy 应用新路由，开始将流量导向新版本后端。
8. 控制面推送 CDS/EDS 更新（新版本 Pod 的端点）。
9. Envoy 更新连接池，新请求使用新端点，旧连接优雅关闭。