python - gRPC 客户端负载均衡

Question

我在 kubernetes pod 中使用带有 Python 的 gRPC 作为客户端/服务器...我希望能够启动多个相同类型的 pod(gRPC 服务器)并让客户端(随机)连接到它们。

我分派(dispatch)了 10 个服务器 pod 并设置了一个“服务”来定位它们。然后，在客户端中，我连接到服务的 DNS 名称——这意味着 kubernetes 应该进行负载平衡并将我定向到一个随机服务器 pod。实际上，客户端调用 gRPC 函数(运行良好)但是当我查看日志时，我发现所有调用都转到同一个服务器 pod。

我假设客户端正在执行某种 DNS 缓存，这会导致所有调用都发送到同一台服务器。是这样吗？无论如何禁用它并设置相同的 stub 客户端进行"new"调用并在每次调用时通过 DNS 获取新的 ip？

我知道如果它每次都查询 DNS 服务器可能会导致开销，但目前分配负载对我来说更为重要。

Answer 1

让我借此机会通过描述事情应该如何运作来回答。

客户端 LB 在 gRPC C 核心(除了 Java 和 Go 风格或 gRPC 之外的所有基础)中的工作方式如下(可以找到权威文档 here ):

客户端 LB 故意保持简单和“愚蠢”。我们选择实现复杂 LB 策略的方式是通过外部 LB 服务器(如上述文档中所述)。您不关心这种情况。相反，您只是创建一个 channel ，它将使用(默认)优先选择 LB 策略。

LB 策略的输入是已解析地址的列表。使用 DNS 时，如果 foo.com 解析为 [10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4]，该策略将尝试与所有这些建立连接。第一个成功连接的将成为选中的那个直到它断开连接。因此得名“先挑”。更长的名称可能是“首先选择并尽可能长时间地使用它”，但这导致了一个非常长的文件名 :)。如果/当挑选一个人断开连接时，选择优先的策略将转移到返回下一个成功连接的地址(内部称为“连接的子 channel ”)，如果有的话。再一次，只要它保持连接，它就会继续选择这个连接的子 channel 。如果所有这些都失败，则调用将失败。

这里的问题是 DNS 解析本质上是基于拉取的，仅在 1) channel 创建时和 2) 在所选连接的子 channel 断开连接时触发。

截至目前，一个 hacky 解决方案是为每个请求创建一个新 channel (效率非常低，但根据您的设置它可以解决问题)。

鉴于 2017 年第一季度即将发生的变化(参见 https://github.com/grpc/grpc/issues/7818)，客户将可以选择不同的 LB 政策，即 Round Robin。此外，我们可能会考虑在该客户端配置中引入一个“随机化”位，这将在对地址进行循环之前对地址进行洗牌，从而有效地实现您的意图。