Gateway API 把集群入口、路由规则和应用团队职责拆得更清楚，适合多团队维护 Kubernetes 服务入口。

Ingress 简单，但团队边界不够清楚

Kubernetes Ingress 对小项目很方便：一个资源里写域名、路径和后端服务，控制器负责把外部流量转进集群。但团队规模变大后，问题会出现：平台团队关心入口网关和证书，业务团队关心路径路由和服务版本，安全团队关心 TLS 和策略。所有东西都挤在 Ingress 上，职责边界容易混乱。

Gateway API 的价值就在这里。它把入口基础设施和业务路由拆开，让不同角色维护不同资源。

三个核心对象

GatewayClass 通常由平台或基础设施团队管理，代表一种网关实现。Gateway 描述具体入口，例如监听哪些端口、使用哪些证书、暴露哪些域名。HTTPRoute 则更贴近业务，描述请求路径、Header 条件和后端服务。

这样的拆分让平台团队可以控制网关能力，业务团队可以提交自己的路由规则。相比所有人都改同一个 Ingress，这种边界更适合多人协作。

如果只是一个单体应用、一个域名、几条路径，Ingress 仍然够用。Gateway API 更适合多团队、多命名空间、多域名、多环境的集群。特别是平台团队希望统一入口能力，同时允许业务团队自助配置路由时，它的收益更明显。

另一个适用场景是从七层 HTTP 路由逐步扩展到更多协议能力。Gateway API 的设计目标不是只替代 Ingress，而是为集群服务入口提供更统一的模型。

不要一开始就把所有 Ingress 迁移。可以先选一个低风险服务，建立 GatewayClass、Gateway 和 HTTPRoute 的最小链路。确认证书、域名、路径、健康检查和日志都正常后，再扩大范围。

迁移前要列清楚旧 Ingress 的注解。很多 Ingress 控制器把重定向、超时、限流、请求体大小等能力放在注解里。迁移到 Gateway API 时，需要找到对应能力或替代方案。

Gateway API 的优势之一是权限分层。平台团队可以拥有 Gateway，业务团队只在自己的命名空间维护 HTTPRoute。这样既能自助发布路由，又不会让业务团队随意改入口网关。

Gateway API 不是为了让配置看起来更新，而是为了让入口治理更清楚。小项目继续用 Ingress 没问题；多团队、多服务、多环境的集群，可以从 Gateway API 试点开始，逐步把入口能力平台化。