如果你正在为一个长期维护的 Kubernetes 项目替换 ingress-nginx，最先要回答两个问题：以后用什么 API 描述入口规则，以及由哪个项目执行这些规则。
我的选型建议是：新建入口优先评估 Gateway API；普通应用入口先试 Traefik；需要 API 认证、消费者管理和配额时重点比较 APISIX 与 Kong；已有 Istio，或者明确需要服务网格时，把 Istio 放到前面。 这些是根据功能定位与维护成本作出的条件性建议，实际结果还要由项目的配置和流量验证。
你觉得 Ingress 和 Gateway API 都在解决"把外部请求转给服务"，这个直觉是对的。理解 Gateway API 的价值，需要继续看：当入口被多个团队共享、规则越来越多时，谁有权改什么，哪些能力能够用标准字段表达，以及换一个实现需要改多少配置。
本文资料核查于 2026 年 10 月 5 日。比较以开源项目为基础，涉及商业产品时单独说明；未对四个项目进行统一环境压测，文中的配置是机制示例。
先说清楚：退役的是哪个 NGINX Ingress
社区项目 kubernetes/ingress-nginx 已于 2026 年 3 月 24 日归档 。官方退役公告说明，2026 年 3 月后不再提供新版本、缺陷修复和安全补丁；已经部署的实例仍能运行，已有镜像和 Helm Chart 仍然可用。Kubernetes 退役公告
这件事和 Kubernetes 的 Ingress API 是两个层面的变化。Ingress API 已冻结，不再增加功能，但仍是稳定 API，Kubernetes 官方没有移除它的计划。Ingress 官方文档
另外，社区的 ingress-nginx 与 F5 的 NGINX Ingress Controller 是不同项目。不能把前者的退役理解成"所有基于 NGINX 的入口方案都退役"。Kubernetes 官方声明
因此，你可以先换成仍维护的 Ingress Controller，再逐步迁移 Gateway API。对维护中的系统，这种分阶段路线有时比同时更换代理、路由 API 和认证逻辑更容易验证。
Ingress 与 Gateway API：数据路径相似，配置组织不同
API 描述规则，控制器落实规则
Ingress 是 Kubernetes 内置的资源；Gateway API 是由 Kubernetes SIG Network 推进的一组服务网络 API，通常通过 CRD 安装到集群中。安装 CRD 只让 API Server 能保存和校验这些对象，还需要兼容的控制器及其数据面来提供入口。Gateway API 项目介绍、Istio 安装说明
控制器观察 Kubernetes 对象，把规则翻译成代理配置；代理接收真实请求，匹配路由并转发。控制器和代理在不同项目里可能分别部署，也可能集成在同一个程序中。
看下面图中上半部的灰色配置链，再看下半部的蓝色流量链。业务请求经过代理；Ingress、Gateway 和 HTTPRoute 都参与配置，不是请求逐个经过的网络节点。
在数据面上，两种 API 都可能得到相近的结果：客户端经过入口代理，访问后端应用。Gateway API 并不保证更快，也不必然增加一层网络代理。
Ingress 很适合表达简单入口
假设我们要把 api.example.com/orders 转到 orders Service。下面是一个简化的 Ingress，假定 public IngressClass 和对应控制器已经存在，Service 在 app 命名空间中，80 是它的 Service 端口：
yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: orders
namespace: app
spec:
ingressClassName: public
rules:
- host: api.example.com
http:
paths:
- path: /orders
pathType: Prefix
backend:
service:
name: orders
port:
number: 80这份配置容易读。问题通常出现在需求增加之后：按请求头选择后端、给新版本分流、配置认证、调节超时。Ingress 标准没有覆盖所有这些能力，实现便通过注解或自己的 CRD 扩展。
同一份 YAML 上的 nginx.ingress.kubernetes.io/* 注解，换到其他控制器后未必生效。基础的域名和路径规则可迁移，注解的语义却可能需要重写。
Gateway API 把共享入口的职责拆开
Gateway API 的核心资源可以按职责理解：
| 资源 | 表达什么 | 常见维护者 |
|---|---|---|
| GatewayClass | 一类网关由哪个控制器实现，使用什么基础配置 | 集群管理员 |
| Gateway | 具体入口的监听器、端口、协议、TLS 与路由接入范围 | 平台或网络团队 |
| HTTPRoute / GRPCRoute 等 | 请求如何匹配、处理并转给后端 | 应用团队 |
这是 API 设计提供的分工方式。要真正限制修改权限，还需要对应的 Kubernetes RBAC 和必要的准入策略。Gateway API 角色设计
观察下面图中的两块命名空间边界：平台持有 Gateway，应用持有 HTTPRoute。应用用 parentRefs 请求接入，平台用监听器的 allowedRoutes 决定是否接纳；共享一个入口，不要求应用拥有修改监听器的权限。
我们把前面的例子扩展为"公共网关 + 应用路由 + 90/10 分流"。下面假定 infra、app 命名空间和后端 Service 已存在，名为 public 的 GatewayClass 已由管理员配置，并且实现支持这里使用的字段。为突出结构，示例只使用 HTTP；生产 HTTPS 还需 TLS 监听器与证书。
yaml
# 平台团队：监听器只接纳 app 命名空间的路由
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: public
namespace: infra
spec:
gatewayClassName: public
listeners:
- name: http
hostname: api.example.com
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
kubernetes.io/metadata.name: app
---
# 应用团队：独立维护路由和分流权重
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: orders
namespace: app
spec:
parentRefs:
- name: public
namespace: infra
sectionName: http
hostnames:
- api.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /orders
backendRefs:
- name: orders-v1
port: 80
weight: 90
- name: orders-v2
port: 80
weight: 10Gateway API 用标准字段表达后端权重，不需要借助 NGINX 的 canary 注解。这里的 90/10 是相对权重所表达的目标分配；少量请求、长连接或会话策略下，观测比例不必刚好是 90% 和 10%。权重也不会自动完成发布门禁、指标判断和回滚，那些仍要由发布流程负责。流量分配指南
有一个容易混淆的授权细节：HTTPRoute 跨命名空间挂到 Gateway，使用 parentRefs 与 allowedRoutes；跨命名空间引用后端 Service，通常需要目标命名空间里的 ReferenceGrant。 两者解决的引用关系不同。本例的后端与路由都在 app，所以不需要为后端创建 ReferenceGrant。Gateway API 安全模型、ReferenceGrant 说明
新 API 带来的收益，也有边界
| 比较点 | Ingress | Gateway API |
|---|---|---|
| 基础目标 | HTTP/HTTPS 入口路由 | 覆盖入口及更广的服务网络场景 |
| 配置结构 | IngressClass 选择实现；单个 Ingress 聚合多类规则 | GatewayClass、Gateway、Route 分别承担职责 |
| 常用高级路由 | 常依赖注解或实现专属 CRD | 请求头匹配、后端权重等有标准表达 |
| 多团队共享 | 需要控制器功能与额外约束配合 | 原生提供路由接入与跨命名空间引用模型 |
| 可迁移范围 | 标准域名、路径规则相对容易迁移 | 标准资源可迁移范围更大，扩展仍依赖实现 |
| 维护工作 | 对象较少，但复杂配置容易藏在注解里 | 对象更多，需要管理 CRD、兼容版本和状态 |
Gateway API 还提供 HTTP、gRPC、TLS、TCP、UDP 等不同路由类型，但每种资源的发布通道、API 版本和实现支持范围都要分别检查。支持 HTTPRoute，不等于所有协议都支持；Gateway API 也通过 GAMMA 扩展到网格内的东西向流量场景。Gateway API 实现与流量类型
标准化仍有边界。例如，Traefik 可以用 ExtensionRef 引用自己的 Middleware。这种写法结构清楚，但换实现时仍要迁移 Middleware 的功能。Traefik Gateway API 扩展
因此，Gateway API 扩大了共同的配置语言；认证、限流和其他治理能力是否能迁移，仍取决于你用了哪些标准字段、策略资源和插件。
四个项目要按实际部署组合比较
用户列出的四个仓库，并不对应四套完全相同形态的 Kubernetes 控制器。尤其是 Kong 和 APISIX，其网关与 Kubernetes 控制器分别在不同仓库中维护。
| 候选组合 | 主要定位与数据面 | Kubernetes 配置入口 | 优先评估的场景 |
|---|---|---|---|
| Istio 控制面 + Envoy 入口代理 | 服务网格，也可只提供入口网关 | Kubernetes Ingress、Gateway API、Istio 自有 API | 已有 Istio，或需要统一入口与服务间治理 |
| Kong Gateway + KIC / Kong Operator | API 网关；基于 NGINX/OpenResty | Ingress、Gateway API、Kong CRD；取决于控制器组合 | API 消费者、插件治理、商业支持 |
| Traefik Proxy | Go 实现的应用代理与负载均衡器 | Ingress、Gateway API、IngressRoute 等 | 通用应用入口，以及 NGINX Ingress 迁移 |
| APISIX + APISIX Ingress Controller | API 网关；基于 NGINX/OpenResty，使用 Lua 插件 | Ingress、Gateway API、APISIX CRD；取决于版本 | 开源 API 治理、插件扩展 |
这些是各项目的功能定位；不是吞吐量或资源占用排名。技术栈与控制器拆分可参阅各仓库，以及 Istio 网关文档、Kong KIC 文档、APISIX 架构文档。
Traefik：把普通应用入口作为第一目标时，值得先试
Traefik 能从 Kubernetes 等配置来源动态生成路由，代理与配置发现通常由同一程序承担。对只需要域名、路径、TLS 和一些请求处理中间件的项目，这种部署形态便于作为初始候选。Traefik 项目说明
它同时提供 Kubernetes Ingress 与 Gateway API provider。Gateway API 文档说明其支持 HTTPRoute Core 功能，并提供具体一致性报告；超出标准范围的功能可通过自身 CRD 扩展。Gateway provider 文档
针对存量 ingress-nginx，Traefik 从 3.6.2 起提供专门的 Ingress NGINX provider，翻译已支持的 NGINX 注解。这让"先保留 Ingress 对象、更换执行者"成为可评估的过渡方案。不过，控制器 ConfigMap 的全局配置仍需要审计，注解兼容也要按支持清单逐项确认。官方迁移指南
我的判断是：如果维护团队主要想让应用稳定暴露到外部，Traefik 应当进入第一轮验证。若需求已经围绕 API 消费者、复杂认证和分布式配额展开，就把这些功能单独列出来，比较 Traefik Proxy、相关商业产品与外部组件的实际组合，不能仅凭"有中间件"判断需求已覆盖。
Kong：API 治理能力要连同产品版本一起选
Kong 的核心是 API 网关，Kubernetes 规则通常由 KIC（Kong Ingress Controller）翻译，或通过 Kong Operator 管理部署与配置。KIC 的 unmanaged 模式不会因为每个 Gateway 对象就自动创建独立数据面，同一个 KIC 管理的多个 Gateway 路由会合并到所管理的网关配置中。KIC Gateway 管理方式
Kong Operator 能管理网关部署，官方文档还明确建议将新功能路线重点放在 Operator 上，同时继续支持 KIC。其数据面采用 DB-less 模式，所以"选 Kong 就必须运维 PostgreSQL"并不准确。Kong Operator 文档
但选 Kong 时，必须写清楚评估的是哪个发行物。Kong/kong 仓库采用 Apache 2.0 许可证；截至本次核查，仓库发布页列出的最新 OSS release 是 3.9.3 。Enterprise 与 Konnect 的版本、功能和支持政策不能直接套到 OSS 上。仓库许可证、OSS 发布页
一个具体差异是：Kong 的官方 OpenID Connect 插件标注为 Enterprise only 。如果你的必需项是 OIDC 登录，采购或实现替代插件的成本就应当进入比较。OIDC 插件说明
我的判断是：如果项目需要成熟的 API 产品能力，愿意评估商业支持，或已经积累了 Kong 插件，Kong 很有竞争力。若目标是完全依靠免费 OSS 长期运行，则先确认网关版本、控制器兼容范围、必需插件与补丁渠道，再决定部署组合。
APISIX：开源 API 治理丰富，控制器能力要单独验收
APISIX 提供 JWT、OIDC、限流、请求处理等插件，适合把入口扩展为 API 治理层。其官方 OIDC 插件能够对接 OpenID Connect 身份提供方，因此与 Kong 官方 OIDC 插件的产品边界不同。APISIX 插件目录、OIDC 插件文档
传统部署通过 etcd 保存配置；Standalone 模式可以不使用独立 etcd。当前控制器安装指南给出了 Standalone API-driven 的部署方式，而架构页仍将 Standalone 标为 Experimental。选型时应记录所选网关、控制器和 Helm Chart 的确切版本，并验证重启后配置恢复、全量同步与故障行为。安装指南、控制器部署架构
APISIX 能实现一个功能，不代表它的控制器已经支持该功能对应的 Gateway API 字段。例如，本次查到的支持表将 Gateway 标为部分支持，HTTPRoute 扩展能力也为部分支持，BackendTLSPolicy 标为不支持；超时、重试等还需要查看替代策略与实际映射。Gateway API 支持表
我的判断是：如果认证、限流和插件扩展是当前需求，并希望优先使用开源能力，APISIX 值得重点验证。如果首要目标是尽量使用标准 Gateway API，减少实现专属资源，则先用支持矩阵筛选，再验证缺失字段对应用有什么影响。
Istio：已有网格时优先考虑，也可以只部署入口
Istio 使用控制面管理代理配置，入口网关的数据面使用 Envoy。它还能提供服务间身份、安全策略和流量治理；这些能力需要相应的网格部署，不能因为选了 Istio 入口就假定集群内通信已经获得保护。Istio 项目架构
Istio 支持以最小安装提供 Gateway API 入口，不要求给所有业务 Pod 注入 sidecar。默认情况下，它可以根据 Gateway 自动创建 Deployment 和 Service，也允许手动部署。Gateway API 实现列表、Istio Gateway 部署机制
因此，不能简单地用"只能上整套服务网格"排除 Istio。不过，即便只做入口，你仍需要理解 Istio 控制面、代理配置和升级过程。如果团队已经运维 Istio，这些是可复用的能力；如果只想暴露几个服务，就要评估新增的学习与维护成本。
还有一个名称陷阱：Istio 自有 API 中也有 Gateway，其 API group 是 networking.istio.io；Kubernetes Gateway API 的 Gateway 使用 gateway.networking.k8s.io。阅读示例或排查对象时，应当看完整 API group。Istio Gateway API 文档
我的判断是：已经使用 Istio，或者有明确的服务网格需求时，优先验证 Istio Gateway API。全新项目只做入口时也可以选它，但应该以网关模式评估，别把未来可能需要的整套能力都当成今天的收益。
"支持 Gateway API"需要核查到哪一层
四个候选都能找到 Gateway API 相关文档，但一个勾选框不足以指导上线。至少要区分三个层次：
- 资源能否被识别。 控制器是否观察 HTTPRoute，CRD 的版本是否匹配。
- 字段能否按规范执行。 你需要的匹配、过滤器、TLS、超时和权重分别是否支持。
- 该版本是否有一致性证据。 报告对应哪个实现版本、Gateway API 版本、Route 类型与 Profile。
官方一致性体系区分 Core 与可选的 Extended 能力。"Conformant"也不表示实现覆盖所有路由类型及所有扩展。核查时，官方实现列表列出了 Istio、Traefik Proxy 与 Kong Operator；APISIX 项目的功能支持表不能代替相同范围的一致性报告。未列入该列表也不足以推断它不能运行 Gateway API。实现列表与一致性定义
对维护者来说，比较单位最好写成：网关版本 + 控制器或 Operator 版本 + Gateway API CRD 版本 + Helm Chart + 使用的插件。 官方滚动文档可能更新，也可能存在页面间版本差异，最终验收应回到选定 release 的配置和测试。
针对维护中的项目，我会这样缩小范围
先按当前的主要需求选两套方案进入验证，不必同时部署四套：
| 当前最重要的需求 | 第一轮候选 | 决策时重点看 |
|---|---|---|
| 普通网站或内部应用入口，维护团队较小 | Traefik；需要对照时再选一个 Gateway 实现 | TLS、路径行为、日志与升级是否容易管理 |
| 开源认证、消费者限流、插件扩展 | APISIX 与 Kong OSS | 必需插件、配置恢复、兼容范围与补丁渠道 |
| API 管理平台与商业支持 | Kong；同时比较 APISIX 的实际产品组合 | 功能所属产品、支持边界与总成本 |
| 已经运维 Istio，或明确需要服务网格 | Istio；再与当前入口方案对照 | 入口与内部治理衔接、控制面及代理升级 |
| 大量 NGINX 注解，短期先降低迁移工作量 | Traefik 的 NGINX 兼容 provider | 已支持注解、全局默认值与真实请求回归 |
这是根据前文定位作出的选型路径，未构成产品性能排名。若限制并不限于这四个项目，也可以把 Envoy Gateway、云厂商托管实现等纳入第二轮，但没有必要因为候选更多就推迟现有需求的验证。
性能应该在功能等价后比较。相同的 TLS、认证、限流、日志配置，以及相同的资源额度和流量模型，才有比较意义。除了请求延迟，还要看修改路由后多久生效、控制器故障后已有流量怎样、数据面重启后配置能否恢复。对长期维护项目，这些问题会直接影响故障处理。
迁移时，先验证行为，再切流量
第一步，盘点现有配置。 收集 Ingress、注解、控制器 ConfigMap、启动参数、自定义模板、TCP/UDP 配置和 TLS 设置。按实际能力分成标准路由、实现扩展与特殊逻辑，尤其关注 snippet、正则改写、外部认证、会话保持和全局默认值。
第二步，用有代表性的请求验证新入口。 选择普通 API，再加入项目真实存在的长连接、流式响应和大文件上传场景。验证路径是否改写、认证头是否保留、真实客户端 IP 是否可信、超时及限流行为是否一致；如果应用使用 gRPC，也要验证协议和错误处理。
第三步，检查配置状态与实际请求。 查看 Gateway 及监听器的 Accepted、Programmed 等状态，以及 HTTPRoute 的父级状态、Accepted 和 ResolvedRefs。不同对象上的条件含义要分别读。资源被 API Server 接收，不等于代理已完成配置；状态正常也需要真实请求验证。HTTP 路由配置指南
第四步，建立并行入口，逐步切流。 新旧控制器用明确的 Class 和独立入口地址，避免抢同一组配置。切流方案要考虑 DNS 缓存与长连接，回滚也应覆盖入口地址、路由和证书，而不只是回退 YAML。先通过新地址验证，再按项目可用的负载均衡或 DNS 机制逐步切换。
如果项目当前的迁移风险较大，可以先换掉停止维护的控制器，保持应用行为，再把适合标准化的规则迁往 Gateway API。如果规则不多、能充分回归，也可以直接迁移。两条路线的判断依据都是实际配置量与验证能力。
对你维护的项目，真正需要决定的是：团队能否长期维护选定的代理、控制器和扩展，应用规则能否尽量用共同标准表达。Gateway API 提供了更清楚的职责与规则边界；具体实现的选择，则要由当前需求、既有经验和迁移验证共同确定。