近日，亚马逊云科技在其 Load Balancer Controller 中正式发布了对 Kubernetes Gateway API 的支持。通过此次发布，团队将可以通过 Gateway API 规范 来管理 Application Load Balancer 和 Network Load Balancer。Gateway API 是由 Kubernetes SIG 维护的标准规范，作为日渐老旧的 Ingress API 的继任者，它正在获得越来越多的关注。
这一点之所以重要，是因为它解决了注解的难题。在 Gateway API 出现之前，用户需要将 JSON 配置塞进 Kubernetes 注解中来配置负载均衡器。没有 schema 验证，没有 IDE 支持，只有字符串，而这些字符串可能在运行时出问题。现在，借助适当的验证和 GitOps 友好的 YAML ，用户可以获得类型安全的 Custom Resource Definitions（CRD）。
AWS Load Balancer Controller 现在使用 Gateway API 资源同时处理第 4 层路由（TCP、UDP、TLS via Network Load Balancer）和第 7 层路由（HTTP、gRPC via Application Load Balancer）。这完善了 AWS Gateway API 覆盖范围，因为 VPC Lattice 已经在东西向服务网格流量中提供了支持。两者一起使用相同的 Kubernetes 原生 API 覆盖了南北向入口和东西向服务通信。
以前的方式是这样的：将目标组属性、健康检查配置和粘性设置塞进注解字符串中。新方法使用了三个 CRD：TargetGroupConfiguration、LoadBalancerConfiguration 和 ListenerRuleConfiguration，这些配置在生效时就会进行验证，而不是在运行时神秘地失败。
例如，配置注销延迟以前需要解析这样的注解：
alb.ingress.kubernetes.io/target-group-attributes: | deregistration_delay.timeout_seconds=30, stickiness.enabled=true
现在它变成了结构化数据：
apiVersion: gateway.k8s.aws/v1beta1kind: TargetGroupConfigurationspec: targetGroupAttributes: - key: deregistration_delay.timeout_seconds value: "30" - key: stickiness.enabled value: "true"
Gateway API 将职责分散到了三个资源中。平台团队定义 GatewayClass（基础设施模板），集群运营商配置 Gateway（监听器、TLS、子网分配），应用开发者创建 Routes（基于路径的路由、header 匹配）。这可以清晰地映射到 RBAC 边界，开发人员不需要集群管理员权限就可以路由流量。
图片来源：亚马逊云科技网络与内容分发博客—— API Gateway 组件
跨命名空间路由现在也可以实现了。平台团队在单个命名空间中配置一个共享 Gateway。应用程序团队在不同的命名空间中创建引用它们的 HTTPRoute，而开发人员无需接触安全组或 VPC 子网等基础设施层的设置，控制器会自动配置负载均衡器。
亚马逊云科技工程师 Alexandra Huides 和 Zac Nixon 在公告中写道， AWS Certificate Manager 中的自动 TLS 证书发现功能已扩展到 Gateway API 监听器。当你指定一个主机名时，控制器会查询 ACM 并附加匹配的证书。证书轮换会自动进行，无需手动更新 ARN。
Gateway API 并非亚马逊云科技所独有的。Google Cloud 的 GKE Gateway 控制器、NGINX、Envoy Gateway、Istio 等都实现了该规范。Kubernetes Gateway API 实现页面列出了 20 多个合规的控制器。亚马逊云科技的此次发布标志着该规范已经成熟；它于 2023 年 10 月达到 v1.0，2025 年 6 月达到 v1.3。
在这里，可移植性很重要。Gateway、GatewayClass 和 Route 资源中的核心路由逻辑在各种实现中保持了一致。亚马逊云科技特有的 CRD（前面提到的三个）仍然是可选且隔离的。你可以编写可移植的 Kubernetes 清单，并在需要时添加到特定云的功能中。
v3.1.0 版本中包含了一致性测试结果，从中可以看出哪些 Gateway API 功能有效，哪些无效。该控制器支持 HTTPRoute 路径匹配、基于 header 的路由、加权流量分割和 TLS 终止。关于 ReplacePrefixMatch 的部分边缘情况有一些记录在案的 ALB 限制。
已经使用 Ingress 资源的团队不需要立即迁移。该控制器仍然支持 Ingress，它没有被弃用。但新项目可能会完全跳过 Ingress，直接从 Gateway API 开始。随着集群的增长，更好的验证、更清晰的错误消息和角色分离会带来让人满意的回报。
需要注意的是，Gateway API 资源需要启用控制器的功能标志。安装文档涵盖了启用 Gateway API 支持和安装 CRD。运行旧版控制器的团队需要升级到 v2.13.3+ 来获得第 4 层支持，升级到 v2.14.0+ 来获得第 7 层支持。此外，在 Reddit 上的一个帖子中，有一位受访者表示：
真遗憾，仍然不支持外部证书。
对于此次发布，该公告将其描述为"在 AWS 上现代化 Kubernetes 部署"。该控制器的 GitHub 存储库显示，Gateway API 支持是从 2024 年的实验性 Beta 版本发展到此次正式发布，社区对于这项功能一直都比较关注。
对于深度使用 EKS 的团队来说，为了获得 Gateway API 功能而添加第三方入口控制器少了一个理由。这是否重要取决于你在亚马逊云科技支持的技术栈与采用最佳开源工具之间如何权衡。
声明：本文为 InfoQ 翻译，未经许可禁止转载。
