对比分析 NGINX Ingress、Kong Gateway、Apache APISIX、Envoy Gateway 等支持 Gateway API 的主流 Kubernetes 网关，从性能、安全、可观测性、社区活跃度等多个维度深入解读。
阅读原文请转到：https://jimmysong.io/blog/kubernetes-gateway-api-comparison/
Kubernetes 最初主要依赖 Ingress Controller（如社区的 NGINX Ingress）暴露 HTTP 服务。近年随着微服务与多协议需求增加，业界推动采用 Gateway API[1] 作为下一代标准，将流量网关演进为可管理 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[2] 项目（GA）来支持核心 Gateway API 功能；社区版 ingress-nginx 本身主要仍用旧有 Ingress 资源。
• Kong Gateway（通过 KIC/Gateway Operator）：Kong Gateway[3] 本身是高性能 API 网关，通过官方控制器如 Kong Ingress Controller (KIC)[4] 或 Gateway Operator[5] 实现对 Kubernetes Gateway API 的支持。控制器负责监听 Gateway/Route 等资源，并将配置同步至 Kong Gateway（数据面），支持多协议（HTTP/gRPC/TCP/UDP）流量管理。
• Apache APISIX： APISIX 以 API Gateway 为定位，支持自定义 CRD（例如 APISIXRoute）；针对 Gateway API，目前正通过提案（AEP-0001[6]）开发 v1alpha2 支持，尚处于早期阶段。未来 APISIX Ingress Controller 将支持 Gateway、跨集群等扩展功能。
• Envoy Gateway (EG)： 原生基于 Gateway API 设计，使用 Gateway/HTTPRoute 等资源动态配置托管的 Envoy 代理。Envoy Gateway[7] 将 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[8] 中，Kong Ingress（KIC）在简单场景下也能达到 3.7 万 QPS（单连接测试），但在大规模规则更新时性能有所下降。
• NGINX Ingress： 性能相对较弱。John 的测试发现，在流量测试中 NGINX Ingress 的性能远低于其他实现（约为平均水平的 1/5-1/20）。阿里云社区测试[9]也观察到，在 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[10] 来配置上游 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 的普及和项目生态的完善，未来云原生流量网关将更加强调多协议支持、自动化控制面、内置安全和可观测性。
引用链接
[1] Gateway API:https://github.com/kubernetes-sigs/gateway-api/blob/main/site-src/implementations.md[2]NGINX Gateway Fabric:https://github.com/nginx/nginx-gateway-fabric[3]Kong Gateway:https://github.com/Kong/kong[4]Kong Ingress Controller (KIC):https://github.com/Kong/kubernetes-ingress-controller[5]Gateway Operator:https://github.com/Kong/gateway-operator[6]AEP-0001:https://apisix.apache.org/docs/ingress-controller/aeps/gateway-api/[7]Envoy Gateway:https://gateway.envoyproxy.io/[8]Gateway API Bench:https://github.com/howardjohn/gateway-api-bench[9]阿里云社区测试:https://www.alibabacloud.com/blog/kubernetes-gateway-selection-nginx-or-envoy_599485[10]`BackendTLSPolicy`:https://gateway.envoyproxy.io/docs/api/gateway_api/backendtlspolicy/