18

在 Kubernetes 中，服务通过服务 ip 相互通信。使用 iptables 或类似的东西，每个 TCP 连接都被透明地路由到可用于被调用服务的 pod 之一。如果调用服务没有关闭 TCP 连接（例如使用 TCP keepalive 或连接池），它将连接到一个 pod，而不使用可能产生的其他 pod。

处理这种情况的正确方法是什么？

我自己不满意的想法：

每次 api 调用后关闭连接

我是否让每次调用都变慢了，只是为了能够将请求分发到不同的 pod？感觉不对。

最小连接数

我可以强制调用者打开多个连接（假设它会在这些连接中分发请求）但是应该打开多少个？调用者（并且可能不应该）不知道有多少个 pod。

禁用突发

我可以限制被调用服务的资源，因此它在多个请求时变慢，调用者将打开更多连接（希望与其他 pod）。同样，我不喜欢任意减慢请求速度的想法，这仅适用于 cpu 绑定服务。

4

2 回答 2

3

keep-alive 行为可以通过 Keep-Alive 通用标题中指定的选项进行调整：

例如：

Connection: Keep-Alive
Keep-Alive: max=10, timeout=60

因此，您可以在特定超时后重新打开 tcp 连接，而不是在每个 API 请求或最大数量的 http 事务之后。

请记住，不保证超时和最大值。

编辑：

注意如果使用k8s服务可以选择两种LB模式：

  • iptables 代理模式（默认情况下，iptables 模式下的 kube-proxy 会随机选择一个后端。）

  • IPVS 代理模式，您有不同的负载平衡选项：

IPVS 提供了更多用于平衡后端 Pod 流量的选项；这些是：

rr：循环 lc：最少连接（打开连接的最少数量） dh：目标哈希 sh：源哈希 sed：最短预期延迟 nq：从不排队

检查这个链接

于 2019-07-23T08:34:35.730 回答
1

执行此操作的一种机制可能是在 TCP 连接终止下方的层中进行负载平衡。例如，如果您将服务分成两部分 - 执行连接处理的微服务（我们称之为frontend-svc）可能还有一些 authnz，以及执行您的业务逻辑/处理的另一个单独的服务。

clients <---persistent connection---> frontend-svc <----GRPC----> backend-svc

frontend-svc 可以以更精细的方式维护对后端的 make 调用，例如使用 GRPC，并在下层的工作人员之间实现真正的负载平衡。这意味着作为 frontend-svc 一部分的 pod 没有做太多工作并且完全无状态（因此不需要负载平衡），这意味着您也可以使用 HPA 控制它们，前提是您有一些耗尽逻辑确保您不会终止现有连接。

这是 SSL 代理等用来处理与 LB 分开的连接终止的常用方法。

于 2019-08-14T19:17:10.067 回答