在Kubernetes中，服务通过服务ip相互通信。使用iptables或类似的东西，每个TCP连接都透明地路由到可用于被叫服务的pod之一。如果呼叫服务未关闭TCP连接（例如使用TCP Keepalive或连接池），它将连接到一个Pod，而不使用可能产生的其他Pod。
处理这种情况的正确方法是什么？
我自己不满意的想法：
我每次通话都变慢了，只是为了能够将请求分配到不同的Pod吗？感觉不对。
我可以强迫调用者打开多个连接（假设它将随后在这些连接中分配请求），但是应该打开几个？呼叫者不知道（可能不应该知道）有多少个豆荚。
我可以限制被调用服务的资源，因此它在多个请求上变得很慢，并且调用方将打开更多连接（希望与其他Pod连接）。再次，我不喜欢任意放慢请求的想法，这仅适用于cpu绑定的服务。
答案 0 :(得分：2)
可以通过“保持活动”常规标头中指定的选项来调整保持活动状态：
例如：
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：永不排队
答案 1 :(得分：1)
执行此操作的一种机制可能是在TCP连接终止下面的层中进行负载平衡。例如，如果您将服务分为两部分-进行连接处理（也许称为authnz）的微服务（我们称为 frontend-svc ），以及进行业务逻辑/处理的另一项单独服务。 / p>
clients <---persistent connection---> frontend-svc <----GRPC----> backend-svc
frontend-svc可以更精细地维护对后端的make调用，例如使用GRPC，并在下一层的工作程序之间实现真正的负载平衡。这意味着作为frontend-svc一部分的pod不需要做很多工作，并且完全是无状态的（因此对负载平衡的需求更少），这意味着您还可以通过HPA来控制它们，前提是您需要一些消耗逻辑确保您不终止现有连接。
这是SSL代理等用于与LB分开处理连接终止的常用方法。