Kubernetes Gateway API-4-TCPRoute和GRPCRoute

1 TCPRoute

目前 TCP routing 还处于实验阶段。

Gateway API 被设计为与多个协议一起工作，TCPRoute 就是这样一个允许管理TCP流量的路由。

在这个例子中，我们有一个 Gateway 资源和两个 TCPRoute 资源，它们按照以下规则分配流量：

网关端口 8080 上的所有TCP流都被转发到 Kubernetes service my-foo-service 的端口 6000。
网关端口 8090 上的所有TCP流都被转发到 Kubernetes service my-bar-service 的端口 6000。

在这个例子中，两个 TCP 侦听器将应用于网关，以便将它们路由到两个单独的后端 TCPRoutes，请注意，Gateway 上为 listeners 设置的协议是TCP：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:name: my-tcp-gateway
spec:gatewayClassName: my-tcp-gateway-classlisteners:- name: fooprotocol: TCPport: 8080allowedRoutes:kinds:- kind: TCPRoute- name: barprotocol: TCPport: 8090allowedRoutes:kinds:- kind: TCPRoute
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:name: tcp-app-1
spec:parentRefs:- name: my-tcp-gatewaysectionName: foorules:- backendRefs:- name: my-foo-serviceport: 6000
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:name: tcp-app-2
spec:parentRefs:- name: my-tcp-gatewaysectionName: barrules:- backendRefs:- name: my-bar-serviceport: 6000

在上面的示例中，我们使用 parentRefs 中的 sectionName 字段将两个单独后端服务的 TCP流量分开：

spec:parentRefs:- name: my-tcp-gatewaysectionName: foo

这与 Gateway 中 listeners 中 name 字段的值直接对应：

  listeners:- name: fooprotocol: TCPport: 8080- name: barprotocol: TCPport: 8090

通过这种方式，每个 TCPRoute 都把自己“固定”到 Gateway 上的不同端口，这样 my-foo-service 就可以从集群外部获取端口 8080 的流量，而 my-bar-service 则可以获取端口 8090 的流量。

2 GRPCRoute

GRPCRoute 资源目前仅处于实验阶段。

GRPCRoute 资源允许您匹配 gRPC 流量并将其定向到 Kubernetes 后端。本指南展示了 GRPCRoute 如何匹配主机、标头和服务以及方法字段上的流量，并将其转发到不同的 Kubernetes 服务。

2.1 通用示例

为了从网关接收流量，必须使用 ParentRefs 配置 GRPCRoute 资源，ParentRefs 引用它应该连接到的父网关。以下示例显示了如何配置 Gateway 和 GRPCRoute 的组合来为gRPC流量提供服务：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:name: example-gateway
spec:gatewayClassName: example-gateway-classlisteners:- name: grpcprotocol: HTTPSport: 50051tls:certificateRefs:- kind: Secretgroup: ""name: example-com-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:name: example-route
spec:parentRefs:- name: example-gatewayhostnames:- "example.com"rules:- backendRefs:- name: example-svcport: 50051

2.2 具体实例

下图描述了三种不同服务之间所需的流量：

对 foo.example.com 的 com.example.User.Login 方法的流量被转发到 foo-svc
带有 env: canary 头的流量被转发到 bar-svc-canary，适用于所有服务和方法
没有该头的流量被转发到 bar-svc，适用于所有服务和方法

一个 GRPCRoute 可以匹配一组单独的主机名。这些主机名在 GRPCRoute 中进行其他匹配之前就已经被匹配。由于 foo.example.com 和 bar.example.com 是具有不同路由需求的独立主机，因此每个主机都作为其自己的 GRPCRoute 部署——foo-route 和 bar-route。

以下的 foo-route 将匹配任何针对 foo.example.com 的流量，并应用其路由规则将流量转发到正确的后端。由于只指定了一个匹配，因此只有对 foo.example.com 的 com.example.User.Login 方法的请求会被转发。任何其他方法的 RPC 将不会被此路由匹配。

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:name: foo-route
spec:parentRefs:- name: example-gatewayhostnames:- "foo.example.com"rules:- matches:- method:service: com.examplemethod: LoginbackendRefs:- name: foo-svcport: 50051

同样,如下所示，bar-route GRPCRoute 匹配 bar.example.com 的 RPC。所有针对该主机名的流量将根据路由规则进行评估。最具体的匹配将优先考虑，这意味着任何带有 env: canary 头部的流量将被转发到 bar-svc-canary；如果该头部缺失或没有值 canary，则流量将被转发到 bar-svc。

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:name: bar-route
spec:parentRefs:- name: example-gatewayhostnames:- "bar.example.com"rules:- matches:- headers:- type: Exactname: envvalue: canarybackendRefs:- name: bar-svc-canaryport: 50051- backendRefs:- name: bar-svcport: 50051

gRPC 反射是使用交互式客户端（如 grpcurl）所必需的，前提是你的本地文件系统中没有目标服务的协议缓冲区的本地副本。要启用此功能，首先确保在你的应用程序 Pod 上有一个 gRPC 反射服务器在监听，然后将反射方法添加到你的 GRPCRoute，配置实例如下。这在开发和预生产环境中可能会很有用，但在生产环境中启用此功能时，应在考虑安全隐患后再进行。

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:name: foo-route
spec:parentRefs:- name: example-gatewayhostnames:- "foo.example.com"rules:- matches:- method:service: com.example.Usermethod: LoginbackendRefs:- name: foo-svcport: 50051- matches:- method:service: grpc.reflection.v1.ServerReflectionbackendRefs:- name: foo-svcport: 50051