📚 课程目录第2章 Gateway基础架构

Gateway API资源限额与弹性容量治理 - 第2节

Gateway API 核心概念：GatewayClass、Gateway、HTTPRoute

Gateway API 是 Kubernetes 社区在 1.0 版本后正式推出的下一代入口流量管理标准。与传统的 Ingress 资源相比，Gateway API 通过 面向角色 的抽象模型，将基础设施提供者、集群运维者和应用开发者的职责清晰分离。其核心由三个顶级资源构成：GatewayClass、Gateway 和 HTTPRoute。

  核心原则：Gateway API 采用“声明式 + 分层”设计。基础设施提供者定义 GatewayClass，集群运维者实例化 Gateway，应用开发者通过 Route 绑定服务。每一层只关注自己职责范围内的配置，互不侵入。

1.1 GatewayClass —— 基础设施的抽象模板

GatewayClass 类似于 Ingress 中的 IngressClass，但语义更明确。它描述了一类由特定控制器（如 Istio、Contour、NGINX Gateway Fabric）实现的网关能力。一个 GatewayClass 通常对应一种负载均衡器或代理实现。

字段	说明	示例值
`spec.controllerName`	控制器标识，决定由哪个实现处理该 GatewayClass	`istio.io/gateway-controller`
`spec.parametersRef`	可选，引用自定义参数配置（如负载均衡器规格）	`kind: ConfigMap`
`spec.description`	人类可读的描述信息	`生产环境 Istio 网关`

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: istio-prod
spec:
  controllerName: istio.io/gateway-controller
  description: "生产环境 Istio 网关，启用 mTLS 与熔断"

1.2 Gateway —— 集群入口的实例化

Gateway 是 GatewayClass 的具体实例，代表一个运行中的负载均衡器或代理端点。它定义了监听地址、端口、TLS 配置以及关联的 GatewayClass。一个 Gateway 可以绑定多个 Route 资源。

字段	说明	示例值
`spec.gatewayClassName`	引用的 GatewayClass 名称	`istio-prod`
`spec.listeners`	监听器列表，包含协议、端口、主机名、TLS 配置	`HTTP/HTTPS`
`spec.addresses`	可选，指定静态 IP 或主机名	`192.168.1.100`

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: istio-prod
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-tls

1.3 HTTPRoute —— 流量路由的声明式规则

HTTPRoute 是应用开发者最常接触的资源。它定义了 HTTP 请求如何匹配（主机名、路径、Header、查询参数）以及如何转发到后端 Service。HTTPRoute 通过 parentRefs 字段绑定到一个或多个 Gateway。

字段	说明	示例值
`spec.parentRefs`	绑定到的 Gateway 名称/命名空间	`prod-gateway`
`spec.hostnames`	匹配的域名列表	`["api.example.com"]`
`spec.rules`	路由规则，包含匹配条件与后端转发	`path: /v1/*`

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: applications
spec:
  parentRefs:
  - name: prod-gateway
    namespace: gateway-infra
  hostnames: ["api.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1/
    backendRefs:
    - name: api-service-v1
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /v2/
    backendRefs:
    - name: api-service-v2
      port: 8080

延迟诊断视角：HTTPRoute 的匹配规则顺序直接影响路由决策延迟。当规则数量超过 50 条时，建议使用 matches 优先级排序，避免正则表达式过度使用。

Gateway API 核心资源关系图

下图展示了 GatewayClass、Gateway、HTTPRoute 三者之间的分层绑定关系，以及它们与底层控制器、后端 Service 的交互流程。

与传统 Ingress 的对比

传统 Ingress 在早期 Kubernetes 生态中解决了基本的 HTTP 路由需求，但随着云原生架构的演进，其局限性日益明显。Gateway API 在设计上对 Ingress 进行了全面升级。以下从多个维度进行对比：

对比维度	传统 Ingress	Gateway API
资源模型	单一资源，所有配置集中在一个对象中	分层资源（GatewayClass → Gateway → Route），职责分离
角色分离	基础设施与业务配置混在一起	基础设施提供者、集群运维者、应用开发者各司其职
协议支持	主要支持 HTTP/HTTPS，扩展性差	原生支持 HTTP、HTTPS、TCP、UDP、TLS 终止、gRPC
路由匹配能力	仅支持主机名 + 路径前缀	支持路径、Header、查询参数、方法、权重、重定向、重写
后端流量管理	仅支持 Service 转发，无细粒度控制	支持权重分流、会话保持、健康检查、熔断、限流
跨命名空间	通常限制在同一命名空间	原生支持跨命名空间 Route 绑定 Gateway
扩展性	依赖 Annotation 扩展，无标准接口	通过 Policy Attachment 和自定义 Filter 标准化扩展
延迟诊断能力	无内置指标，依赖第三方	标准 Status 条件、Conditions 字段，便于监控与排障

迁移注意：虽然 Gateway API 提供了向后兼容的 Ingress 迁移路径，但直接替换时需注意 TLS 配置模型差异。Ingress 的 TLS 在 spec 顶层定义，而 Gateway API 的 TLS 在 listener 级别配置，且支持更细粒度的证书选择。

Gateway API 与传统 Ingress 架构对比图

下图从架构层面对比传统 Ingress 的扁平模型与 Gateway API 的分层模型，突出两者在职责边界和扩展性上的差异。

延迟诊断优势：Gateway API 的每个资源都包含 status.conditions 字段，可以精确反映资源是否被控制器接受、是否处于就绪状态。在延迟诊断场景中，运维人员可以直接通过 kubectl get gateway -o wide 查看监听器状态，无需像 Ingress 那样解析 Annotation 或日志。

小结

Gateway API 通过 GatewayClass、Gateway、HTTPRoute 三层模型，解决了传统 Ingress 在角色分离、协议扩展、路由能力和可观测性上的核心痛点。对于延迟诊断而言，分层模型带来的好处是：

故障域隔离：Gateway 层的问题不会影响 Route 配置，反之亦然。
细粒度监控：每个资源都有独立的状态和条件，便于定位瓶颈。
标准化扩展：Policy Attachment 机制使得限流、熔断等策略可以统一附加到 Route 或 Gateway 上，无需依赖非标准 Annotation。