【Kubernetes 网络深度系列】Gateway API：Kubernetes 流量管理的未来标准
内容提要
Gateway API是Kubernetes入口流量管理的新标准，取代Ingress。它通过GatewayClass、Gateway、xRoute三层资源实现角色分离，支持HTTP、gRPC、TCP等协议及高级流量管理（金丝雀、Header路由、URL改写）。相比Ingress依赖annotation，Gateway API提供原生可移植能力，并扩展至服务网格（GAMMA）。文章还介绍了迁移路径、主流实现对比及Envoy Gateway金丝雀发布实验。
延伸解读
角色分离：从“一把抓”到“各司其职”
Ingress 的单一资源模型让基础设施团队和应用团队共用一份配置，权限边界模糊。Gateway API 通过 GatewayClass、Gateway、xRoute 三层资源，将网关实现、实例配置、路由规则分别对应基础设施提供者、集群运维和应用开发者。这种设计不仅让职责更清晰，还能通过 RBAC 实现细粒度权限控制，例如只允许运维创建 Gateway，开发者只能管理自己的 Route。
可移植性：告别 annotation 依赖
Ingress 的扩展能力依赖各厂商自定义的 annotation，导致同一份 YAML 在不同控制器间无法通用。Gateway API 将金丝雀、Header 路由、URL 改写等高级功能纳入原生 spec，并提供了 Filter、Policy Attachment、parametersRef 三种标准化扩展机制。这意味着核心配置可以在不同实现间迁移，降低了厂商锁定风险。
迁移路径：评估、共存、切换
从 Ingress 迁移到 Gateway API 并非一蹴而就。文章建议先评估现有 annotation 的依赖，确定是否有跨 namespace 引用需求，并选择合适的实现。迁移过程中，大多数实现可与现有 Ingress 控制器共存，可以逐步将非关键应用切换到 HTTPRoute，验证后再扩大范围，最后下线旧控制器。社区工具 ingress2gateway 可辅助转换，但复杂 annotation 仍需手动处理。
GAMMA：统一南北向与东西向流量管理
Gateway API 不仅用于入口流量，还通过 GAMMA 子项目扩展到服务网格。在 GAMMA 模型中，HTTPRoute 的 parentRef 可以指向 Service，实现网格内的流量分割和路由。这意味着开发者可以用同一套 API 管理南北向和东西向流量，减少学习成本。目前 Istio 支持最完整，Linkerd 和 Cilium 部分支持，长期目标是实现跨网格的可移植性。
Q&A
Gateway API 相比 Ingress 有哪些核心优势？
Gateway API 相比 Ingress 具有角色分离、可移植性、可扩展性和协议多样性等核心优势。它通过 GatewayClass、Gateway、xRoute 三层资源实现角色分离，支持 HTTP、HTTPS、gRPC、TLS、TCP、UDP 等多种协议，并提供原生的高级流量管理功能（如金丝雀发布、Header 路由、URL 改写），不再依赖不可移植的 annotation。
Gateway API 中的 GatewayClass、Gateway 和 HTTPRoute 分别由谁管理？
GatewayClass 由基础设施提供者（Infrastructure Provider）管理，负责声明集群中可用的网关实现；Gateway 由集群运维（Cluster Operator）管理，代表实际的数据面实例，配置监听端口、TLS 证书等；HTTPRoute 由应用开发者（Application Developer）管理，定义路由规则并绑定到 Gateway。
如何用 Gateway API 实现金丝雀发布？
在 HTTPRoute 的 backendRefs 中为不同版本的后端设置 weight 权重，例如 stable 版本 weight: 90，canary 版本 weight: 10，即可将 10% 的流量导向 canary 版本。也可以结合 Header 匹配，将带有特定 Header（如 x-canary: true）的请求全部导向 canary 版本。
Gateway API 支持哪些协议？
Gateway API 原生支持 HTTP、HTTPS、gRPC、TLS、TCP 和 UDP。其中 HTTPRoute 和 GRPCRoute 在 Standard channel，TLSRoute、TCPRoute 和 UDPRoute 在 Experimental channel。
ReferenceGrant 在 Gateway API 中起什么作用？
ReferenceGrant 用于允许跨 namespace 的安全引用。默认情况下，Gateway API 禁止跨 namespace 引用资源，ReferenceGrant 由被引用方 namespace 的管理员创建，显式授权其他 namespace 的特定资源可以引用本 namespace 中的资源，例如允许 HTTPRoute 引用其他 namespace 的 Service，或 Gateway 引用其他 namespace 的 Secret。
如何从 Ingress 迁移到 Gateway API？
迁移步骤包括：1. 评估现有 Ingress 使用的 annotation，检查在 Gateway API 中是否有原生替代；2. 规划跨 namespace 引用需求，创建 ReferenceGrant；3. 选择 Gateway API 实现（如 Envoy Gateway、Istio 等）；4. 部署实现并创建 GatewayClass 和 Gateway；5. 选择非关键应用创建 HTTPRoute 替代 Ingress，验证后逐步扩大范围；6. 全部迁移后下线旧控制器。也可以使用社区工具 ingress2gateway 自动转换部分资源。
GAMMA 是什么？它如何扩展 Gateway API？
GAMMA（Gateway API for Mesh Management and Administration）是 Gateway API 的子项目，旨在将 Gateway API 的资源模型扩展到服务网格（东西向流量）。在 GAMMA 模型中，HTTPRoute 的 parentRef 可以指向 Service，从而定义如何路由到该 Service 的流量，实现网格内的金丝雀发布、Header 路由等功能，提供跨网格的可移植性。
Envoy Gateway 和 Istio 在 Gateway API 实现上有什么主要区别？
Envoy Gateway 是专为 Gateway API 设计的，完全合规，提供丰富的 Policy Attachment，但社区规模相对较小；Istio 也完全合规，GAMMA 支持最成熟，与服务网格一体化，但部署复杂度较高。选择时，如果已用 Istio 做服务网格，可直接使用 Istio 的 Gateway API 实现；如果纯入口网关，Envoy Gateway 更轻量。
