内部 TCP/UDP 负载平衡器作为下一个跃点

内部 TCP/UDP 负载平衡是一种区域级负载平衡器,可让您在内部负载平衡 IP 地址后面运行和扩缩您的服务。您可以将内部 TCP/UDP 负载平衡器用作数据包沿其最终目标的路径转发到的下一个网关。为此,您需要将负载平衡器设置为自定义静态路由中的下一个跃点

此配置适用于以下情况:

  • 您需要在充当虚拟网络地址转换 (NAT) 设备的多个虚拟机之间进行流量负载平衡。

  • 您需要一个负载平衡器作为默认路由的下一个跃点。当 Virtual Private Cloud (VPC) 网络中的虚拟机实例向互联网发送流量时,系统会通过负载平衡的网关虚拟设备路由流量。

  • 您需要将同一组多 NIC 虚拟机用作后端,通过多个负载平衡器向两个或多个方向发送流量。为此,您需要创建一个负载平衡器,并将其用作每个 VPC 网络中自定义静态路由的下一个跃点。每个内部 TCP/UDP 负载平衡器都在单个 VPC 网络中运行,将流量分配到该网络中后端虚拟机的网络接口。

将负载平衡到多个 NIC(点击可放大)
将负载平衡到多个 NIC(点击可放大)

在上图中,一个虚拟机实例组用作两个不同负载平衡器的后端。这种使用场景被称为“针对常见后端将内部 TCP/UDP 负载平衡器设置为下一个跃点”,因为后端虚拟机上有多个 NIC(在此示例中为 nic0nic1)在进行负载平衡。系统允许进行此部署,因为内部 TCP/UDP 负载平衡支持将负载平衡到后端虚拟机实例上的任何接口(而不仅仅是主要接口 nic0)。

相比之下,两组虚拟机实例可用作两个不同负载平衡器的后端。如果传入和传出流量具有不同的流量配置文件,您可以使用两组后端。这种使用场景被称为“针对不同后端将内部 TCP/UDP 负载平衡器设置为下一个跃点”,因为只有后端虚拟机上的主要接口 (nic0) 会进行负载平衡。下图展示了此设置:

将负载平衡到单个 NIC(点击可放大)
将负载平衡到单个 NIC(点击可放大)

您可以创建自定义静态路由,将 TCP 和 UDP 流量传递到内部 TCP/UDP 负载平衡器,其中负载平衡器是静态路由的下一个跃点。路由可以是默认路由 (0.0.0.0/0)、可公开路由的外部 CIDR 前缀,或者内部 CIDR 前缀(如果前缀与子网路由不冲突)。例如,您可以将默认路由 (0.0.0.0/0) 替换为将流量定向到第三方后端虚拟机进行数据包处理的路由。

为了使用自定义静态路由,每个 VPC 网络中的虚拟机实例必须位于其关联负载平衡器所在的区域中。

如果 Cloud Router 路由器与负载平衡器位于同一区域,您可以使用 Cloud Router 路由器自定义路由通告向其他连接的网络通告此路由。如需了解详情,请参阅内部 TCP/UDP 负载平衡和连接网络

有关详情,请参阅:

将内部 TCP/UDP 负载平衡器用作下一个跃点的好处

如果负载平衡器是静态路由的下一个跃点,您无需将客户端明确配置为向负载平衡器或每个后端虚拟机发送流量。您可以通过线缆串接设备的方式集成后端虚拟机。

通过使用内部 TCP/UDP 负载平衡器作为静态路由的下一个跃点,您可以获得内部 TCP/UDP 负载平衡所具有的相同好处。负载平衡器的运行状况检查可以确保新连接路由到运行状况良好的后端虚拟机。通过将托管实例组用作后端,您可以配置自动扩缩功能以根据服务需求扩大或缩小虚拟机集。

规格

以下是将内部 TCP/UDP 负载平衡器用作下一个跃点的规范。

客户端 IP 地址会话粘性

客户端 IP 地址会话亲和性是一个可用的会话亲和性选项。它是二元组亲和性,将来源 IP 地址和目标 IP 地址用作哈希函数的输入。

如果单独使用内部 TCP/UDP 负载平衡器,则目标 IP 地址是负载平衡器转发规则的 IP 地址。此上下文中的客户端 IP 地址会话亲和性意味着来自具有固定来源 IP 地址的客户端的连接,会传送到同一运行状况良好的后端虚拟机。

相比之下,如果将内部 TCP/UDP 负载平衡器用作静态路由的下一个跃点,则目标 IP 地址会发生变化,因为负载平衡器的后端虚拟机可处理数据包并将数据包路由到不同的目标。即使客户端具有固定的来源 IP 地址,在此上下文中使用客户端 IP 地址会话亲和性也不会导致数据包由同一后端虚拟机处理。

目标范围

自定义静态路由的目标不能等于子网路由,也不能比其更具体。请注意,更具体意味着子网掩码更长。此规则适用于所有自定义静态路由,包括下一个跃点是内部 TCP/UDP 负载平衡器时。例如,假设您的子网路由为 10.140.0.0/20。自定义静态路由的目标不能是相同的 (10.140.0.0/20),并且不能比 10.140.0.0/22 中的更具体。

相同的 VPC 网络和区域

只有在以下场景下,自定义静态路由会将内部 TCP/UDP 负载平衡器用作下一个跃点:

  • 单个 VPC 网络。负载平衡器和自定义静态路由必须位于同一个 VPC 网络中。

  • 单个区域或所有区域。除非您配置全球访问权限,否则自定义静态路由只能供与负载平衡器位于同一区域的资源使用。即使路由本身是整个 VPC 网络的路由表的一部分,系统也会强制实施此区域限制。如果您启用全球访问权限,则自定义静态路由可供任何区域中的资源使用。

操作顺序

您必须先创建内部 TCP/UDP 负载平衡器,然后才能创建将该负载平衡器用作下一个跃点的自定义静态路由。负载平衡器必须已存在,您才能创建路由。如果您尝试创建路由,但路由引用的负载平衡器不存在,则 Google Cloud 会返回错误。

如需指定内部 TCP/UDP 负载平衡器下一个跃点,您可以使用转发规则的名称和负载平衡器的区域,而不是使用与转发规则关联的内部 IP 地址。

使用下一个跃点(引用内部 TCP/UDP 负载平衡器)创建路由后,除非先删除路由,否则无法删除负载平衡器。具体来说,您不能删除内部转发规则,除非没有自定义静态路由将该转发规则用作下一个跃点。

后端要求

  • 您必须将内部 TCP/UDP 负载平衡器的所有后端虚拟机配置为允许 IP 转发(--can-ip-forward = True)。如需了解详情,请参阅基于实例或基于负载平衡器的路由的注意事项

  • 您不能将后端为 Google Kubernetes Engine (GKE) 节点的内部 TCP/UDP 负载平衡器用作自定义静态路由的下一个跃点。如果目标与集群管理的 IP 地址匹配,则节点上的软件只能将流量路由到 Pod,而不是任意目标。

TCP、UDP 和其他协议流量的处理

将内部 TCP/UDP 负载平衡器部署为下一个跃点时,Google Cloud 会将所有端口上的所有 TCP 和 UDP 流量转发到后端虚拟机,而不考虑以下因素:

  • 转发规则的协议和端口配置
  • 后端服务的协议配置

负载平衡器仅处理 TCP 和 UDP 流量,并忽略所有其他流量,例如 ICMP。不使用 TCP 或 UDP 协议的流量由 VPC 网络中的下一个最具体的路由处理。非 TCP 和非 UDP 流量的路由具有以下特征:

  • 它们没有内部 TCP/UDP 负载平衡器作为下一个跃点。
  • 它们是根据路由顺序选择的。

例如,假设您的 VPC 网络中有以下路由:

  • 目标:1.1.1.1/32,下一个跃点:内部 TCP/UDP 负载平衡器
  • 目标:1.0.0.0/8,下一个跃点:默认互联网网关

对于与负载平衡器位于同一区域的客户端(如果启用了全球访问权限,则为任意区域),目标为 1.1.1.1/32 的 TCP 和 UDP 流量将使用下一个跃点为内部 TCP/UDP 负载平衡器的路由。

对于非 TCP 和非 UDP 流量(例如 IMP ping),则会改用 1.0.0.0/8 路由。

其他规范

  • 如果自定义静态路由具有作为其下一个跃点的内部 TCP/UDP 负载平衡器,则该路由无法使用网络标记

  • 您无法创建具有相同优先级、相同目的地、相同内部 TCP/UDP 负载平衡器的下一个跃点的多个自定义静态路由。 因此,具有相同下一个跃点负载平衡器的每个自定义静态路由必须至少具有唯一的目标或唯一的优先级。

  • 如果您将多个内部 TCP/UDP 负载平衡器作为具有相同目标和优先级的多个路由的下一个跃点,则 Google Cloud 不会在负载平衡器之间分配流量。相反,Google Cloud 仅选择其中一个负载平衡器作为与目标匹配的所有流量的下一个跃点,并忽略其他负载平衡器。

  • 当您将内部 TCP/UDP 负载平衡器用作自定义静态路由的下一个跃点时,不能使用具有内部转发规则 IP 地址的 --purpose=SHARED_LOADBALANCER_VIP 标志。这是因为共享的内部 IP 地址可以间接引用多个后端服务。

如需了解详情,请参阅路由概览

用例

您可以将内部 TCP/UDP 负载平衡器用作多个部署和拓扑中的下一个跃点。

对于每个示例,请注意以下准则:

  • 每个虚拟机接口必须位于单独的 VPC 网络中。

  • 您无法使用后端虚拟机或负载平衡器在同一 VPC 网络的子网之间路由流量,因为无法替换子网路由。

  • 内部 TCP/UDP 负载平衡器是软件定义的直通负载平衡器。NAT 和代理仅由后端虚拟机(防火墙虚拟设备)执行。

将内部 TCP/UDP 负载平衡器用作 NAT 网关的下一个跃点

在此使用场景中,系统通过负载平衡将流量从内部虚拟机路由到多个 NAT 网关实例,这些实例将流量路由到互联网。

NAT 使用场景(点击放大)
NAT 使用场景(点击可放大)

中心辐射型拓扑:使用 VPC 网络对等互连来交换下一个跃点路由

除了交换子网路由之外,您还可以配置 VPC 网络对等互连以导出和导入自定义静态和动态路由。系统会排除使用网络标记的自定义静态路由或者下一个跃点为默认互联网网关的自定义静态路由。

通过执行以下操作,您可以使用位于 hub VPC 网络中的下一个跃点防火墙虚拟设备来配置一个中心辐射型拓扑:

  • hub VPC 网络中,创建内部 TCP/UDP 负载平衡器并将防火墙虚拟设备用作后端。
  • hub VPC 网络中,创建自定义静态路由,并将下一个跃点设置为内部 TCP/UDP 负载平衡器。
  • 使用 VPC 网络对等互连将 hub VPC 网络连接到每个 spoke VPC 网络。
  • 对于每个对等互连,配置 hub 网络以导出其自定义路由,并配置相应的 spoke 网络以导入自定义路由。具有负载平衡器下一个跃点的路由是 hub 网络导出的路由之一。

hub VPC 网络中的下一个跃点防火墙设备负载平衡器在每个 spoke 网络中的可用性取决于路由顺序

中心辐射型拓扑(点击放大)
中心辐射型拓扑(点击可放大)

将负载平衡到多个 NIC

在以下使用场景中,后端虚拟机是在多个 VPC 网络中具有 NIC 的虚拟设备实例(例如,防火墙实例或 NAT 网关)。防火墙实例和 NAT 网关可以由第三方作为虚拟设备提供。虚拟设备是具有多个 NIC 的 Compute Engine 虚拟机。

此示例显示了托管虚拟机实例组中的一组后端虚拟设备。

在名为 testing 的 VPC 网络中,内部 TCP/UDP 负载平衡器具有一个名为 fr-ilb1 的转发规则。在此示例中,此负载平衡器会将流量分配到每个虚拟设备上的 nic0 接口,但也可能是任何 NIC。

在名为 production 的 VPC 网络中,不同的内部 TCP/UDP 负载平衡器具有一个名为 fr-ilb2 的转发规则。此负载平衡器会将流量分配到不同的接口(本例中为 nic1)。

流量进行了多 NIC 负载平衡(点击可放大)
流量进行了多 NIC 负载平衡(点击可放大)

如需了解详细的配置设置,请参阅将负载平衡到多个后端 NIC

将内部 TCP/UDP 负载平衡器用作具有单个 NIC 的下一个跃点

与先前使用场景类似,后端虚拟机是在多个 VPC 网络中具有 NIC 的虚拟设备实例(例如,防火墙实例或 NAT 网关)。

以下示例显示了两个托管虚拟机实例组中的两组后端虚拟设备。

这些后端可归纳如下。

testingproduction 流量的已进行负载平衡的实例 productiontesting 流量的已进行负载平衡的实例
fw-instance-a
fw-instance-b
fw-instance-c
fw-instance-d
fw-instance-e
fw-instance-f

testingproduction 方向,流量源自名为 testing 的 VPC 网络。在 testing 网络中,内部 TCP/UDP 负载平衡器具有一个名为 fr-ilb1 的转发规则。此示例将内部 TCP/UDP 负载平衡器与没有指定 network 参数的后端服务结合使用。这意味着每个负载平衡器仅将流量分配到每个后端虚拟机的主要网络接口。

流量进行了单 NIC 负载平衡(<code>testing</code> 到 <code>production</code>)(点击可放大)
流量进行了单 NIC 负载平衡(testingproduction)(点击可放大)

productiontesting 方向,流量源自名为 production 的 VPC 网络。在 production 网络中,不同的内部 TCP/UDP 负载平衡器具有一个名为 fr-ilb2 的转发规则。同样,此示例将内部 TCP/UDP 负载平衡器与没有指定 network 参数的后端服务结合使用。这意味着每个负载平衡器仅将流量分配到每个后端虚拟机的主要网络接口。因为每个虚拟设备只能具有一个 nic0,所以此部署需要第二组虚拟设备:第一组为 testingproduction 负载平衡,第二组为 productiontesting 负载平衡。

流量进行了单 NIC 负载平衡(<code>production</code> 到 <code>testing</code>)(点击可放大)
流量进行了单 NIC 负载平衡(productiontesting)(点击可放大)

后续步骤