内容管家
评论9字数 446阅读1分29秒阅读模式
背景与选型原因
2025 年 11 月，Kubernetes 官方宣布 Ingress-NGINX 将被停用，Stack Overflow 不得不提前规划迁移方案。Ingress-NGINX 此前一直是其 Kubernetes 集群流量路由的核心组件。借此机会，团队决定转向更现代的 Gateway API，以获得更好的功能特性和角色分离能力，不再选用其他 Ingress 控制器。
候选方案与评估标准
团队制定了严格的筛选条件：必须是 Gateway API 兼容实现列表中的产品，且需同时支持 GCP 和 Azure 两大云平台。经综合功能矩阵（v1.4）和第三方基准测试，最终入围三款 Gateway API 实现：
- NGINX Gateway Fabric
- Traefik
- Istio
此外，两款 Ingress 方案（F5 NGINX Ingress 和 Traefik）也被纳入备选考量。但因注解兼容性问题，以及高级路由功能依赖非标准 Kubernetes 资源，团队很早就放弃了 Ingress 路线。
测试方法与结论
团队使用 HTTPBin 和一个轻量级 Go 服务作为测试后端，通过 K6 进行压测，基准目标为单网关 10,000 RPS，每款网关部署 4 个副本（e2-standard-4 GCP 节点）。测试覆盖约六组典型用例和两项扩展性基准。
结果方面，三款实现均能满足核心路由需求。在功能细节上，Istio 符合最多 Gateway API 特性，Traefik 最少。值得注意的是，Gateway API 的 Header 修改功能仅支持静态值，动态正则匹配需依赖各实现的自定义扩展点——三者的扩展机制均可满足需求，但 Istio 的语法复杂度明显更高。此外，涉及 ngxhttpauthrequestmodule 的认证转发在迁移到其他实现时需要调整应用代码，这是迁移中的主要痛点之一。
评论