Gateway API：Kubernetes 流量管理的未来，Ingress的接班者

在很长一段时间里，Ingress 是 Kubernetes 集群的标准北向流量入口。但随着业务复杂度增加、微服务体系兴起、多协议需求增长，Ingress 的先天缺陷越来越明显。

2024–2025 年，Kubernetes 官方与 CNCF 明确：

Gateway API 是下一代流量管理标准，将逐步取代 Ingress 成为默认推荐方式。

而随着 ingress-nginx 宣布在 2026 年 3 月停止维护，Gateway API 的迁移意义愈发明确。

本文将从原理、对比、设计理念、CRD、部署与使用示例多个方面全面介绍 Gateway API。

1. 什么是 Gateway API？

Gateway API 是 Kubernetes SIG-Network 推出的新一代流量治理标准。

核心目标：

统一 L4/L7 流量管理
取代 Ingress 的简陋模型
提供可扩展、可观察、可分权协作的网关体系
能适配云厂商、服务网格、Ingress 控制器等各种实现

它不是一个控制器，而是一套标准 API（CRD）。

控制器厂商（如 Envoy、Traefik、Istio、Kong）可以实现这套 API。

Gateway API 主要提供以下能力：

多协议支持：HTTP、HTTPS、gRPC、TCP、UDP、TLS
更丰富的路由表达式
多 listener、多端口、跨命名空间引用
运维与开发分离
可扩展策略（HTTPRouteFilter、Policy Attachment）
统一的条件与状态反馈

这些是 Ingress 无法做到的。

2. 与 Ingress 的对比

下表总结两者的核心差异：

对比项	Ingress	Gateway API
设计年代	2015（Kubernetes 1.2）	2022（现代网关能力需求）
支持协议	仅 HTTP/HTTPS	HTTP、HTTPS、TCP、UDP、gRPC、TLS
扩展方式	annotation（混乱、不可维护）	Policy Attachment、Filters（结构化扩展）
资源模型	IngressClass、Ingress	GatewayClass、Gateway、xRoute 多资源模型
权限与分权	不支持	完整支持 Ops（Gateway）与 Dev（Route）分离
可观察性	状态简陋	丰富的 Conditions
多 Listener	不支持	支持多个端口、TLS、SNI
团队协作	困难	一等公民能力
行业支持	ingress-nginx 等传统控制器	Google、AWS、Azure、Envoy、Istio、Kong、Traefik

核心结论

Ingress 是简陋的 1.0 版本，而 Gateway API 是可扩展的现代化网关规范。

3. 为什么 Kubernetes 官方不升级改造 Ingress，而是重做 Gateway API？

这是很多人关心的问题。

官方给出的根本原因：

Ingress 模型太简陋，结构性无法扩展

Ingress 的原始设计只包含：

host
path
backend

没有 header、method、流量镜像、权重路由、重写规则、多 listener 等能力。

为了加功能，各控制器全靠 annotation hack，最终变成：

“同一能力不同 controller 语法不同，生态彻底碎片化。”

Ingress 的设计已经补不动了。

Ingress 是单资源模型，无法支持现代需求

现代网关需要：

LB 生命周期
Listener
多团队协作
不同 protocol 的路由
TLS 策略
绑定多个 Route
权限隔离

Ingress 单一资源没办法表达这些需求。

Ingress 只支持 HTTP，不支持多协议

如今的需求包括：

TCP 服务
UDP 服务
gRPC
TLS Passthrough
WebSocket
Mesh Ingress

Ingress 无法扩展。

厂商实现完全不兼容，社区无法统一标准

Nginx、Traefik、Kong、云厂商的 Ingress 都不兼容，这让官方无法继续推进它作为标准。

提升 Ingress = 大修 API → 这是破坏性变更

Kubernetes 官方不允许破坏性 API 升级，这意味着：

“想升级 Ingress，但升级后的 API 必须不破坏，不可能。”

所以，只能重做一套更先进的网关模型。

4. Gateway API 的资源模型（CRD）

Gateway API 使用多层次模型，清晰分权：

GatewayClass → Gateway → xRoute → Backend

GatewayClass

描述网关的“类型”，类似于 IngressClass。

由运维团队创建，比如：

Envoy Gateway
Nginx Gateway
云厂商负载均衡器

由集群管理员创建维护。

Gateway

实际的网关实例，例如：

一个 VIP（load balancer）
一个 Nginx/Envoy pod 部署
一个 Istio IngressGateway

由 Ops 团队创建。

Route

可以是以下任意一种：

HTTPRoute
TCPRoute
UDPRoute
TLSRoute
GRPCRoute

Route 由业务开发创建，声明服务如何暴露。

Backend（Service）

最终转发的目标服务。

5. 部署与使用示例

下面以 Envoy Gateway 为例。

注意：Gateway API还在高速发展中，CRDs在变化，因此Controller不同版本存在兼容矩阵，在部署的时候要根据你的Kubernetes版本选择兼容的Controller、Gateway API版本。如Envoy Gateway，请查看https://gateway.envoyproxy.io/news/releases/matrix/

安装 Gateway API CRDs

这一步可能不需要主动安装，大多常见的控制器厂家在他们的部署文件中已经包含了Gateway API CRDs。

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml

部署 Envoy Gateway

kubectl apply -f https://github.com/envoyproxy/gateway/releases/latest/download/install.yaml

创建 GatewayClass

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

创建 Gateway（入口网关）

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: envoy
  listeners:
    - allowedRoutes:
        namespaces:
          from: All
      name: http
      protocol: HTTP
      port: 80

创建HTTPRoute（代替Ingress）

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: default
spec:
  hostnames:
  - www.example.local
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway
    namespace: default
  rules:
  - backendRefs:
    - group: ""
      kind: Service
      name: httpbin
      port: 80
      weight: 1
    matches:
    - path:
        type: PathPrefix
        value: /

相当于 Ingress，但语义更完整、结构更清晰。