Kubernetes 最初主要依赖 Ingress Controller（如社区的 NGINX Ingress）暴露 HTTP 服务。近年随着微服务与多协议需求增加，业界推动采用 Gateway API 作为下一代标准，将流量网关演进为可管理 L4/L7 多协议流量的控制面。本文对比几种支持 Gateway API 的代表性网关：NGINX Ingress、Kong Gateway、Apache APISIX、Envoy Gateway，从网关 API 支持、性能、启动部署、安全、可观测性、社区活跃度等维度展开分析。
Gateway API 支持情况
- NGINX Ingress Controller： 传统基于 Ingress API 实现。针对 Gateway API，NGINX 官方推出了 NGINX Gateway Fabric 项目（GA）来支持核心 Gateway API 功能；社区版 ingress-nginx 本身主要仍用旧有 Ingress 资源。
- Kong Gateway（通过 KIC/Gateway Operator）：Kong Gateway 本身是高性能 API 网关，通过官方控制器如 Kong Ingress Controller (KIC) 或 Gateway Operator 实现对 Kubernetes Gateway API 的支持。控制器负责监听 Gateway/Route 等资源，并将配置同步至 Kong Gateway（数据面），支持多协议（HTTP/gRPC/TCP/UDP）流量管理。
- Apache APISIX： APISIX 以 API Gateway 为定位，支持自定义 CRD（例如 APISIXRoute）；针对 Gateway API，目前正通过提案（AEP-0001）开发 v1alpha2 支持，尚处于早期阶段。未来 APISIX Ingress Controller 将支持 Gateway、跨集群等扩展功能。
- Envoy Gateway (EG)： 原生基于 Gateway API 设计，使用 Gateway/HTTPRoute 等资源动态配置托管的 Envoy 代理。Envoy Gateway 将 Envoy 作为数据平面，充分实现了 Gateway API 所有核心功能。
| 网关 | Gateway API 支持 | 扩展能力/插件 |
|---|---|---|
| NGINX Ingress Controller | 传统 Ingress API；NGINX Gateway Fabric (GA) 支持核心 Gateway API | 通过 NGINX 模板、Snippet 等自定义配置；支持 WAF、Lua 等扩展 |
| Kong Gateway (KIC/Gateway OP) | 原生支持 Gateway API（继承 Ingress API） | 内置丰富插件（认证、限流、转码等）；可用 Kong 插件开发环境动态扩展 |
| Apache APISIX | 传统 APISIXRoute 等；正在开发 Gateway API 支持（v1alpha2） | 丰富插件系统（认证、限流、QoS、Websocket、gRPC 等）；易于添加自定义插件 |
| Envoy Gateway (EG) | 完全实现 Gateway API | 利用 Envoy 强大扩展：TLS、Wasm、外部认证等；支持 Gateway API 扩展 CRD（如 SecurityPolicy） |
性能（QPS、延迟、资源消耗）
综合社区测试和官方基准：
- Apache APISIX： 性能突出。API7（APISIX 背后团队）测试表明，APISIX 在无插件场景下可达约 16-17 万 QPS（95% 延迟 2.3ms）；启用插件后（限流、认证等），仍能保持 13-14 万 QPS 左右。与 Kong 相比，APISIX 在相同场景下吞吐约为 Kong 的 1.4–2 倍；例如在 1 条路由 + 限流测试中，APISIX 平均 QPS≈13787，Kong≈9840（APISIX 140%）；添加认证插件后，APISIX 8933 QPS，Kong 3977 QPS（近 2.2 倍）。
- Kong Gateway： Kong 官方文档公布的基准显示，单实例 Kong 在简单代理场景下可稳定 12.4–12.7 万 RPS（P99 7-10ms），即使加了限流/认证插件，吞吐也可达 9.1–9.7 万 RPS。实际性能与 APISIX 相比略低。John Howard 的 Gateway API Bench 中，Kong Ingress（KIC）在简单场景下也能达到 3.7 万 QPS（单连接测试），但在大规模规则更新时性能有所下降。
- NGINX Ingress： 性能相对较弱。John 的测试发现，在流量测试中 NGINX Ingress 的性能远低于其他实现（约为平均水平的 1/5-1/20）。阿里云社区测试也观察到，在 CPU 利用率上升到较高水平时，NGINX Ingress 吞吐大幅下降，有时还会发生 Pod 重启导致吞吐骤降。其原因之一是控制面（Go）和数据面（Nginx）运行在同一容器内，高负载时会互相争用资源。
- Envoy Gateway： 性能与 Envoy 数据面能力直接相关。John 的基准显示 Envoy Gateway 在多数测试中表现与 Istio/Cilium 接近（均为 Envoy）的最佳水平；其单连接 QPS 3.45 万，16 连接时可突破 13 万 QPS。由于 Envoy 的高效架构，Envoy Gateway 能够在高并发和多路由场景下保持稳定，且常见瓶颈为单核。总体而言，基于 Envoy 的实现在高性能和可扩展性上具有显著优势。
启动时间与部署复杂度
John Howard 的 Gateway API Bench 提供了启动时间比较：在单实例简单部署情况下，Kong Ingress Controller 启动非常快（约 1s），Envoy Gateway 约需 10–23s，NGINX Ingress 约 17–29s。同时部署多个 Gateway 时，Envoy Gateway 的并行启动也明显快于 NGINX（Envoy ~10s，NGINX ~17s）。可见：
- Kong/IngressController 启动轻量（采用单容器控制面 + 数据面或 KIC 单纯控制面）。
- Envoy Gateway 需要初始化 CRD 对象、Envoy 配置等，启动稍慢。
- NGINX Ingress 混合了控制平面和 NGINX 数据平面，容器体积大、启动相对慢且可能因初始化过多组件而较复杂。
部署复杂性上，各项目均提供 Helm Chart 或 Operator：Kong 和 Envoy Gateway 都有专门的 Operator/Chart 引导安装，APISIX 和 ingress-nginx 也可通过常规 Helm 或清单部署。总体来看，Kong 和 ingress-nginx 的部署相对成熟简便，Envoy Gateway 和 APISIX 随产品成熟度不同，配置细节稍多一些。
安全能力（mTLS、认证授权）
- TLS/双向认证 (mTLS)： 所有网关都支持标准的 TLS 终止。NGINX Ingress 可通过 Ingress 注解启用客户端证书验证（mTLS）；Kong Gateway 和 APISIX 都提供了 mTLS 插件 或配置方式以验证客户端证书；Envoy Gateway 利用 Envoy 的原生功能支持客户端证书，以及 Gateway API 的
BackendTLSPolicy来配置上游 TLS。 - 认证授权： Kong 和 APISIX 提供了丰富的认证授权插件，例如 JWT、Key-Auth、OAuth2 等，且支持自定义 Lua/WASM 扩展，可实现细粒度的访问控制。NGINX Ingress 主要依赖 NGINX 内建或第三方模块（如 basic auth、JWT 验证脚本等）。Envoy Gateway 通过 SecurityPolicy 扩展（CRD）集成了外部认证服务和策略配置，并支持 Envoy Proxy 的内置功能（外部授权、JWT 验证、IP 白名单等）。
- 其他安全特性： 部分网关（如 Kong Enterprise、NGINX Plus）还提供高级安全功能（WAF、动态 IDP 集成等）。总的来看，这四种开源网关都能够满足常见的加密传输和认证需求，其中 Kong、APISIX 插件生态最为丰富，而 Envoy Gateway 借助 Envoy 实现了高度灵活的安全扩展。
可观测性（指标、日志、Tracing）
- 指标 (Metrics)： NGINX Ingress 可输出 Prometheus 格式的指标（包含 NGINX 核心和 Ingress 控制器自身指标）。Kong Gateway 提供内置的 Prometheus 指标支持和/或通过插件导出指标；APISIX 通过 Metrics 插件输出 Prometheus 格式数据，并可对接专用监控面板。Envoy Gateway 则直接使用 Envoy 的统计指标（通过 Gateway API Exported Metrics 导出），并内置对 OpenTelemetry/Prometheus 的支持，用户可自动收集到下游应用延迟、吞吐等指标。
- 日志（日志采集）： 所有网关均记录访问日志和错误日志。Kong/APISIX 支持将日志送往多种后端（文件、Syslog、Elasticsearch 等），Envoy Gateway 则利用 Envoy 的访问日志机制，可以配置格式和目标（文件、gRPC 推送等）。
- Tracing/分布式追踪： Kong 和 APISIX 均支持通过插件注入 OpenTracing/OpenTelemetry 报头，以配合 Jaeger/Zipkin 等链路追踪系统。Envoy Gateway 支持通过其配置机制启用 Envoy 原生链路追踪功能。
- 可视化集成： 这些项目通常提供与 Grafana+Prometheus 的集成示例（如 ingress-nginx 的 Grafana 仪表盘），也可结合云监控系统使用。Envoy Gateway 官方文档专门列出了 Gateway API 指标和访问日志等内容，方便用户快速配置监控。总之，各网关在可观测性方面都提供了丰富支持，部分项目在标准化配置与默认集成方面更具优势。
社区活跃度（GitHub 指标对比）
根据最新 GitHub 数据，各项目代码仓库活跃度如下：
- kubernetes/ingress-nginx（NGINX Ingress）：约 18.7k 星标，约 348 个开放 Issue，累积提交 8,098 次。
- apache/apisix（Apache APISIX）：约 15.3k 星标，285 个 Issue，4,486 次提交。
- Kong/kubernetes-ingress-controller（Kong Ingress Controller）：约 2.3k 星标，231 个 Issue，5,350 次提交。
- envoyproxy/gateway（Envoy Gateway）：约 2.0k 星标，401 个 Issue，3,343 次提交。
| 项目 | GitHub Stars | Open Issues | Commits | 备注 |
|---|---|---|---|---|
| NGINX Ingress (k8s 仓库) | 18.7k | 348 | 8,098 | 社区项目 |
| Apache APISIX | 15.3k | 271 | 4,494 | Apache 项目 |
| Kong Ingress Controller | 2.3k | 231 | 5,350 | Kong 官方维护 |
| Envoy Gateway (EG) | 2.0k | 401 | 3,343 | Envoy 官方项目 |
选型建议
根据以上分析，以下是针对不同使用场景的选型建议：
🚀 高性能场景
推荐：Apache APISIX 或 Envoy Gateway
- Apache APISIX：在需要极致性能的 API 网关场景，APISIX 表现最佳（16-17 万 QPS），插件丰富且性能损耗较小
- Envoy Gateway：适合需要 Gateway API 标准化且对性能有较高要求的场景，基于 Envoy 的架构保证了高并发稳定性
🏢 企业级生产环境
推荐：Kong Gateway
- 成熟的商业化产品，企业版提供完整的安全、监控、支持服务
- 丰富的插件生态和良好的扩展性
- 快速启动（~1s）和相对简单的部署流程
- 适合需要专业技术支持的大型企业
🔄 从 Ingress 迁移
推荐：NGINX Gateway Fabric
- 对于已使用 NGINX Ingress 的团队，NGINX Gateway Fabric 提供了平滑的 Gateway API 迁移路径
- 熟悉的 NGINX 配置方式和运维经验可以复用
- 但需要注意性能瓶颈，适合中小规模应用
🔮 未来标准化需求
推荐：Envoy Gateway
- 完全基于 Gateway API 设计，最符合 Kubernetes 未来标准
- 利用 Envoy 的强大扩展能力和 CNCF 生态
- 适合希望跟进最新技术标准的团队
💡 快速原型和中小项目
推荐：Apache APISIX
- 相对轻量的部署和配置
- 性能优异，能以较少资源支撑较大流量
- 活跃的开源社区和中文文档支持
📋 选型决策矩阵
| 优先级 | NGINX Ingress | Kong Gateway | Apache APISIX | Envoy Gateway |
|---|---|---|---|---|
| 高性能需求 | ❌ 不推荐 | ✅ 推荐 | ⭐ 强烈推荐 | ✅ 推荐 |
| Gateway API | ⚠️ 需额外产品 | ✅ 支持 | ⚠️ 开发中 | ⭐ 原生支持 |
| 企业级支持 | ✅ 社区成熟 | ⭐ 商业支持 | ✅ Apache 项目 | ✅ CNCF 项目 |
| 部署简易性 | ⚠️ 较复杂 | ✅ 简单 | ✅ 简单 | ⚠️ 配置较多 |
| 插件生态 | ⚠️ 有限 | ⭐ 丰富 | ⭐ 丰富 | ✅ 基于 Envoy |
| 社区活跃度 | ⭐ 最高 | ✅ 活跃 | ⭐ 很高 | ✅ 快速发展 |
总体建议：
- 追求性能优先选择 Apache APISIX
- 企业级应用选择 Kong Gateway
- 标准化需求选择 Envoy Gateway
- 现有 NGINX 用户可考虑 NGINX Gateway Fabric 作为过渡方案
结论
Kubernetes 流量网关正从早期的单协议 Ingress（以 NGINX 为代表）演进到支持多协议、可扩展的现代 Gateway API 解决方案。新一代网关（如 Kong、APISIX、Envoy Gateway）更注重性能优化、协议覆盖、认证插件和标准 API 的支持。随着 Gateway API 的普及和项目生态的完善，未来云原生流量网关将更加强调多协议支持、自动化控制面、内置安全和可观测性。