2. 核心资源模型:GatewayClass、Gateway、HTTPRoute、ReferenceGrant、TLSRoute、TCPRoute、UDPRoute

Gateway API 的核心资源模型由七个关键 CRD(Custom Resource Definition)构成,它们共同定义了从集群入口到后端服务的完整流量治理路径。理解这些资源之间的层级关系、职责边界以及协同方式,是进行 Helm 参数化配置与测试验证的基础。

2.1 资源模型总览与层级关系

Gateway API 采用分层抽象设计,将基础设施提供者、集群运维人员和应用开发者的关注点分离。核心资源分为三个层级:

  • 基础设施层:GatewayClass — 定义由哪个控制器(如 Istio、Contour、NGINX)实现。
  • 集群管理层:Gateway — 代表一个具体的负载均衡器或代理实例,关联到 GatewayClass。
  • 应用路由层:HTTPRoute、TLSRoute、TCPRoute、UDPRoute — 定义流量如何从 Gateway 转发到后端 Service。

此外,ReferenceGrant 作为安全跨命名空间引用的授权机制,允许路由规则引用其他命名空间中的后端服务。

关键概念:Gateway API 的核心理念是“声明式路由”。运维人员定义 Gateway 的监听端口与 TLS 配置,应用开发者通过 Route 资源声明流量匹配规则和后端转发目标,两者通过 parentRef 字段建立关联。
Gateway API 核心资源模型层级架构 GatewayClass 定义控制器实现(如 istio.io/gateway-controller) Gateway 监听器(listeners):端口、协议、TLS、允许的路由类型 关联 GatewayClass,绑定到具体负载均衡器实例 Route 资源(通过 parentRef 关联 Gateway) HTTPRoute TLSRoute TCPRoute UDPRoute 后端 Service(目标 Pod) 由 Route 的 backendRefs 指定,支持跨命名空间 ReferenceGrant 授权跨命名空间引用:允许 Route 引用其他命名空间的 Service 或 Gateway 引用其他命名空间的 Secret

2.2 GatewayClass — 基础设施入口

GatewayClass 是集群范围的资源,类似于 StorageClass 在存储领域的角色。它声明了一种可用的网关实现,并指定由哪个控制器负责处理该类的 Gateway 实例。

字段 类型 说明
spec.controllerName string 控制器名称,格式如 istio.io/gateway-controller 或 projectcontour.io/gateway-controller
spec.parametersRef Object 可选,引用一个包含实现特定配置的参数对象(如 ConfigMap)
spec.description string 人类可读的描述信息
测试验证要点:验证 GatewayClass 是否被控制器识别,可通过 kubectl get gatewayclass 查看 ACCEPTED 状态是否为 True。Helm 参数化时,通常将 controllerName 作为全局变量暴露。

2.3 Gateway — 网关实例

Gateway 是命名空间范围的资源,代表一个具体的负载均衡器或代理实例。它定义了监听端口、协议类型、TLS 配置以及允许关联的路由类型。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: Same
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-tls-secret
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: All
字段 说明
spec.gatewayClassName 引用一个 GatewayClass,决定由哪个控制器实现
spec.listeners[].protocol 监听协议:HTTP、HTTPS、TLS、TCP、UDP
spec.listeners[].tls TLS 配置,包括模式(Terminate/Passthrough)和证书引用
spec.listeners[].allowedRoutes 限制哪些命名空间和路由类型可以关联到此监听器
常见陷阱:Gateway 的 listeners[].allowedRoutes.namespaces.from 默认为 Same,即只允许同命名空间的 Route 关联。跨命名空间路由需要显式设置为 All 或使用 Selector,并配合 ReferenceGrant 授权。

2.4 HTTPRoute — 七层路由核心

HTTPRoute 是使用最频繁的路由资源,用于定义 HTTP/HTTPS 流量的匹配规则、转发目标和高级策略(如重定向、重写、镜像)。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-http-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
    sectionName: http
  hostnames:
  - "example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 8080
      weight: 90
    - name: api-service-canary
      port: 8080
      weight: 10
  - matches:
    - path:
        type: Exact
        value: /healthz
    backendRefs:
    - name: health-service
      port: 8080
字段 说明
spec.parentRefs 关联到 Gateway 的某个监听器(通过 name 和可选的 sectionName)
spec.hostnames 匹配的域名列表,支持通配符(如 *.example.com)
spec.rules[].matches 匹配条件:路径(PathPrefix/Exact/RegularExpression)、Header、QueryParam、Method
spec.rules[].backendRefs 后端服务引用列表,支持权重分配(灰度发布)和跨命名空间引用
spec.rules[].filters 请求/响应过滤器:重定向、重写、添加Header、镜像流量等
Helm 参数化建议:将 hostnames、matches 路径、backendRefs 的服务名称和权重作为 values.yaml 中的动态参数,支持多环境差异化配置。

2.5 TLSRoute — 四层 TLS 代理

TLSRoute 用于处理 TLS 透传(Passthrough)或 TLS 终止(Terminate)场景下的流量路由。它基于 SNI(Server Name Indication)进行匹配,适用于需要保持 TLS 连接端到端加密的场景。

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name: my-tls-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
    sectionName: tls-passthrough
  hostnames:
  - "secure-app.example.com"
  rules:
  - backendRefs:
    - name: secure-app-service
      port: 443
字段 说明
spec.hostnames SNI 匹配规则,支持通配符
spec.rules[].backendRefs 后端服务引用,通常指向 TLS 终结点的 Service
测试验证要点:TLSRoute 的验证需要检查 SNI 匹配是否正确。使用 openssl s_client -connect <gateway-ip>:443 -servername secure-app.example.com 测试 TLS 握手是否成功转发到后端。

2.6 TCPRoute 与 UDPRoute — 四层协议路由

TCPRoute 和 UDPRoute 分别用于处理 TCP 和 UDP 协议的流量路由,适用于数据库连接、DNS 查询、Syslog 等非 HTTP 协议场景。

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: my-tcp-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
    sectionName: tcp
  rules:
  - backendRefs:
    - name: database-service
      port: 3306
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: UDPRoute
metadata:
  name: my-udp-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
    sectionName: udp
  rules:
  - backendRefs:
    - name: dns-service
      port: 53
资源 协议 匹配方式 典型场景
TCPRoute TCP 基于端口(由 Gateway 监听器定义) 数据库连接、Redis、Memcached、SSH
UDPRoute UDP 基于端口(由 Gateway 监听器定义) DNS、Syslog、NTP、DHCP
注意事项:TCPRoute 和 UDPRoute 不支持 HTTPRoute 中的复杂匹配规则(路径、Header 等),仅基于目标端口进行转发。Helm 参数化时,通常将 backendRefs 的服务名称和端口作为核心参数。

2.7 ReferenceGrant — 跨命名空间授权

ReferenceGrant 是 Gateway API 中实现安全跨命名空间引用的关键资源。它允许一个命名空间中的资源(如 Route)引用另一个命名空间中的资源(如 Service 或 Secret)。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-route-to-service
  namespace: backend-ns
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: frontend-ns
  to:
  - group: ""
    kind: Service
字段 说明
spec.from 指定哪些来源(group、kind、namespace)可以发起跨命名空间引用
spec.to 指定允许被引用的目标资源类型(group、kind)
最佳实践:ReferenceGrant 应遵循最小权限原则,只允许必要的命名空间和资源类型。在 Helm 部署中,ReferenceGrant 通常与 Route 资源一起打包,确保跨命名空间引用在部署时自动授权。
跨命名空间路由与 ReferenceGrant 交互流程 命名空间:frontend-ns 命名空间:backend-ns HTTPRoute parentRef: my-gateway Gateway 监听器 http:80 Service: api-service 端口 8080,选择器 app=api ReferenceGrant 允许 frontend-ns/HTTPRoute 引用 Service backendRefs 授权 跨命名空间引用流程 1. HTTPRoute 通过 backendRefs 引用 backend-ns 的 Service 2. ReferenceGrant 在 backend-ns 中授权该引用 3. 控制器验证授权后,将流量转发到目标 Service

2.8 资源模型测试验证清单

在 Helm 参数化部署后,需要针对每个核心资源进行验证。以下清单覆盖了关键验证点:

资源 验证项 验证方法
GatewayClass ACCEPTED 状态为 True kubectl get gatewayclass -o jsonpath='{.items[*].status.conditions[?(@.type=="Accepted")].status}'
Gateway PROGRAMMED 状态为 True,监听器 Ready kubectl get gateway my-gateway -o jsonpath='{.status.conditions[?(@.type=="Programmed")].status}'
HTTPRoute RESOLVED 状态为 True,后端引用有效 kubectl get httproute my-route -o jsonpath='{.status.parents[*].conditions[?(@.type=="ResolvedRefs")].status}'
TLSRoute SNI 匹配正确,TLS 握手成功 openssl s_client 测试 + 后端日志验证
TCPRoute 端口转发正确,连接可达 nc -zv <gateway-ip> <port>
UDPRoute UDP 数据包正确转发 使用 nping --udp 或应用层协议测试
ReferenceGrant 跨命名空间引用被授权 检查 Route 的 ResolvedRefs 条件,无跨命名空间拒绝错误
自动化测试建议:将上述验证命令集成到 Helm 测试钩子(test hooks)中,使用 helm test 命令自动执行。对于 HTTPRoute,可以进一步使用 curl 验证响应状态码和内容;对于 TLSRoute,使用 openssl s_client 验证证书链。