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 等主流云厂商和服务网格项目广泛采用。

关键里程碑:Gateway API v1.0 标志着核心路由功能(GatewayClass、Gateway、HTTPRoute)进入 GA 阶段,而 GRPCRoute、TCPRoute、TLSRoute 等扩展协议仍在 beta 阶段。

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,生态快速扩展
迁移建议:如果你的集群仅需要简单的七层路由且团队规模较小,Ingress 仍然可用。但若涉及多协议、多团队协作或需要精细化流量管理,Gateway API 是更优的选择。

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
注意:HTTPRoute 通过 parentRefs 关联 Gateway,且支持跨命名空间引用。这要求集群中已部署 RBAC 规则允许跨命名空间绑定。

1.4 核心架构关系图

下图展示了 GatewayClass、Gateway 和 HTTPRoute 之间的分层关系以及角色职责:

Gateway API 核心架构关系图 Gateway API 核心架构关系图 GatewayClass 集群级别 · 定义网关实现 引用 Gateway 命名空间级别 · 监听端口、TLS、主机名 parentRefs HTTPRoute 命名空间级别 · 匹配规则、后端引用、流量策略 backendRefs Backend Service (Pod) 基础设施团队 定义 GatewayClass 管理 Gateway 实例 配置 TLS 证书 应用团队 定义 HTTPRoute 配置路由规则 管理后端服务

1.5 核心概念对比总结

资源 作用域 创建者 核心职责 示例
GatewayClass 集群 平台管理员 注册网关实现(如 Istio、Contour) istio, contour, aws-alb
Gateway 命名空间 基础设施团队 暴露监听端口、配置 TLS、绑定 GatewayClass my-gateway, public-gw
HTTPRoute 命名空间 应用团队 定义 HTTP 路由规则、后端服务、流量策略 app-route, canary-route
最佳实践:建议将 Gateway 部署在独立的 infra 或 gateway 命名空间中,而 HTTPRoute 由各业务团队在自己的命名空间中管理。通过 RBAC 限制跨命名空间的 parentRefs 权限,实现安全的多租户隔离。