EKS 上的 Gateway API：NGINX Ingress Controller 结束后有什么变化
Source: Dev.to
NGINX Ingress Controller 的终止
NGINX Ingress 正式进入 停用 阶段。维护将在 2026 年 3 月 结束——在此日期之后，将不再有新版本、错误修复或安全补丁。
Kubernetes 的 Ingress API 并未 被停用，仅是 NGINX Ingress Controller（实现）被停用。你仍然可以使用 Ingress API，配合其他控制器，如 AWS Load Balancer Controller、Traefik 等。
为什么要停用？
- 难以维系的技术债务（NGINX 代码片段已成为漏洞）
- 每次配置变更都需要重新加载 NGINX，负载过高
- 过度依赖特定控制器的 annotations
- 维护者严重不足
项目 InGate 曾尝试解决这些问题，但因缺乏足够的社区参与，也将在 2026 年停用。
来源： Kubernetes Blog – Ingress NGINX Retirement
Gateway API：Ingress 的演进
Gateway API 引入了更清晰的概念并实现了职责分离。
主要组件
- GatewayClass – 定义由哪个控制器管理网关（类似 IngressClass）
- Gateway – 定义负载均衡器（ALB/NLB）及其监听器
- HTTPRoute – 定义 HTTP 路由（类似 Ingress，但更强大）
相比 Ingress 的优势
- 职责划分明确（基础设施 vs. 应用）
- 原生支持跨多个 Namespace
- 高级路由功能（header 匹配、加权路由、重试等）
- 行业标准，而非 Kubernetes 专属实现
重要提示： 此处的 “Gateway API” 指的是 Kubernetes Gateway API（Ingress 的替代方案），而非 Amazon API Gateway 或 Kong、Apigee 等产品。
在 EKS 中的选项
就像使用 Ingress 需要一个控制器（NGINX、Traefik 等），Gateway API 也需要安装 GatewayClass。在 EKS 中没有原生支持——需要自行选择实现。
如果你使用 ingress‑nginx‑controller
在 gateway‑api.sigs.k8s.io/implementations 中列出的 GA 实现中，以下两者尤为突出：
- Envoy Gateway – 开源成熟度高，市场采用广泛，基于 Cloud Native 生态的标准代理（同 Istio），由 CNCF 维护。
- Traefik Proxy – 注重开发者体验；用 Middlewares（可复用的 CRD）取代 NGINX 那一堆 “annotations”，让规则管理更简洁、可视化。
这两者的架构与 NGINX Ingress Controller 类似：
- 使用 NLB 作为托管的 L4 服务
- 在集群中以 Pod 形式运行代理（L7）
注意：
external-dns、cert-manager等工具仍然可以与 Gateway API 配合使用，只是部分配置需要相应调整。
如果你今天使用 AWS Load Balancer Controller 的 Ingress
继续使用 Ingress。 暂时不要切换。基于 AWS Load Balancer Controller 的传统 Ingress 已经相当成熟、稳定，适合生产环境。
AWS Load Balancer Controller 已经支持 Gateway API，但仍处于 beta 阶段。根据官方文档：
“团队正在积极弥补符合性和支持方面的差距。尚不建议在生产工作负载中同时使用 LBC 和 Gateway API（目前仍不建议）。”
能用吗？ 能。我们在实验室完成了一个功能性 POC，测试时运行良好。
离题提示： 在 GKE（Google Cloud）上，Gateway API 已经更为成熟并原生集成，采用门槛更低。
结论
Gateway API 是 Ingress 的自然演进，但在 EKS 上仍处于过渡期。建议提前做好准备：进行测试、熟悉新 API，并规划将现有配置迁移到 Kubernetes 新一代 API 的方案。