2. 核心概念：Gateway API 资源模型与 Ingress 对比

Gateway API 是 Kubernetes 社区下一代入口网关标准，其核心设计理念是角色分离与声明式路由。与传统的 Ingress 资源相比，Gateway API 将网络配置拆解为三个独立的资源层：GatewayClass、Gateway 和 HTTPRoute。这种分层模型让基础设施管理员、集群运维人员和应用开发者各司其职，避免权限越界和配置冲突。

2.1 三层资源模型详解

2.1.1 GatewayClass — 基础设施抽象

GatewayClass 是集群范围的资源，由基础设施提供商（如云厂商、硬件设备商）或集群管理员定义。它描述了一类网关的实现方式，类似于 StorageClass 对存储后端的抽象。

• 作用：定义网关的控制器名称、参数引用（如负载均衡器规格、网络插件配置）。
• 作用域：集群级别，不可跨命名空间。
• 典型字段：spec.controllerName（控制器标识）、spec.parametersRef（可选参数引用）。

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: my-lb-gateway-class
spec:
  controllerName: "example.com/my-lb-controller"
  parametersRef:
    group: "example.com"
    kind: "LBParams"
    name: "my-lb-config"

2.1.2 Gateway — 网关实例声明

Gateway 是命名空间级别的资源，由集群运维人员或平台团队创建。它代表一个具体的网关实例（如负载均衡器、API 网关），并绑定到某个 GatewayClass。

• 作用：定义监听器（Listener）的协议、端口、TLS 配置，以及允许哪些命名空间的路由绑定到该网关。
• 作用域：命名空间级别，可跨命名空间引用路由。
• 关键字段：spec.gatewayClassName、spec.listeners（协议、端口、主机名、TLS）、spec.addresses（可选固定 IP）。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: infra
spec:
  gatewayClassName: my-lb-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            app-tier: frontend
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-tls-cert

2.1.3 HTTPRoute — 应用路由规则

HTTPRoute 是命名空间级别的资源，由应用开发者或服务所有者编写。它定义了 HTTP 流量的匹配条件、转发目标、重定向、重写等行为，并绑定到指定的 Gateway。

• 作用：声明式定义流量路由规则，支持路径匹配、Header 匹配、权重分发、镜像流量等高级特性。
• 作用域：命名空间级别，通过 spec.parentRefs 绑定到 Gateway。
• 关键字段：spec.parentRefs（绑定目标 Gateway）、spec.hostnames、spec.rules（匹配条件 + 后端服务）。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: app
spec:
  parentRefs:
  - name: my-gateway
    namespace: infra
  hostnames:
  - "myapp.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api/v1
    backendRefs:
    - name: api-service-v1
      port: 8080
      weight: 90
    - name: api-service-v2
      port: 8080
      weight: 10

2.2 三层资源协作关系

下图展示了 GatewayClass、Gateway、HTTPRoute 之间的引用与绑定关系，以及各层对应的角色职责。

2.3 与传统 Ingress 的对比

传统 Ingress 资源将所有配置（监听器、路由规则、TLS 证书）塞进一个资源对象中，导致以下问题：

• 角色耦合：集群管理员和应用开发者的配置混在一起，权限难以隔离。
• 扩展性差：Ingress 规范只支持基础的路由匹配，高级特性（如流量拆分、Header 修改、重定向）依赖注解，不同实现注解不兼容。
• 跨命名空间困难：Ingress 默认只能引用同命名空间的后端 Service，跨命名空间需要额外配置。

下表从多个维度对比 Gateway API 与传统 Ingress 的差异：

2.4 为什么 Gateway API 更适合流量回滚护栏

在流量回滚场景中，我们需要精细控制流量切分的粒度、速率和条件。Gateway API 的 HTTPRoute 原生支持以下能力，这些能力是传统 Ingress 难以实现的：

• 权重分发：通过 backendRefs[].weight 实现蓝绿部署和金丝雀发布，回滚时只需调整权重比例。
• 基于 Header 的匹配：可以针对特定用户、测试流量或内部请求进行路由，实现灰度验证。
• 镜像流量：将实时流量复制到新版本，用于观察而不影响线上用户。
• 策略绑定：通过 PolicyAttachment 机制，可以附加限流、重试、熔断等策略，形成完整的回滚护栏。

2.5 资源模型与回滚护栏的映射

下图展示了 Gateway API 三层资源如何映射到流量回滚护栏架构中的不同组件：