📚 课程目录第2章延迟基础概念

Gateway API 概述：架构、核心资源与传统 Ingress 对比

Gateway API 是 Kubernetes 社区在服务网络领域的一次重要演进，旨在解决传统 Ingress 在表达能力、可扩展性和角色划分上的局限性。本章从架构设计、核心资源模型以及与 Ingress 的对比三个维度，建立对 Gateway API 的完整认知，为后续延迟诊断与性能调优奠定基础。

一、Gateway API 架构设计

Gateway API 采用分层解耦的架构思想，将网络配置的责任划分为三个独立角色：基础设施提供者（Infrastructure Provider）、集群管理员（Cluster Operator）和应用开发者（Application Developer）。这种角色分离使得不同团队可以独立管理各自关注的配置层面，减少配置冲突和权限扩散。

下图展示了 Gateway API 的核心架构与资源关系：

架构要点：Gateway API 的三层角色模型与 Kubernetes RBAC 天然契合。基础设施提供者通常对应平台工程团队，集群管理员对应 SRE 或运维团队，应用开发者对应业务研发团队。每一层只关注自己职责范围内的资源，降低了配置耦合度。

二、核心资源模型

Gateway API 定义了三个核心资源：GatewayClass、Gateway 和 HTTPRoute（以及 TCPRoute、TLSRoute 等）。它们共同构成了从“实现声明”到“流量转发”的完整链路。

2.1 GatewayClass

GatewayClass 是集群级别的资源，用于声明可用的网关实现类型。它类似于 StorageClass 在存储领域的角色，定义了网关的控制器名称、参数引用和默认配置。

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx-gateway-class
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
  parametersRef:
    group: gateway.networking.k8s.io
    kind: GatewayClassParameters
    name: nginx-params

2.2 Gateway

Gateway 资源代表一个具体的网关实例，由集群管理员创建。它定义了监听器（Listener）的端口、协议、TLS 配置以及允许绑定的命名空间范围。Gateway 通过 gatewayClassName 字段引用 GatewayClass。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: nginx-gateway-class
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: prod-tls-cert
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            environment: production

2.3 HTTPRoute

HTTPRoute 是应用开发者最常操作的资源，用于定义 HTTP 流量的匹配规则和后端转发目标。它支持主机名匹配、路径匹配、HTTP 方法匹配、Header 匹配以及权重路由等高级特性。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: app-team
spec:
  parentRefs:
  - name: prod-gateway
    namespace: gateway-infra
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1/users
    backendRefs:
    - name: user-svc
      port: 8080
      weight: 90
    - name: user-svc-canary
      port: 8080
      weight: 10
  - matches:
    - path:
        type: PathPrefix
        value: /v1/orders
    backendRefs:
    - name: order-svc
      port: 8080

2.4 Service 资源的关系

在 Gateway API 模型中，Service 仍然是后端工作负载的抽象层。HTTPRoute 的 backendRefs 直接引用 Service 名称和端口，Gateway 本身不直接管理 Pod。这种设计保持了与 Kubernetes 原生 Service 模型的兼容性，同时允许未来扩展为直接引用 Pod 或自定义后端。

资源	作用域	创建者	核心职责
GatewayClass	集群	基础设施提供者	声明网关实现类型与控制器
Gateway	命名空间	集群管理员	配置监听器、TLS、端口与访问策略
HTTPRoute	命名空间	应用开发者	定义流量匹配规则与后端转发
Service	命名空间	应用开发者	暴露 Pod 网络端点，作为路由后端

三、与传统 Ingress 的对比

传统 Ingress 自 Kubernetes 1.1 引入以来，一直是南北向流量的主要入口。但随着服务网格和多集群架构的普及，Ingress 的局限性日益凸显。Gateway API 在设计上对 Ingress 进行了全面升级。

下图从资源模型、角色划分和扩展性三个维度对比两者的差异：

  关键对比结论：
  角色分离：Ingress 将网关配置和路由规则写在一个资源中，Gateway API 通过 GatewayClass / Gateway / HTTPRoute 三层解耦，每个角色只管理自己关心的部分。
协议扩展：Ingress 仅支持 HTTP/HTTPS，Gateway API 原生支持 TCP、TLS、UDP 和 gRPC，适合微服务、服务网格和 IoT 场景。
流量治理：Gateway API 内置权重路由、Header 匹配、重定向、请求镜像等高级特性，Ingress 需要依赖 Annotation 或自定义 CRD 实现。
安全边界：Gateway API 通过 ReferenceGrant 控制跨命名空间引用，TLS 在监听器级别统一配置，避免路由级别的安全配置遗漏。

四、Gateway API 在延迟诊断中的意义

从性能工程角度看，Gateway API 的分层模型为延迟诊断提供了更清晰的故障域隔离：

Gateway 层：监听器配置、TLS 握手、连接池管理直接影响入口延迟。诊断时优先检查 Gateway 的 TLS 证书有效性、监听器超时设置和连接数限制。
HTTPRoute 层：路由匹配规则的数量和复杂度影响请求处理路径。过多的匹配规则（尤其是正则匹配）会增加路由查找延迟。
Service 层：后端 Service 的负载均衡策略、端点健康状态和 Pod 资源利用率是延迟的最终瓶颈。

性能陷阱提示：Gateway API 的灵活性也可能引入性能风险。例如，在 HTTPRoute 中配置大量细粒度的 Header 匹配规则，或在 Gateway 中开启过多的监听器，都会增加网关控制面的配置下发延迟和数据面的规则匹配开销。在性能调优时，需要平衡表达能力和处理效率。