Gateway API 基础回顾：核心概念、与传统 Ingress 的对比及架构优势

在深入延迟诊断之前，必须先厘清 Gateway API 的核心抽象层。与 Kubernetes 原生 Ingress 的“扁平化”路由规则不同，Gateway API 通过 GatewayClass、Gateway、HTTPRoute 三层模型，将基础设施提供方、集群运维方和应用开发方的职责解耦。这种分层设计直接影响了延迟链路的可观测性和资源配额的控制粒度。

2.1 核心概念：三层模型

Gateway API 的核心在于将网络配置从“单体资源”拆解为三个独立但关联的 API 对象。每一层都有明确的关注点和生命周期。

以下是一个典型的 GatewayClass 声明示例，它定义了集群中可用的网关“类型”：

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: istio-gateway-class
spec:
  controllerName: istio.io/gateway-controller
  parametersRef:
    group: ""
    kind: ConfigMap
    name: istio-gateway-params
    namespace: istio-system

而 Gateway 实例则通过 gatewayClassName 引用上述类，并绑定具体的监听端口：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: istio-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            app-tier: frontend

最后，应用团队通过 HTTPRoute 将流量绑定到 Gateway 的监听器上：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: user-service-route
  namespace: user-app
spec:
  parentRefs:
  - name: public-gateway
    namespace: gateway-infra
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /users
    backendRefs:
    - name: user-svc
      port: 8080

2.2 与传统 Ingress 的对比

Kubernetes 原生 Ingress 在 v1 时代解决了“七层路由”的从无到有问题，但在生产环境中暴露出多个痛点。Gateway API 并非简单的“升级版”，而是对网络配置模型的重新设计。

2.3 架构优势：为什么选择 Gateway API

从延迟诊断和资源配额协同的角度，Gateway API 的架构优势体现在以下四个核心方面：

1. 角色职责分离（Role-based Configuration）：平台团队管理 GatewayClass 和 Gateway 的容量与配额，应用团队只管理 HTTPRoute。这种分离避免了“配置冲突”导致的意外延迟增加。
2. 标准化状态与条件（Standardized Status）：每个 Gateway API 资源都有 status.conditions 字段，提供机器可读的“就绪”状态。延迟诊断时可以直接查询资源状态，而非解析日志。
3. 原生支持流量分割与镜像：HTTPRoute 的 backendRefs 支持权重路由和流量镜像，无需额外注解。这对于“金丝雀发布”场景下的延迟对比至关重要。
4. Policy Attachment 机制：通过 policy 资源（如 RateLimitPolicy、RetryPolicy）可以独立于路由规则附加策略，实现“配额与路由解耦”。