http - gRPC 连接如何在 kubernetes 服务 ClusterIP 上工作

Question

我对网络和 gRPC 的理解可能遗漏了一些东西。我想从一个例子开始解释我是如何理解网络的。

我在默认命名空间中部署了 3 个名为 app 的副本他们有 pod IP:

10.3.0.1, 10.3.0.2, 10.3.0.3

我有一个 ClusterIP 服务用于名为 app-service 的部署，它的 IP 为:

10.24.0.0

kube-dns 将有一个映射 app-service.default.svc.cluster.local -> 10.24.0.0 的记录。每个节点上的 kube-proxy 将看到配置并使用映射更新 netfilter 10.24.0.0 -> 10.3.0.1, 10.3.0.2 , 10.3.0.3。

现在在我的集群中，我有另一个客户端 pod，它对 app-service.default.svc.cluster.local 进行 gRPC 调用。

我期望发生的是 app-service.default.svc.cluster.local 将解析为单个 IP 10.24.0.0，并且 gRPC 将创建单个子 channel 并尝试建立长期连接。

此调用将从 pod 到达节点并通过 netfilter，此时 10.24.0.0 变为 10.3.0.1 并最终到达第一个 pods 。

现在有来自客户端的第二个调用，它通过 netfilter，此时 10.24.0.0 变成 10.3.0.2，这个调用在另一个 pod 上结束谁不知道他们已经建立了连接？

我也看到了这些 blogs提到 gRPC 将创建到单个 pod IP 的粘性 session ，但我认为 pod IP 不会在 application/grpc 客户端内部解析，而是在 netfilter 中解析。

Answer 1

我认为您可以从 Load Balancing in gRPC 中找到一些答案.

负载平衡策略适合 gRPC 客户端工作流程，介于名称解析和连接到服务器之间。

• 在启动时，gRPC 客户端发出 name resolution请求服务器名称。该名称将解析为IP 地址列表，这是一个指示要使用哪个客户端负载平衡策略的服务配置(例如，round_robin 或 grpclb) 并提供该策略的配置和一组属性(C 核心中的 channel 参数)。
• 客户端实例化负载平衡策略并通过服务配置、IP 地址列表和属性传递其配置。
• 负载平衡策略为服务器的 IP 地址(可能与解析器返回的 IP 地址不同；见下文)创建一组子 channel 。它还会监视子 channel 的连接状态，并决定每个子 channel 何时应尝试连接。
• 对于发送的每个 RPC，负载均衡策略决定 RPC 应该发送到哪个子 channel (即哪个服务器)。

当 pod 的 IP 由于 pod 重启而更改时，现在 gRPC 将在子连接进入瞬时故障时尝试重新解析。这是一个相关的 discussion和 code