Envoy Gateway 与 Ingress NGINX 怎么选
结论先行
需要 Gateway API、多团队角色分离、Envoy 生态和现代流量治理，选 Envoy Gateway。已有大量 Ingress 注解、追求稳定和简单，继续用 Ingress NGINX。
Ingress NGINX 仍在维护，但 Gateway API 是更长期的方向；迁移要逐条验证注解语义。
核心差异
| 维度 |
Envoy Gateway |
Ingress NGINX |
| API |
Gateway API |
Ingress + 注解 |
| 数据面 |
Envoy |
NGINX |
| 角色分离 |
GatewayClass/Gateway/HTTPRoute |
较弱 |
| 流量治理 |
权重、Header、重写、限流 |
注解丰富但分散 |
| 生态 |
Envoy 生态、Wasm |
NGINX 模块和注解 |
| 学习曲线 |
Gateway API 新模型 |
Ingress 熟悉 |
| 多团队 |
原生支持 |
需要额外约束 |
| 适用场景 |
新平台、Gateway API |
现有 Ingress、稳定业务 |
怎么选
- 新集群、希望用 Gateway API：Envoy Gateway。
- 已有大量 Ingress 和 NGINX 注解：先保留 Ingress NGINX。
- 平台团队要给多团队提供统一入口：Envoy Gateway。
- 需要 Wasm、Envoy 过滤器：Envoy Gateway。
- 需要成熟的 NGINX 模块和社区经验：Ingress NGINX。
- 迁移成本敏感：先在低风险域名试点 Gateway API。
注意
- Ingress 注解和 Gateway API 策略不是一一对应，重写、限流、超时要逐项验证。
- TLS Secret 的命名空间和 ReferenceGrant 配置容易出错。
- 网关地址和 DNS TTL 要提前规划，便于回滚。
- 不要同时让两个控制器处理同一域名。
- 监控入口延迟、错误率和上游健康状态。
相关命令