Kubernetes Gateway API：接替 Ingress 的角色化 L4/L7 流量标准
阅读时间: 大约 15 分钟
Kubernetes Gateway API：接替 Ingress 的角色化 L4/L7 流量标准
Gateway API 是 Kubernetes SIG-Network 社区主导的官方项目，定位为”Kubernetes 上 L4 与 L7 路由的下一代 Ingress、负载均衡与服务网格 API”，从一开始就按 generic（通用）、expressive（可表达）、role-oriented（角色化）设计。它不是某个厂商的控制器，而是一份可被多家实现的可移植规范。本文以 SIG 官方文档为准（调研时最新补丁版为 v1.6.3，2026-10-06 发布），结合第三方早期科普，说明它为什么取代 Ingress、怎么工作，以及官方仍标注为实验或演进中的部分。
一、背景：Ingress 为什么不够用
Ingress 是 K8s 最早的北向（North-South）流量入口对象，定义外部流量到 Service 的路由，提供负载均衡、TLS 终止、基于名字的虚拟主机。但正如第三方 2022 年科普（ARMO）所述，Ingress API 刻意保持窄小以保证可移植性，NGINX Ingress、HAProxy 等控制器为了区分彼此，纷纷用私有注解（annotations）塞入高级负载均衡、流量染色等能力，各家实现互不兼容，用户被绑在特定控制器的注解方言上。
Gateway API 的思路是：把这些”以前只能靠私有注解”的能力收编进标准 API，让多家厂商按同一份规范实现，用户保留切换实现的自由。官方四条设计目标直接对标 Ingress 的短板：
- Role-oriented（角色化）：资源模型映射组织里不同角色各自管理的对象；
- Portable（可移植）：像 Ingress 一样是多实现支持的通用规范；
- Expressive（可表达）：头匹配、流量加权等核心能力原生支持，不再靠自定义注解；
- Extensible（可扩展）：API 各层都可挂载自定义资源做细粒度定制。
二、资源模型：三个角色，三类对象
官方把使用者抽象为三个 persona，并对应到三类 CRD（均在 gateway.networking.k8s.io 组）：
| 角色 | 代表人物 | 管理的资源 | 职责 |
|---|---|---|---|
| Infrastructure Provider | Ian | GatewayClass | 定义一类网关的通用配置与行为，由哪个控制器实现 |
| Cluster Operator | Chihiro | Gateway | 请求一个具体负载均衡实例，绑定地址与监听器 |
| Application Developer | Ana | Route（HTTPRoute 等） | 描述到达 Gateway 的流量如何映射到后端 Service |
- GatewayClass（Standard Channel 自 v0.5.0）：集群级资源，类似 IngressClass/StorageClass，一个 GatewayClass 由单个控制器处理，控制器也可处理多个 GatewayClass；集群里至少要有一个 GatewayClass 才能产生可用 Gateway。
- Gateway（v1.0 进入 GA）：定义”把外部流量翻译到集群内 Service”的请求，绑定一个或多个 Address（IP，部分云实现用域名）与多个 Listener（端口+协议）。官方要求 Listener 之间必须可区分（distinct），一条流量只能命中一个 Listener，命中后要么经挂载的 Route 路由，要么被丢弃，不能落空后回退到另一个 Listener；Listener 冲突会让整个 Gateway 无法进入 Accepted 状态。
- Route：协议相关的路由规则，把 Gateway 收到的请求映射到 Service。
三、Route 类型与标准进度（官方渠道标注）
| Route 类型 | 用途 | 官方渠道状态 |
|---|---|---|
| HTTPRoute | 多路复用 HTTP/终止后的 HTTPS，按 HTTP 头路由或改写 | Standard，自 v0.5.0 |
| GRPCRoute | 地道地路由 gRPC；要求支持无需 HTTP/1 升级的 HTTP/2 | Standard，自 v1.1.0 |
| TLSRoute | 按 SNI 分流 TLS，Passthrough 透传或 Terminate 终止 | Standard，自 v1.5.0 |
| TCPRoute / UDPRoute | 把端口映射到单一后端 | Experimental，自 v0.3.0 |
四、双用途：北向 Ingress 与东向 Mesh（GAMMA）
官方 Logo 的寓意就是同一套配置同时服务南北向与东西向流量：
- 北向（Ingress）：Standard 自 v0.5.0。流量从集群外进入，经 GatewayClass→Gateway，再挂 Route；
- 东向（Service Mesh，GAMMA 倡议）：Standard 自 v1.1.0。集群里通常只有一个 mesh，因此不使用 Gateway/GatewayClass，Route 直接挂到 Service（
parentRefs里kind: Service）。官方把 Service 拆成 frontend（名字+ClusterIP）与 backend（端点 IP 集合）两个 facet 以精确定义 mesh 内路由。
GAMMA 还区分两类 Route：producer route（与 Service 同命名空间，工作负载创建方定义，影响所有客户端）与 consumer route（跨命名空间，消费方定制，只影响本命名空间内对该 Service 的请求）。官方明确：一旦 Service 挂了 Route，未命中任何 Route 的请求会被拒绝；未挂 Route 则按 mesh 默认行为转发。producer/consumer route 的关系仍是 ongoing work。
共享 Gateway 与跨命名空间：多个独立 Route 可挂载到同一 Gateway，团队（即使跨 Namespace）无需直接协调即可共享负载均衡器/VIP；跨命名空间引用由 ReferenceGrant 授权控制。
五、发布渠道：Standard 与 Experimental
官方把稳定性压缩为两个渠道（废弃了 K8s 传统的 alpha/beta/GA 三级里的 beta 中间态）：
- Standard Channel：已毕业到 GA 的资源与字段，默认推荐，提供稳定体验；标准版目标约 4 个月节奏，日期固定、内容灵活；
- Experimental Channel：Standard 全部内容 + Alpha 资源与未毕业新字段，按月发布（
monthly-YYYY-MM），不保证向后兼容，可随时引入破坏性变更。
官方用 Validating Admission Policies（Upgrade VAP、Guardrails VAP）保护渠道边界：禁止用实验版 CRD 覆盖标准版，且不带注解就不能设置实验字段。v1.0 发布时 HTTPRoute、Gateway、GatewayClass 毕业到 GA v1；此前的 v1beta1 仅 HTTPRoute/Gateway/GatewayClass/ReferenceGrant 持有，未来新资源直接以 v1 毕业；ReferenceGrant 因正迁移为 sig-auth 上游 API，实际冻结在 beta。
六、一致性与实现差异（口径）
Gateway API 功能面很广、实现众多，官方用 Core / Extended 支持级别 + 行为驱动的一致性测试（conformance tests）来约束：Core 是可移植子集，Extended 是可选增强，实现私有特性不在一致性测试覆盖内。当前测试覆盖标准渠道多数 Core 能力与部分 Extended，分 Gateway（ingress）与 Service Mesh 两套。这意味着：同一个 HTTPRoute 写法，不同控制器对 Extended 字段的支持可能不同，投产前必须核对具体实现的一致性报告。
七、适用与不适用场景
适合：
- 多团队共享入口、希望脱离特定控制器注解方言的平台团队；
- 需要标准头匹配、流量加权（蓝绿/金丝雀）、跨命名空间共享网关的北向场景；
- 想用同一套 Route 配置同时治理 ingress 与 mesh 东西向流量的组织；
- 需要在多家网关实现间保持可移植、避免厂商锁定的团队。
不适合/需谨慎：
- 依赖 TCPRoute/UDPRoute 等 Experimental 能力的关键路径（无兼容性承诺）；
- 期望所有控制器都支持全部 Extended 字段（需逐个核对一致性）；
- 把 Gateway API 当作服务网格数据面本身（它只标准化配置，策略/加密仍由 mesh 实现提供）；
- 认为 Ingress 会立即下线（Ingress 仍长期并存，迁移是渐进的）。
八、客观分析：优势与局限
优势：
- 角色化分权：基础设施、集群运营、应用开发各管各的对象，共享基础设施与自治的矛盾被显式建模；
- 能力收编进标准：头匹配、流量加权、TLS 多终止等脱离私有注解，可移植性强；
- 一套 API 覆盖南北与东西：GAMMA 用最小改动把 Route 复用到 Service Mesh；
- 双渠道 + 一致性测试：实验快速迭代与生产稳定被明确隔离；
- 官方 SIG 项目、多厂商实现、v1 GA，长期路线清晰。
局限：
- 学习对象增多：GatewayClass/Gateway/Route/ReferenceGrant 层级比 Ingress 复杂，小团队收益有限；
- Extended 支持碎片化，跨实现移植仍需核对一致性；
- Mesh 方向（GAMMA）仍在演进，producer/consumer route 关系未定稿；
- 不替代数据面与选主，TLSRoute 等较晚才进 Standard；
- 第三方科普多写于早期（如 ARMO 2022 年文），版本与渠道状态已变化，须以现行官方文档为准。
九、它意味着什么
Gateway API 代表 K8s 流量控制从”一个窄对象 + 各家私有注解”走向”角色化、可移植、可扩展的标准接口”。对平台团队，它是统一南北向入口、为多租户分权的长期方向；对应用开发者，它把路由配置从控制器方言里解放出来。生产落地建议默认 Standard 渠道、只启用已确认实现支持的 Core/Extended 字段，并把 Experimental 能力留在非关键路径。
参考来源
- Gateway API 官方文档 Introduction（SIG-Network）
- 官方 API Overview：GatewayClass/Gateway/Route
- 官方 Versioning：Standard/Experimental 渠道
- 官方 Conformance：Core/Extended 与一致性测试
- 官方 GAMMA：Gateway API for Service Mesh
- kubernetes-sigs/gateway-api 仓库（最新 v1.6.3）
- ARMO：The New Kubernetes Gateway API and Its Use Cases（2022，第三方早期科普）
- Koala 项目库条目 1153：Kubernetes Gateway API | K8s 流量控制新方案