3. Gateway API 概述：起源、核心概念与 Ingress 对比
Gateway API 是 Kubernetes 社区为解决传统 Ingress API 在表达能力、多团队协作、协议扩展和流量治理方面的不足而推出的新一代网关抽象层。本章从起源、核心资源模型以及与 Ingress API 的对比三个维度，帮助学员建立对 Gateway API 的完整认知。
3.1 起源：从 Ingress 到 Gateway API 的演进
Kubernetes 原生 Ingress API（networking.k8s.io/v1）自 1.1 版本引入，提供了基于 HTTP/HTTPS 的七层路由能力。然而，随着云原生网关场景的复杂化，Ingress 的局限性日益凸显：
- 协议单一：仅支持 HTTP/HTTPS，无法原生处理 TCP、UDP、gRPC、TLS 透传等协议。
- 职责模糊：Ingress 资源同时承载“网关配置”与“路由规则”，导致多团队协作时配置冲突。
- 扩展性差：通过 Annotation 实现厂商特定功能，缺乏标准化，导致配置不可移植。
- 缺少分层抽象：基础设施团队与应用团队共享同一资源，无法实现职责分离。
Gateway API 由 SIG-Network 于 2020 年发起，旨在解决上述问题。其设计目标包括：面向角色（Role-oriented）、可移植（Portable）、表达性强（Expressive）、可扩展（Extensible）。
3.2 核心概念：三大资源模型
Gateway API 的核心由三个资源构成：GatewayClass、Gateway、HTTPRoute。它们形成了从“基础设施定义”到“流量路由”的完整分层模型。
3.2.1 GatewayClass
GatewayClass 是集群级别的资源，由基础设施管理员定义，用于声明可用的网关实现（如 Istio、Contour、NGINX、HAProxy 等）。它类似于 IngressClass，但语义更丰富。
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: example-gateway-class
spec:
controllerName: "istio.io/gateway-controller"
parametersRef:
group: "example.com"
kind: "Config"
name: "gateway-config"
namespace: "gateway-system"
3.2.2 Gateway
Gateway 是命名空间级别的资源，由集群运维人员定义，代表一个具体的网关实例。它描述了监听器（Listener）的协议、端口、TLS 配置以及关联的 GatewayClass。
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-gateway
namespace: infra
spec:
gatewayClassName: example-gateway-class
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
app: frontend
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
certificateRefs:
- name: my-tls-cert
3.2.3 HTTPRoute
HTTPRoute 是命名空间级别的资源，由应用开发者定义，用于描述 HTTP 流量的路由规则。它支持路径匹配、Header 匹配、权重分发、过滤器（重定向、重写、请求镜像）等高级特性。
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: my-app-route
namespace: app-team
spec:
parentRefs:
- name: my-gateway
namespace: infra
hostnames:
- "app.example.com"
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: api-service
port: 8080
weight: 90
- name: api-service-canary
port: 8080
weight: 10
- matches:
- path:
type: Exact
value: /healthz
backendRefs:
- name: health-service
port: 9090
3.3 核心资源关系图
下图展示了 GatewayClass、Gateway、HTTPRoute 三者之间的关联关系，以及它们与后端 Service 的最终绑定。
3.4 与 Ingress API 的对比
Gateway API 并非 Ingress 的简单替代，而是一次架构层面的升级。下表从多个维度对比两者的核心差异：
| 对比维度 | Ingress API | Gateway API |
|---|---|---|
| 资源模型 | 单一资源（Ingress）承载路由与网关配置 | 三层资源模型：GatewayClass / Gateway / Route |
| 角色分离 | 无原生角色分离，所有配置集中在同一资源 | 面向角色设计：基础设施、平台、应用各司其职 |
| 协议支持 | 仅 HTTP/HTTPS | HTTP、HTTPS、TLS 透传、TCP、UDP、gRPC（通过 GRPCRoute） |
| 路由匹配 | 路径前缀、主机名 | 路径（Exact/Prefix/RegularExpression）、Header、QueryParam、Method |
| 流量治理 | 无原生支持，依赖 Annotation | 权重分发、请求镜像、重定向、重写、自定义过滤器 |
| 跨命名空间 | 不支持（需 IngressClass 配合） | 原生支持，通过 allowedRoutes 控制跨命名空间引用 |
| TLS 配置 | 仅支持 TLS 终止 | 支持 TLS 终止、TLS 透传（Passthrough）、双向 TLS（mTLS） |
| 扩展性 | 通过 Annotation 扩展，不可移植 | 通过 Policy Attachment（如 BackendTLSPolicy）和自定义 Route 类型扩展 |
| 状态反馈 | 无标准状态字段 | 提供丰富的 Status 字段，包括 Accepted、ResolvedRefs、Condition 等 |
3.5 从 Ingress 到 Gateway API 的迁移路径
对于已有 Ingress 资源的集群，Gateway API 提供了平滑的迁移策略：
- 并行部署：在集群中同时部署 Ingress 控制器和 Gateway API 控制器，新服务使用 Gateway API，旧服务保持 Ingress。
- 逐步迁移：将 Ingress 资源中的路由规则逐步转换为 HTTPRoute，并通过 Gateway 资源统一管理监听器。
- 统一管理：待所有流量迁移完成后，移除 Ingress 控制器，仅保留 Gateway API 控制器。