gateway

Envoy Gateway：把 Envoy 从"手写 xDS"里解放出来

项目背景与痛点

Envoy 早已是云原生数据面的事实标准，但它的配置模型是给机器看的，不是给人看的。LDS、RDS、CDS、EDS 四层 xDS 叠加 filter chain、cluster、listener 的各种细节，"我想暴露一个 HTTPS 路由"这件事，在 Envoy 里要展开成几百行结构化配置。于是每个想拿 Envoy 当入口网关的团队，最后都不得不自己写一个控制面，把业务意图翻译成 xDS。

这直接导致了网关语义的碎片化：各家 Ingress 控制器各写各的注解，Istio 有自己的 Gateway/VirtualService，云厂商再叠一层私有 CRD。Gateway API（SIG Network）就是冲着这个来的：用角色化的 CRD（GatewayClass / Gateway / HTTPRoute）把"基础设施提供者、集群运维、应用开发者"的职责切开。Envoy Gateway 是最早的参考实现之一，如今已进入 CNCF。

它的定位很克制——不造数据面、不做服务网格，只做一件事：把 Gateway API 声明的意图，可靠地翻译成 Envoy 能吃的 xDS。

核心技术揭秘

Envoy Gateway 的控制面可以拆成三层：Provider、Translation、Infra。这个分层是它最重要的架构决策。

Provider 抽象层负责"从哪里拿配置"。Kubernetes 模式下 watch API Server；File 模式下直接读本地 YAML 文件。正因为这层抽象，Envoy Gateway 才敢宣称自己是 standalone 的——同一套翻译逻辑，既能跑在集群里，也能跑在裸机、VM 或边缘节点上。

Translation 层是核心。它没有把 Gateway API 对象直接映射成 xDS，而是先归一化成一个内部 IR（中间表示），再从 IR 渲染 xDS 资源。这层 IR 的价值在于：多个输入源（Gateway、Route 加上各类 Policy）可以先合并、按 targetRef 优先级排序、做冲突消解，最后一次性产出一份一致的 xDS 快照。中间态的缺失是很多网关控制面的通病，会造成配置"半更新"。

Infra 管理器决定了数据面的拓扑：每个 Gateway 对应一套独立的 Envoy 部署（Deployment、Service、HPA、PDB）。控制面只管控制，流量一个包都不碰。

xDS 的下发走 go-control-plane 的 snapshot 机制，用版本号保证数据面看到的是完整一致的一份配置，而不是几条互相矛盾的增量更新。

扩展能力用的是 Policy Attachment 模型：BackendTrafficPolicy、ClientTrafficPolicy、SecurityPolicy、EnvoyExtensionPolicy 通过 targetRef 挂到 Gateway、Listener 或 Route 上，而不是往核心 Route 里塞字段。这让核心 API 保持干净，新能力可以独立演进。另有一层 EnvoyPatchPolicy，允许直接 patch 生成的 xDS JSON——这是逃生舱，能力上限极高，代价是你把自己的配置和 Envoy 内部结构绑死了。

功能亮点与差异

• 原生 Gateway API，没有自创方言，路由语义跟规范走，迁移成本低。
• 一 Gateway 一数据面。多租户场景下故障域天然隔离：A 团队的网关崩了，不影响 B 团队。
• Standalone 模式。这是它区别于多数同类的关键——脱离 Kubernetes 也能当应用网关用。
• 纯 Envoy 数据面，不自研代理，Wasm、JWT/OIDC、限流这些生态能力直接继承。

横向对比：Istio 覆盖南北向 + 东西向，能力更全但心智负担重；Contour 同样基于 Envoy 与 Gateway API，但策略体系不如 EG 完整；Ingress NGINX 正在进入退役周期，Envoy 的并发模型和热更新能力本来就更占优。

应用场景与落地建议

适合：K8s 集群的统一南北向入口、多团队多租户的网关隔离、需要 Envoy 生态能力（Wasm 插件、全局限流、OIDC）的入口层，以及边缘/非 K8s 环境的 standalone 部署。

落地时要注意几点：

1. Pod 数量会膨胀。每个 Gateway 一套 Envoy 部署，集群里网关多了就是一堆小 Deployment。务必配好 HPA、PDB 和资源 request/limit。
2. EnvoyPatchPolicy 慎用。它能解决 90% 的"官方还没支持"的诉求，但每次升级 Envoy 或 EG 都要重新验证 patch 是否仍然成立。
3. 全局限流依赖外部 ratelimit 服务，不是开箱即用，网络链路要提前规划。
4. 控制面高可用靠 leader election，同时确认数据面在 xDS 断连时保持 last-known-good 配置，避免控制面抖动直接打穿流量。
5. CRD 版本对齐。Gateway API 的版本演进较快，EG 版本与 CRD 版本要严格匹配。

综合评价

优点：分层清晰、语义干净、扩展模型设计得体、纯 Envoy 带来的生态红利明显，社区节奏稳定，是 Gateway API 落地最省心的选项之一。

缺点：大量策略 API 仍在 v1alpha1，接口有变动风险；一 Gateway 一数据面的模型在超大规模下资源开销可观；EnvoyPatchPolicy 是双刃剑，用得好是护城河，用不好就是升级地狱；文档对 xDS 内部细节覆盖偏浅，排障时仍需 Envoy 功底。

一句话总结：它不试图解决所有问题，只把"Envoy 当网关"这一件事做扎实了。对绝大多数需要标准化入口层的团队来说，这恰恰是最需要的克制。