1. Gateway API 概述:起源、对比与核心概念
Gateway API 是 Kubernetes 社区在 2020 年正式启动的下一代入口流量管理标准,旨在解决传统 Ingress 资源在表达能力、多团队协作和协议扩展上的根本性局限。本章从起源、与 Ingress 的对比以及三大核心概念入手,帮助你建立对 Gateway API 的完整认知。
1.1 Gateway API 的起源
Kubernetes 自 1.1 版本引入 Ingress 资源以来,社区逐渐发现其设计存在以下痛点:
- 表达能力有限:Ingress 仅支持 HTTP/HTTPS 七层路由,无法原生处理 TCP、UDP、gRPC 或 TLS 透传。
- 厂商锁定严重:Ingress 规范过于简单,大量功能依赖注解(annotations),导致不同 Ingress Controller 的配置方式差异巨大,迁移成本高。
- 缺乏角色分离:基础设施团队和应用团队共享同一个 Ingress 资源,权限边界模糊,容易产生配置冲突。
- 无标准化状态反馈:Ingress 资源没有统一的 status 字段来描述路由是否生效、证书是否有效等运行时状态。
为解决上述问题,SIG-NETWORK 在 2020 年提出了 Gateway API(当时称为 Service APIs),经过多个 alpha 和 beta 版本的迭代,于 2023 年 10 月发布了 v1.0 正式版。目前 Gateway API 已被 AWS、Google Cloud、Istio、Contour、Traefik 等主流云厂商和服务网格项目广泛采用。
1.2 Gateway API 与 Ingress 的对比
下表从多个维度对比 Ingress 与 Gateway API 的核心差异:
| 对比维度 | Ingress | Gateway API |
|---|---|---|
| 协议支持 | 仅 HTTP/HTTPS | HTTP、HTTPS、gRPC、TCP、UDP、TLS 透传 |
| 角色分离 | 无,所有配置集中在单一资源 | 基础设施(GatewayClass/Gateway)与应用(Route)分离 |
| 扩展机制 | 依赖注解,无标准化 | Policy Attachment、BackendRef 扩展、自定义 Route |
| 状态反馈 | 无统一 status | 丰富的 status 条件,支持 listeners、routes、addresses 状态 |
| 跨命名空间 | 不支持 | 原生支持跨命名空间路由引用 |
| 流量分割 | 需额外 CRD 或注解 | 原生支持权重路由、镜像、请求头修改 |
| 成熟度 | 稳定但功能受限 | v1.0 GA,生态快速扩展 |
1.3 三大核心概念
Gateway API 围绕三个核心资源构建:GatewayClass、Gateway 和 HTTPRoute。它们共同构成了一个分层、角色分离的流量管理模型。
1.3.1 GatewayClass
GatewayClass 是集群级别的资源,定义了可用的网关实现(如 Istio、Contour、AWS ALB)。它类似于 IngressClass,但更强调实现的可发现性和参数标准化。
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: istio
spec:
controllerName: istio.io/gateway-controller
parametersRef:
group: example.com/v1
kind: IstioParams
name: istio-config
1.3.2 Gateway
Gateway 是命名空间级别的资源,代表一个具体的网关实例。它定义了监听端口、协议、TLS 配置以及关联的 GatewayClass。
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-gateway
namespace: infra
spec:
gatewayClassName: istio
listeners:
- name: https
port: 443
protocol: HTTPS
hostname: "*.example.com"
tls:
mode: Terminate
certificateRefs:
- name: example-cert
1.3.3 HTTPRoute
HTTPRoute 是应用团队使用的资源,定义了 HTTP 流量的路由规则,包括匹配条件、后端服务和高级流量管理策略。
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: app-route
namespace: apps
spec:
parentRefs:
- name: my-gateway
namespace: infra
rules:
- matches:
- path:
type: PathPrefix
value: /api
backendRefs:
- name: api-service
port: 8080
weight: 90
- name: api-service-canary
port: 8080
weight: 10
parentRefs 关联 Gateway,且支持跨命名空间引用。这要求集群中已部署 RBAC 规则允许跨命名空间绑定。
1.4 核心架构关系图
下图展示了 GatewayClass、Gateway 和 HTTPRoute 之间的分层关系以及角色职责:
1.5 核心概念对比总结
| 资源 | 作用域 | 创建者 | 核心职责 | 示例 |
|---|---|---|---|---|
| GatewayClass | 集群 | 平台管理员 | 注册网关实现(如 Istio、Contour) | istio, contour, aws-alb |
| Gateway | 命名空间 | 基础设施团队 | 暴露监听端口、配置 TLS、绑定 GatewayClass | my-gateway, public-gw |
| HTTPRoute | 命名空间 | 应用团队 | 定义 HTTP 路由规则、后端服务、流量策略 | app-route, canary-route |
infra 或 gateway 命名空间中,而 HTTPRoute 由各业务团队在自己的命名空间中管理。通过 RBAC 限制跨命名空间的 parentRefs 权限,实现安全的多租户隔离。