Traffic Director 服务路由 API 概览

本文档适用于对 Traffic Director 和服务网格概念具有中高级熟悉程度的网格或平台管理员和服务开发者。本文档适用于使用 Envoy 和 gRPC 客户端的部署。如需详细了解 Traffic Director 概念,请参阅一般概览无代理 gRPC 服务概览

Traffic Director 为您的应用提供服务网络功能,包括高级流量管理、可观测性和安全性。但是,对网格管理员和服务开发者而言,配置和运营服务网格是一项复杂的任务。

本文档介绍用于配置 Traffic Director 的服务路由 API。这些 API 旨在简化和改进整体网格配置体验。

此 API 模型将旧的转发规则目标代理网址映射资源替换为名为 MeshGatewayRoute 的 API 资源。在定义服务网络控制平面时,这些资源可提供与上下文更相关的配置体验。

本文档介绍了以下服务路由 API 模型和资源。

  • Mesh
    • Envoy 边车代理和无代理 gRPC 客户端的服务到服务(东西向)流量管理和安全配置。
    • 标识服务网格,表示负责拦截和路由流量以及应用政策的组件,同时标识流量拦截端口。
  • Gateway
    • 充当入站流量网关的 Envoy 代理的流量管理和安全配置,允许外部客户端连接到服务网格(南北向)。
    • 识别中间代理,表示监听 IP 地址-端口对列表、路由流量以及应用政策的组件。
  • Route
    • 识别客户端用于将流量路由到后端服务的主机名称和端口,包含复杂的流量路由信息。Route 资源有多种不同类型。
    • HTTPRoute
    • GRPCRoute
    • TCPRoute
    • TLSRoute

Google Cloud 控制台不为服务路由 API 提供支持。您必须使用 Google Cloud CLI 或 REST API 实现这些 API 资源。此外,没有从旧版 API 到服务路由 API 的自动迁移路径。如需替换现有部署,您必须使用服务路由 API 创建新的 Traffic Director 部署,然后关停旧部署。

使用场景和优势

借助服务路由 API,您便可以为无代理 gRPC 和 Envoy 代理部署配置 Traffic Director。服务路由 API 模型具有多项关键优势。

在下图中,服务网格中的两项服务通过 Mesh 资源进行连接。两个 HTTPRoute 资源会配置路由。网格或平台管理员负责管理 Mesh 资源,这两个服务所有者为其服务创建路由配置。

服务网格中东西向的服务到服务流量
服务网格中东西向的服务到服务流量(点击可放大)

面向角色的 API 设计可实现明确的职责分离

服务路由 API 可让您根据组织角色分离网格配置职责:

  • 网格管理员可以定义逻辑网格以及入站流量网关基础架构。
  • 服务所有者(应用开发者)可以独立定义其服务的访问模式。他们还可以为服务定义和应用流量管理政策。

在下图中,Cloud Load Balancing 和 Gateway 资源为从客户端(不在网格中)进入网格的流量提供了入站流量网关。网格管理员配置和管理 Gateway 资源,而服务所有者配置和管理自己的服务和流量路由。

通过网关流向网格的流量(南北向)
通过网关流向网格的流量(南北向)(点击可放大)

通过自助服务模型增强可靠性

在旧的 Traffic Director API 中,网址映射定义网格中服务到服务通信的路由,以及通过代管式负载均衡器进入网格的外部流量的路由。多个团队可能正在修改单个网址映射资源,这会带来潜在的可靠性问题,并使将每个服务配置委派给服务所有者的过程变得复杂。

服务路由 API 引入了可以由独立服务所有者配置和拥有的按协议、按路由的资源。这样做具有很多优势.

  • 现在,服务所有者可以自主选择如何为其拥有的服务配置政策和流量管理。
  • 更新一个 Route 资源不会影响网格中的其他 Route 资源。更新过程也不易出错,因为服务所有者管理的配置要小得多。
  • 负责目标服务或主机名的服务所有者拥有每个 Route 资源。
  • 服务所有者不必依赖于网格管理员使用集中式网址映射资源更新路由。

仅配置相关内容

服务路由 API 会替换转发规则目标代理网址映射。您无需从 Virtual Private Cloud (VPC) 网络分配虚拟 IP 地址,即可与边车代理和无代理 gRPC 进行服务到服务通信。

在共享 VPC 环境中启用跨多个项目的服务网格

借助服务路由 API 模型,服务所有者可以使用共享 VPC 和其他连接方法参与共享网格基础架构,同时保持对其服务的独立控制。例如,服务所有者可以在自己的项目中定义 Route 资源。平台管理员可以在集中管理的宿主项目中定义 Mesh,然后向服务所有者授予 IAM 权限,使其 Route 资源关联到共享 MeshGateway。下图展示了使用共享 VPC 的示例。

使用共享 VPC 进行跨项目引用
使用共享 VPC 进行跨项目引用(点击可放大)

通过服务路由 API,您还可以使用 VPC 网络对等互连将服务网格客户端连接到不同网络。

根据服务器名称指示符路由流量

借助 TLSRoute 资源,您可以根据 TLS 握手中的服务器名称指示 (SNI) 路由通过 TLS 加密的流量。您可以通过在 TLSRoute 资源中配置 SNI 匹配项,将 TLS 流量配置为路由到相应的后端服务。在这些部署中,代理仅路由流量,并且会在目标后端实例上终止 TLS 会话。

只有部署为 Sidecar 代理或网关的 Envoy 代理支持 TLSRoute 资源。

TLSRoute 资源挂接到 Mesh 资源

下图中显示的部署会将 SNI 扩展值为 service1 的所有服务网格流量路由到后端服务 service1。此外,SNI 扩展值为 service2 的所有服务网格流量则会被路由到后端服务 service2。SNI 扩展值和后端服务名称彼此独立。

TLSRoute 资源和网格资源
TLSRoute 资源和 Mesh 资源(点击可放大)

TLSRoute 资源挂接到 Gateway 资源

下图中显示的部署会将发送到 SNI 扩展值为 serviceAGateway 资源的所有入站流量路由到后端服务 serviceA。此外,发送到 SNI 扩展值为 serviceBGateway 的所有入站流量则会被路由到后端服务 serviceB。SNI 扩展值和后端服务名称彼此独立。SNI 扩展值和 HTTP 请求中的标头也是彼此独立的。

Gateway 资源不会终止 Gateway 的 Envoy 代理上的 TLS 连接。相反,TLS 连接会在相应的后端服务上终止。Gateway 无法检查 TLS 层中加密的任何信息,但在查看 ClientHello 时除外,其包含一个纯文本 SNI 扩展。Gateway 在此模式下执行 TLS 直通。请注意,加密的 ClientHello 不受支持。

TLSRoute 资源和网关资源
TLSRoute 资源和 Gateway 资源(点击可放大)

内置 gRPC 支持

您可以使用内置的 gRPC 属性(例如按方法匹配)来配置无代理 gRPC 客户端,而不是转换为等效路径和使用路径匹配器。

TCP 流量的流量拆分

您现在可以跨多个后端服务为 TCP 流量实现基于权重的流量拆分。您可以在更新服务时配置模式,例如 Canary 版(蓝绿色)部署。通过流量拆分,您还可以可控方式迁移流量,而无需停机。

流量拦截

使用服务路由 API MeshGateway 资源时,所有流量都会被自动拦截。如需了解详情,请参阅为 Compute Engine 虚拟机进行自动 Envoy 部署的设置选项

架构和资源

本部分介绍了服务路由 API 模型及其资源,并帮助您了解服务路由 API 资源如何协同工作。

Mesh 资源

Mesh 资源表示服务网格的实例。您可以用它在项目中创建逻辑服务网格。每个 Mesh 资源在项目中都必须具有唯一的名称。创建 Mesh 资源后,无法修改其名称。

使用 Envoy 边车和无代理 gRPC 部署的 Mesh API 资源
Mesh使用 Envoy 边车和无代理 gRPC 部署的 API 资源(点击可放大)

Route 资源中引用了 Mesh 资源,用于为属于该网格的服务添加路由。

Envoy 代理和无代理 gRPC 客户端通过加入由 Mesh 资源的名称标识的服务网格从 Traffic Director 接收配置。Mesh 名称作为引导参数,受 Compute Engine 上的自动 Envoy 部署GKE 上的自动 Envoy 注入器支持。

Mesh 资源支持以下数据平面部署:

  • Envoy 作为边车代理与应用一起运行
  • 无代理 gRPC 客户端
  • 将 Envoy 边车和无代理 gRPC 客户端混用

Route 资源

Route 资源用于设置通往服务的路由。Route API 资源有四种不同的类型。它们定义用于将流量路由到后端服务的协议。

该 API 不包含逐字 Route API。唯一可配置的 API 资源是 HTTPRouteGRPCRouteTCPRouteTLSRoute

Route 资源引用一个或多个 MeshGateway 资源来添加属于相应 MeshGateway 配置的路由。Route 资源可以引用 GatewayMesh 资源。

Route 资源还引用一个或多个后端服务资源。使用后端服务 API 和现有配置流程来配置服务。服务路由 API 不会更改后端服务和健康检查在 Traffic Director 配置中的定义方式。为此,您需要创建一个指向一个或多个 MIG 或 NEG 后端的后端服务资源。

下图显示了 MeshGatewayRoute 资源与后端服务资源及其后端之间的关系。

Route API 资源
Route API 资源(点击可放大)

您可以在 Route 资源中定义其他流量管理功能,例如路由、标头修改、超时和基于权重的流量拆分。例如,在下图中,HTTPRoute 资源定义了两个后端服务之间的流量拆分比例为 70%/30%。

基于权重的流量拆分
基于权重的流量拆分(点击可放大)

TLSRoute 资源

使用 TLSRoute 资源时,系统会根据 SNI 主机名和应用层协议协商 (ALPN) 名称将 TLS 流量路由到后端服务。TLSRoute 配置表示 TLS 直通,其中 Envoy 代理不会终止 TLS 流量。

TLSRoute 资源会引用一个或多个 MeshGateway 资源来添加属于相应网格或网关配置的路由。

TLSRoute 资源还会引用一个或多个后端服务资源。这些服务使用现有配置流程和 API 通过后端服务 API 资源进行配置。

Gateway 资源

Gateway 资源用于表示充当入站流量网关的 Envoy 代理,允许外部客户端连接到服务网格(南北向流量)。此资源具有侦听端口以及 scope 参数。充当入站流量网关的 Envoy 代理会绑定到指定的端口,以及绑定到 0.0.0.0(表示本地虚拟机上的所有 IP 地址)。下图显示了部署为 Ingress 服务并由 Gateway 资源配置的 Envoy 代理。在此特定示例中,Envoy 代理配置为侦听客户端上端口 80 的传入连接。

Gateway API 资源仅支持 Envoy 代理数据平面。它不支持无代理 gRPC。Gateway 资源支持 gRPCRoutes,但 gRPC 流量由充当中间代理的 Envoy 代理进行路由。

通过“网关”资源的服务网格入站流量
通过 Gateway 资源的服务网格入站流量(点击可放大)
Gateway 资源
Gateway 资源(点击可放大)

什么是 Gateway 范围及合并的 Gateway 配置?

Gateway 资源实例表示端口和特定于在这些端口上接收的流量的配置。Gateway API 资源具有参数 scope,该参数用于对两个或更多 Gateway 资源的配置进行逻辑分组和合并。

例如,如果您希望 Gateway 代理侦听端口 80 和 443 以分别接收 HTTP 和 HTTPS 流量,则需要创建两个 Gateway 资源。使用端口 80 配置一个 Gateway 资源以用于 HTTP 流量,然后使用端口 443 配置另一个资源以用于 HTTPS 流量。为两个资源中的 scope 字段指定相同的值。Traffic Director 会动态合并具有相同范围的所有网关的各个配置。对于数据层面端,在入站流量网关模式下运行的 Envoy 代理也必须向 Traffic Director 提供相同的范围参数才能接收 Gateway 配置。请注意,您需要在创建 Gateway 资源时指定范围,并且需要为代理指定与引导参数相同的范围。

Gateway 资源合并行为
Gateway资源合并行为(点击可放大)

以下是 Gateway 资源的关键注意事项:

  • Gateway 范围参数是必需的。在 Gateway 资源中和 Envoy 代理的引导配置中指定范围,即使只有一个 Gateway 存在也是如此。
  • 创建 Gateway 资源不会使用 Envoy 代理部署服务。部署 Envoy 代理是一个单独的步骤。
  • Gateway 资源具有表示入站流量部署类型的 type。此字段预留以供将来使用。当前唯一支持的值是 OPEN_MESH,这是默认值,无法修改。

使用混合协议和数据平面的网格部署

您可以进行混合数据平面部署,并将 Envoy 代理和无代理 gRPC 置于同一网格中。创建此类部署时,请考虑以下事项。

  • Envoy 边车部署支持所有路由(HTTPRouteGRPCRouteTCPRouteTLSRoute)。
  • 无代理 gRPC 部署仅支持 GRPCRoute
  • GRPCRoute 仅限于 gRPC 无代理部署支持的功能。

多项目共享 VPC 环境中支持的拓扑

Traffic Director 支持将在其他项目中定义的 Route 资源添加到集中式管理项目中定义的 MeshGateway 资源。已获授权的服务所有者可以直接将其服务路由配置添加到 MeshGateway

Mesh 和 Route 资源之间的跨项目引用
MeshRoute 资源之间的跨项目引用(点击可放大)

在典型的跨项目场景中,您可以选择一个项目(宿主项目或集中控制的管理项目)作为网格管理项目,并在其中创建 Mesh 资源。网格管理项目所有者会授权其他项目中的 Route 资源引用 Mesh 资源,从而允许其他项目中的路由配置成为网格的一部分。网格数据平面(无论是 Envoy 还是 gRPC)会向管理项目请求配置,并接收连接到 Mesh 的所有路由的并集。对于 Gateway,路由也会合并到所有使用相同范围的 Gateways 中。

Mesh 管理项目可以是您选择的任何项目,只要底层项目通过共享 VPC 或 VPC 网络对等互连建立了 VPC 网络连接,就可以使用配置。

IAM 权限和角色

以下是安全获取、创建、更新、删除、列出以及使用 MeshRoute 资源所需的 IAM 权限。

  • Mesh 管理员需要具有 networkservices.mesh.* 权限。
  • Gateway 管理员需要具有 networkservices.gateways.* 权限。
  • 服务所有者需要具有 networkservices.grpcRoutes.*networkservices.httpRoutes.*networkservices.tcpRoutes.* 权限。

Mesh 管理员需要向服务所有者授予 networkservices.mesh.use 权限,以便服务所有者将其 Route 资源关联到 Mesh 资源。同一模型也适用于 Gateway 资源。

如需查看 Mesh 资源的所有 IAM 权限,请转到 IAM 权限参考页面,然后搜索 meshes

无需其他预定义角色。现有的预定义角色 Compute Network Admin (roles/compute.networkAdmin) 默认具有 networkservices.* 权限。您可能需要将上述权限添加到自定义角色中。

服务路由和旧版 API 模型的比较

本部分对旧版 API 与服务路由 Traffic Director API 模型进行了主题比较。

旧版 API 服务路由 API
API 资源 转发规则、目标代理、网址映射和后端服务。 Gateway、Mesh、Route 和后端服务。
服务的 IP 地址和端口号 您必须为服务预配 IP 地址和端口号,并配置转发规则,而转发规则必须与所有使用场景的 IP:Port 对匹配。

必须手动将 IP 地址映射到主机名,或者必须使用无限别名 IP 地址 0.0.0.0
您无需为 MeshGateway 用例配置 IP 地址。Gateway 要求配置端口号。
服务网格范围 Traffic Director 对连接到 VPC 网络的所有代理进行编程,因此网格范围是 VPC 网络。 Traffic Director 不会根据 VPC 网络对代理进行编程。

对于东西向的服务到服务通信,Envoy 和无代理 gRPC 客户端使用 Mesh 资源的名称。

对于南北向的入站流量网关使用场景,Gateway API 中有一个 scope 参数,允许多个 Gateways 与合并的配置组合在一起。
共享 VPC 环境中的跨项目引用 不支持跨项目引用。所有 API 资源都必须在同一项目中配置。 可以在集中管理的项目(宿主项目)中创建 MeshGateway 资源,此外服务所有者还可以在共享 VPC 环境的服务项目中创建 Route 资源。Route 资源可以引用跨项目的 MeshGateway
拦截端口 必须在连接到 Traffic Director 的每个 Envoy 中指定 TRAFFICDIRECTOR_INTERCEPTION_PORT 引导参数。

在 Compute Engine API 上自动部署 Envoy 并在 GKE 上自动注入边车,此值默认为 15001
拦截端口在 Mesh 资源中配置,并自动应用于请求该 Mesh 的配置的所有 Envoy。

如果未指定,则值继续默认为 15001

在 Compute Engine 和 GKE 上引导 Envoy 和 gRPC 客户端

旧版 API 服务路由 API
在 Compute Engine 上使用自动 Envoy 部署 创建虚拟机模板时,您需要指定命令行参数 --service-proxy=enabled,以使用所需属性动态引导 Envoy 代理。 创建虚拟机模板时,您可以指定一些其他参数。例如,--service-proxy=enabled, mesh=[MESH_NAME](针对网格)或 --service-proxy=enabled, scope=[SCOPE_NAME](针对网关)。其他必需属性是动态引导的。对于用作网关的 Envoy,请确保未将 serving_ports 指定为 --service-proxy 命令行参数。如需了解详情,请参阅为 Compute Engine 虚拟机进行自动 Envoy 部署的设置选项
在 GKE 上使用自动边车注入 您可以在边车注入器的 configMap 中指定所需的引导属性。 与 configMap 中指定的新属性相同的工作流。
在 GKE 上使用手动边车注入 此处所述,应用 pod 需要一个具有使用所需属性启动的 Envoy 边车容器。 具有新特性的同一工作流。
使用 Compute Engine 或 GKE 部署 gRPC 客户端 客户端应用必须使用所需属性进行引导。 具有新特性的同一工作流。

配置网格和网关安全使用场景

旧版 API 服务路由 API
GKE 中的服务到服务 mTLS 对于基于 Envoy 边车的部署,请按照此处的说明操作。

请按照此处的说明执行基于无代理 gRPC 的部署。
相关说明也适用。

客户端 TLS 政策和服务器 TLS 政策必须分别应用于后端服务和端点政策资源。由于这两个 API 与服务路由 API 正交,因此配置流程保持不变。
保护中间代理(入站或出站流量网关)部署 请按照此处的说明操作。

服务器 TLS 政策和授权政策资源将关联到目标 HTTPS 代理资源。
将服务器 TLS 政策和授权政策资源关联到 Gateway。

注意事项和限制

  • Google Cloud 控制台不支持服务路由 API。
  • 使用 xDS API 版本 3 或更高版本。
    • 最低 Envoy 版本 1.24.9。
    • gRPC 引导生成器最低版本 v0.14.0
  • 只有部署为 Sidecar 代理或网关的 Envoy 代理支持 TLSRoute 资源。
  • 仅支持具有自动 Envoy 部署的 Compute Engine 虚拟机和支持自动 Envoy 注入的 GKE Pod。您不能将手动部署与服务路由 API 一起使用。
  • 此版本不支持 Terraform。
  • 服务路由 API 不向后兼容旧版 API。
  • TCPRoute 资源关联到 Mesh 资源时,用于匹配 TCP 流量的端口不能用于处理此 TCPRoute 所描述的流量以外的任何内容。
    • 例如,您的部署可能包含与端口“8000”匹配的 TCPRoute 资源以及 HttpRoute 资源。当两者都关联到同一 Mesh 资源时,即使底层 IP 地址不同,由 HTTPRoute 资源路由的流量也无法使用端口 8000。此限制来自 Envoy 代理实现,该实现会先分配与端口匹配的路由的优先级。
  • Gateway 资源不会预配代管式负载均衡器,也不会动态创建 Envoy 服务。
  • 自动部署的 Envoy 充当入站流量网关的 serving_ports 参数不得添加到 --service-proxy 标志。
  • 自动部署的 Envoy 不支持提供与虚拟机项目不同的项目编号。

后续步骤