如果我们已经有外部负载均衡器，为什么还要使用内部负载均衡器？答案

【问题标题】：Why to use internal load balancer if we already have an external load balancer?如果我们已经有外部负载均衡器，为什么还要使用内部负载均衡器？
【发布时间】：2020-07-06 09:37:01
【问题描述】：

在我的项目中，我们已经有一个外部负载均衡器。但是，组织内有几个团队使用我们的内部负载均衡器。我想知道如果我们已经有一个面向公众的外部负载均衡器，为什么还需要内部负载均衡器？请详细说明。

【问题讨论】：

只是为了减少公众曝光！减少攻击面。安全最佳实践。
@guillaumeblaquiere 但我们已经有一个面向公众的外部负载均衡器。那么为什么在这种情况下需要内部负载均衡器呢？

标签： networking google-cloud-platform aws-elb

【解决方案1】：

我在评论中回答你的问题，因为评论太长了

事物是内在的，其他是外在的。举例

您有一个外部 TCP/UDP 负载平衡器
您的外部负载均衡器在端口 443 上接受连接，并将它们重定向到您安装了 NGINX 的后端
您的后端需要一个 MongoDB 数据库。您将数据库安装在计算上，然后选择抽象 VM IP 并使用负载均衡器
您在端口 27017 上的外部负载平衡器上定义了一个新后端

结果：因为负载均衡器是外部的，所以您的 MongoDB 在端口 27017 上公开。

如果您使用内部负载平衡器，情况并非如此，您可以提高安全性。只有面向 Web 的端口是开放的 (443)，其余的无法从 Internet 访问，只能由您在您的项目中访问。

【讨论】：

我得到了内部负载均衡器的使用。我只想知道，如果某个特定服务已经有一个外部负载均衡器，那么如果其他团队正在使用该服务，为什么同一服务可能需要一个内部负载均衡器？
如果您重复使用外部负载均衡器，则会在 Internet 上公开您的内部通信/端口，并增加您的攻击面。它的安全性较低，仅此而已！
为什么其他团队不能只在与互联网相同的端口上使用外部负载均衡器？为什么在这种情况下需要内部负载均衡器？
我不明白你的担忧。对于外部通信，请使用外部负载平衡器。对于内部通信，并且仅当您希望获得更好的安全级别时，才使用内部负载平衡器。当然，您可以将外部负载均衡器重用于内部服务，但不建议这样做！
为什么不推荐？这就是我想知道的

【解决方案2】：

您应该查看文档，然后确定您的用例是否需要使用内部负载均衡器。您可以在下面找到指向 Google Cloud 文档和示例的链接。

首先看一下文档Choosing a load balancer:

决定哪种负载平衡器最适合您的 Google 实施 Cloud，请考虑 Cloud Load Balancing 的以下方面：

全球与区域负载平衡

外部与内部负载平衡

交通类型

之后，查看文档Cloud Load Balancing overview 部分Types of Cloud Load Balancing：

外部负载平衡器将来自互联网的流量分配到您的 Google Cloud Virtual Private Cloud (VPC) 网络。全局负载均衡要求您使用 Premium Tier 网络服务层。对于区域负载均衡，您可以使用标准层。

内部负载平衡器将流量分配到 Google Cloud 内的实例。

和

下图说明了一个常见的用例：如何使用外部和内部负载平衡在一起。在插图中，来自旧金山、爱荷华州和新加坡的用户的流量是定向的到外部负载均衡器，该负载均衡器将流量分配给 Google Cloud 网络中的不同区域。 内部负载均衡器然后在 us-central-1a 和 us-central-1b 之间分配流量区域。

您可以在文档中找到更多信息。

更新查看internal HTTP(S) load balancer 和internal TCP/UDP load balancer 的可能用例，检查它们是否适合您，以及使用它们是否可以改善您的服务。

如果您不需要，则不需要使用内部负载均衡器。

【讨论】：

但这并不能回答我的问题。也许还不清楚。已经有一个外部负载均衡器暴露在互联网上。如果某个内部团队正在使用您的服务，那么内部负载均衡器的需求是什么？为什么他们不能只使用外部负载均衡器？
我已经用一些用例更新了我的答案。您是否可以使用当前服务图表更新您的问题？
@XYZ 我也想自己解决这个问题，但我认为这是因为如果您只使用外部负载均衡器，则会对性能产生影响，因为它会先路由到 Internet，然后再路由内部。而如果您只使用内部负载均衡器，您的流量不会首先进入互联网，因此速度会稍微快一些。