Gateway API 解决的是声明方式，而不是能力边界。

大规模K8s场景需要的是全局流量基础设施，而不是集群内组件。

网算分离，正在重新定义七层网关的位置。

引言

过去几年，Kubernetes 正在成为事实上的云原生操作系统。围绕 K8s 构建七层网关，也逐渐形成了两条技术路线：一条是以 Ingress[1] / Gateway API[2] 为代表的 “网关内嵌 K8s” 模式；另一条则是把七层网关独立出来，通过控制面对接 K8s 的 “网算分离” 模式。

图1 以Ingress/Gateway API为代表的“网关内嵌K8s”模式

在中小规模集群中，Ingress 和 Gateway API 提供了不错的开箱体验：声明式配置、与 Service/Pod 自动关联、统一的 CRD 模型，这些能力让业务团队可以“自助发布”。从平台视角看，这似乎是一条标准化、云原生化的正确道路。

但当场景演进到多租户、多集群、跨地域，以及 AI 推理流量、长连接、流式返回等新型负载时，这套模型开始显现出越来越多的结构性问题：

• 七层网关的生命周期被绑定在 K8s 之内

• 控制面与计算调度耦合

• 不同网关实现对 CRD 的扩展导致“标准不可替代”

• 高性能转发模型难以通过通用抽象表达

与此同时，在采用 BGP 直连的 CNI 方案下，Pod 已具备全局可达性，七层网关从网络层面上不再必须部署在 K8s 内部。这为一种新的架构提供了可能：

让 K8s 专注于算力与编排，让七层网关回归独立的流量基础设施，通过控制面与 K8s 同步服务与实例信息。

本文将从架构演进的角度讨论：为什么 Gateway API 很难成为七层网关的终局形态，以及在大规模环境中，网算分离为何是一条更现实的技术路径。

一、Gateway API 的结构性问题

很多讨论把 Gateway API 的问题归结为“还不成熟”，但更本质的，是它在设计目标上的约束。

1. 抽象层次过高，难以覆盖全功能转发模型

Gateway API 试图用一套通用 CRD 描述所有七层网关能力，但不同网关在核心转发模型上差异巨大：

• Nginx[3] 是基于正则与 location 的路径匹配模型

• Envoy[4] 是基于多字段匹配的声明式路由模型

• BFE[5] 是基于条件表达式的策略决策模型

为了统一抽象，只能选择“最小公约数”，这意味着：

👉 高级能力必须通过私有 CRD 扩展

👉 一旦使用扩展，就失去可替代性

标准存在，但可移植性并不存在。

2. 控制面与计算调度耦合

Gateway API 的资源模型依附于 K8s：

• 网关实例的生命周期受 K8s 调度影响

• 流量入口与 Pod 编排强绑定

• 多集群场景需要额外的同步控制面

这导致一个问题：

流量基础设施被绑定在单一集群的控制域内。

而在大规模场景中，七层网关往往需要：

• 多K8s集群统一入口

• 跨K8s集群流量调度

• 独立的灰度与发布体系

这些能力天然更适合独立控制面。

3. 多实现导致“虽有标准、仍然不可替代”

理论上 Gateway API 是标准，但现实是：

• 每个网关都有自己的 CRD 扩展

• 策略、鉴权、限流模型完全不同

• 可观测性接口不一致

结果是：

👉 从 A 网关迁移到 B 网关，成本依然很高

👉 Gateway API 并没有带来真正的可替换性

标准更多解决的是“声明方式统一”，而不是“能力模型统一”。

4. 不适配新型流量形态

Gateway API 的设计中心仍然是传统 HTTP 流量，而在 AI 推理场景中，常见的是：

• 长连接

• 流式返回

• 会话亲和

这些能力依赖网关与后端的深度协同，很难通过通用 CRD 描述。

二、 网络条件的变化：七层网关不再必须在 K8s 内

在早期 Overlay 网络中，Pod IP 不可达，网关必须部署在集群内部。但在采用 BGP 直连的 CNI 方案后：

• Pod IP 全局可路由

• 网关可以直接访问 Pod

• 不再依赖 NodePort / kube-proxy

这意味着：

七层网关的位置从“技术必选项”变成了“架构选择题”。

既然网络已经解耦，把网关继续放在 K8s 内，更多是历史路径依赖，而不是技术必要性。

三、网算分离的架构优势

将七层网关独立于 K8s 部署，并通过控制面与 K8s 同步实例信息，可以带来几个关键优势。

1. 职责边界清晰

• K8s 负责算力调度

• 网关负责流量治理

两者解耦，避免单一控制域过载。

2. 更适合多集群场景

独立网关天然就是全局入口：

• 多集群统一调度

• 全局灰度发布

不需要额外的多集群 Gateway API 控制面。

3. 更稳定的转发平面

网关实例不再受：

• Pod 重调度

• 节点漂移

• 集群升级

的影响，转发平面可以独立扩缩容，稳定性显著提升。

4. 更适配 AI 与长连接流量

独立网关更容易实现：

• 会话级路由

• 推理状态感知调度

这些能力往往需要网关与推理框架深度协同，而不是通用 CRD。

四、落地方式：控制面对接 K8s，而不是嵌入 K8s

图2 K8s场景下网算分离的落地方式

网算分离并不意味着放弃云原生，而是换一种对接方式：

1. 在 K8s 内运行 Service Controller：同步 Pod / Endpoint 变化到网关控制面

2. 网关控制面提供多租户 API：供业务团队自助配置路由与策略

3. 转发平面独立部署：作为全局流量入口

这样既保留了 K8s 的自动扩缩容能力，又避免了将流量基础设施绑定在集群内部。

具体应用实例，可参考[6]和[7]中的说明。

结语：不是替代，而是分层

Gateway API 并非没有价值，在中小规模、单集群场景下，它仍然是高效的解决方案。但在大规模、多集群、多租户以及 AI 推理驱动的流量形态下，七层网关正在从“集群组件”演进为“全局基础设施”。

当网络已经解耦、流量形态已经变化、控制面复杂度不断上升时，继续把网关嵌入 K8s，并通过通用 CRD 试图抽象所有能力，反而会成为架构的限制。

网算分离并不是对云原生的背离，而是一次职责边界的重构：

• K8s 回归算力调度

• 网关回归流量治理

在这一分层之下，七层网关才能真正成为跨集群、面向新型流量的稳定基础设施。

对于大规模平台团队而言，这可能不是一个“是否支持 Gateway API”的问题，而是一个更根本的架构选择题。

当七层网关成为全局基础设施时，它就不再属于某一个 K8s 集群。

参考资料

[1] Ingress，https://kubernetes.io/docs/concepts/services-networking/ingress/

[2] Gateway API，https://gateway-api.sigs.k8s.io/

[3] Nginx, https://nginx.org/

[4] Envoy，https://github.com/envoyproxy/envoy

[5] BFE, https://github.com/bfenetworks/bfe

[6] BFE service-controller v1.0.0 发布！，https://mp.weixin.qq.com/s/1obISim8HfdBtuGOqeHRnw，2025年12月

[7] BFE service-controller，https://github.com/bfenetworks/service-controller

作者简介

章淼，博士，1994年进入清华大学计算机科学与技术系学习，2004年获得博士学位，2004年至2006年在清华大学留校任教，在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年，聚焦云网络基础架构的研发工作，是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升，曾担任百度代码规范委员会主席，2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术：用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO，聚焦研发面向云和大模型场景的现代化流量管理平台。