Kubernetes 负载均衡 HTTP/1.1 请求答案

【问题标题】：Kubernetes load balance HTTP/1.1 requestsKubernetes 负载均衡 HTTP/1.1 请求
【发布时间】：2021-02-02 17:27:12
【问题描述】：

我们知道，默认情况下，HTTP 1.1 使用持久连接，这是一个长期连接。对于Kubernetes中的任何服务，例如clusterIP模式，都是基于L4的负载均衡器。

假设我有一个运行 web 服务器的服务，该服务包含 3 个 pod，我想知道 HTTP/1.1 请求是否可以分发到 3 个 pod？

谁能帮忙澄清一下？

【问题讨论】：

一组使用单个长连接的请求将转到同一个 pod。使用不同长期连接的不同请求集可能会分发到另一个 pod。
是否有可能将一组使用单个长寿命连接的请求平均分配到不同的 pod？
连接是客户端应用程序和服务端应用程序（即pod内部容器内运行的应用程序实例）之间建立的通道，因此服务端应用程序端切换到没有意义另一个实例，而连接已经建立。如果我们要设计这样的魔法，那么 Kubernetes 必须以某种方式模拟连接需要传输到的应用程序实例的 TCP 握手（SYN、SYN-ACK、ACK），以使客户端假设它仍在与相同的服务器应用程序实例。
你知道什么情况下HTTP/1.1长连接会断开吗？
HTTP 只是 TCP 之上的另一层，因此要关闭 HTTP 连接，客户端或服务器应用程序都需要发送一个 FIN 数据包。在 HTTP 1.0 中，服务器应用程序总是会在一个请求-响应周期后发送 FIN 数据包来关闭连接。在 HTTP 1.1 中，客户端关闭连接或服务器应用程序也可以由于 KeepAliveTimeout 设置或服务器应用程序因任何原因关闭而关闭连接。

【解决方案1】：

本着StackOverflow的精神，我在这里总结一下网页：

TLDR：Kubernetes 不会对长期连接进行负载平衡，并且某些 Pod 可能会收到比其他 Pod 更多的请求。
Kubernetes 服务不存在。没有进程监听服务的 IP 地址和端口。
服务 IP 地址仅用作占位符，iptables 规则将使用巧妙的随机化将其转换为目标 pod 的 IP 地址。
来自客户端的任何连接（无论来自集群内部还是外部）都是直接与 Pod 建立的，因此对于 HTTP 1.1 持久连接，客户端与特定 Pod 之间的连接将一直保持，直到它被任一方关闭。
因此，所有使用单个持久连接的请求都将被路由到单个 Pod（在建立连接时由 iptables 规则选择），而不是负载均衡到其他 Pod。

附加信息：

根据 W3C RFC2616 (https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.3)，在客户端和服务器之间服务的任何代理服务器都必须保持从客户端到自身以及从自身到服务器的 HTTP 1.1 持久连接。

【讨论】：