Gateway API资源配额模型：数据传输优化实战 - 第2节

2.1 Gateway API 的起源：从 Ingress 到下一代网关标准

Kubernetes 原生 Ingress 资源自 1.1 版本引入以来，一直是南北向流量接入的事实标准。然而，随着云原生架构向多集群、多协议、精细化流量治理演进，Ingress 的局限性日益凸显。Gateway API 正是在这一背景下，由 SIG-NETWORK 于 2020 年发起，旨在构建一个更强大、更可扩展、面向角色的 API 网关标准。

Ingress 的三大痛点

Gateway API 从设计之初就明确了三个目标：面向角色（Role-oriented）、可移植（Portable）、富有表现力（Expressive）。它通过分层资源模型，将基础设施、路由策略、后端服务的管理职责解耦，让每个角色只关注自己负责的配置层。

2.2 核心概念：三层资源模型

Gateway API 的核心创新在于将传统 Ingress 的单一资源拆解为三个层次：GatewayClass（基础设施层）、Gateway（接入层）、Route（路由策略层）。这种分层设计使得不同角色的职责边界清晰，配置可组合、可复用。

2.2.1 GatewayClass —— 基础设施抽象

GatewayClass 是集群级别的资源，由基础设施管理员定义，描述了一类网关实现的规格和能力。它类似于 StorageClass 对存储的抽象，定义了网关的控制器类型、参数模板和实现版本。

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
  parametersRef:
    group: gateway.envoyproxy.io
    kind: EnvoyProxy
    name: custom-proxy-config
    namespace: envoy-gateway-system

2.2.2 Gateway —— 网络接入点

Gateway 资源代表一个具体的网络接入点，由集群运维人员管理。它定义了监听器（Listener）的协议、端口、TLS 配置，以及关联的 GatewayClass。Gateway 是流量进入集群的入口，可以对应一个负载均衡器、虚拟 IP 或 NodePort。

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

2.2.3 Route —— 流量路由策略

Route 资源由应用开发者定义，描述了如何将进入 Gateway 的流量路由到后端服务。Gateway API 定义了多种 Route 类型，覆盖不同的协议和场景：

• HTTPRoute：基于 HTTP 方法、路径、Header、Query 参数的路由，支持权重拆分、镜像、重定向
• HTTPSRoute：基于 SNI 的 TLS 路由，适用于 TLS 透传场景
• TCPRoute：基于端口和源 IP 的四层路由
• UDPRoute：基于端口的 UDP 路由
• GRPCRoute：针对 gRPC 协议优化的路由，支持 gRPC 方法匹配

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store-route
  namespace: store-app
spec:
  parentRefs:
  - name: prod-gateway
    namespace: infra-gateways
    sectionName: https
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: store-api-svc
      port: 8080
      weight: 90
    - name: store-api-canary-svc
      port: 8080
      weight: 10
  - matches:
    - path:
        type: PathPrefix
        value: /static
    backendRefs:
    - name: store-static-svc
      port: 80

2.3 与传统 Ingress 的对比

Gateway API 并非简单地替代 Ingress，而是在设计哲学、资源模型、功能覆盖和生态兼容性上进行了全面升级。以下从多个维度进行对比：

2.4 从 Ingress 迁移到 Gateway API 的策略

对于已有 Ingress 资源的集群，迁移到 Gateway API 并非一蹴而就。推荐采用渐进式迁移策略：

1. 评估阶段：梳理现有 Ingress 资源，识别使用的 Annotation 和扩展功能，确认 Gateway API 实现是否支持
2. 并行部署：在集群中同时部署 Ingress Controller 和 Gateway API 实现，将部分非关键业务迁移到 Gateway API
3. 功能验证：对比 Ingress 和 Gateway API 的路由行为，确保流量转发、TLS 终止、权重拆分等功能一致
4. 全面切换：确认 Gateway API 稳定运行后，逐步将剩余 Ingress 资源迁移，最终下线 Ingress Controller