1. Gateway API 概述
什么是 Gateway API
Gateway API 是 Kubernetes 社区在 2020 年启动的下一代入口流量管理规范，由 SIG-NETWORK 主导设计，旨在替代和超越传统的 Ingress API。它不是一个单一的 CRD，而是一组可组合的、面向角色的资源模型，核心资源包括：
- GatewayClass — 定义网关的“类”，类似 StorageClass，描述由哪个控制器实现（如 Istio、Contour、Nginx Gateway Fabric）。
- Gateway — 描述具体的网关实例，绑定监听端口、协议、TLS 配置，并关联到 GatewayClass。
- HTTPRoute — 核心路由规则，定义 HTTP 请求的匹配条件（路径、Header、Query 参数）和后端转发目标。
- ReferenceGrant — 跨命名空间授权机制，允许路由引用其他命名空间的后端服务。
关键认知：Gateway API 将“基础设施配置”与“应用路由配置”解耦。平台管理员管理 GatewayClass 和 Gateway，应用开发者只管理 HTTPRoute，职责清晰，权限可控。
与传统 Ingress 的区别
传统 Ingress API（networking.k8s.io/v1）自 Kubernetes 1.19 进入稳定版，但在生产实践中暴露出多个结构性缺陷。下表从六个维度对比两者的核心差异：
| 对比维度 | 传统 Ingress | Gateway API |
|---|---|---|
| 资源模型 | 单一资源，所有规则平铺 | 分层资源（GatewayClass → Gateway → Route），职责分离 |
| 角色划分 | 无角色概念，运维与开发共用同一资源 | 面向角色：平台管理员、集群管理员、应用开发者各司其职 |
| 协议支持 | 仅 HTTP/HTTPS，扩展需注解 | 原生支持 HTTP、HTTPS、TCP、UDP、gRPC、TLS 直通 |
| 跨命名空间 | 默认不支持，需注解或自定义方案 | 通过 ReferenceGrant 显式授权，安全可控 |
| 流量分割 | 无原生支持，依赖注解或第三方 CRD | 原生支持权重路由、Header 匹配、镜像流量 |
| 扩展性 | 通过注解扩展，无类型安全 | 通过 Policy Attachment 机制，类型安全且可组合 |
迁移建议：如果当前集群使用 Nginx Ingress Controller 且路由规则简单，可继续使用 Ingress。若涉及多协议、跨命名空间、灰度发布或精细流量治理，应优先评估 Gateway API。
Gateway API 的核心优势
Gateway API 的设计哲学围绕 可组合性、角色分离 和 可移植性 展开，具体优势如下：
- 面向角色的资源模型 — 每个角色只操作自己职责范围内的资源，减少误操作风险。平台管理员定义 GatewayClass，集群管理员部署 Gateway，应用开发者编写 HTTPRoute。
- 原生多协议支持 — 不再局限于 HTTP/HTTPS，通过 Route 类型扩展支持 TCPRoute、UDPRoute、TLSRoute、GRPCRoute，覆盖南北向和东西向流量。
- 强类型与声明式 — 所有字段都是结构化 Schema，无需注解字符串拼凑，IDE 自动补全、CRD 校验、控制器准入控制均能提前拦截错误。
- 跨命名空间安全引用 — ReferenceGrant 提供显式授权模型，避免 Ingress 中“跨命名空间引用”的安全漏洞。
- 流量治理原生内置 — 权重路由、请求镜像、超时、重试、健康检查等能力直接定义在 Route 资源中，无需额外 CRD 或注解。
- 可移植性 — 规范由社区统一维护，不同实现（Istio、Contour、Nginx、Traefik）遵循同一资源模型，迁移成本大幅降低。
注意：Gateway API 目前处于 GA 阶段（v1.0+），但不同控制器的实现成熟度存在差异。生产环境选型时，请确认目标控制器对 HTTPRoute、TLSRoute、ReferenceGrant 等资源的支持状态。