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-class
listeners:
- name: foo
protocol: TCP
port: 8080
allowedRoutes:
kinds:
- kind: TCPRoute
- name: bar
protocol: TCP
port: 8090
allowedRoutes:
kinds:
- kind: TCPRoute
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
name: tcp-app-1
spec:
parentRefs:
- name: my-tcp-gateway
sectionName: foo
rules:
- backendRefs:
- name: my-foo-service
port: 6000
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
name: tcp-app-2
spec:
parentRefs:
- name: my-tcp-gateway
sectionName: bar
rules:
- backendRefs:
- name: my-bar-service
port: 6000
在上面的示例中,我们使用 parentRefs
中的 sectionName
字段将两个单独后端服务的 TCP流量分开:
spec:
parentRefs:
- name: my-tcp-gateway
sectionName: foo
这与 Gateway
中 listeners
中 name
字段的值直接对应:
listeners:
- name: foo
protocol: TCP
port: 8080
- name: bar
protocol: TCP
port: 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-class
listeners:
- name: grpc
protocol: HTTPS
port: 50051
tls:
certificateRefs:
- kind: Secret
group: ""
name: example-com-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
name: example-route
spec:
parentRefs:
- name: example-gateway
hostnames:
- "example.com"
rules:
- backendRefs:
- name: example-svc
port: 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-gateway
hostnames:
- "foo.example.com"
rules:
- matches:
- method:
service: com.example
method: Login
backendRefs:
- name: foo-svc
port: 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-gateway
hostnames:
- "bar.example.com"
rules:
- matches:
- headers:
- type: Exact
name: env
value: canary
backendRefs:
- name: bar-svc-canary
port: 50051
- backendRefs:
- name: bar-svc
port: 50051
gRPC 反射是使用交互式客户端(如 grpcurl)所必需的,前提是你的本地文件系统中没有目标服务的协议缓冲区的本地副本。要启用此功能,首先确保在你的应用程序 Pod 上有一个 gRPC 反射服务器在监听,然后将反射方法添加到你的 GRPCRoute
,配置实例如下。这在开发和预生产环境中可能会很有用,但在生产环境中启用此功能时,应在考虑安全隐患后再进行。
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
name: foo-route
spec:
parentRefs:
- name: example-gateway
hostnames:
- "foo.example.com"
rules:
- matches:
- method:
service: com.example.User
method: Login
backendRefs:
- name: foo-svc
port: 50051
- matches:
- method:
service: grpc.reflection.v1.ServerReflection
backendRefs:
- name: foo-svc
port: 50051