kubernetes - kube-proxy 如何处理 Pod 之间到 Service 的持久连接？

Question

我见过这样的场景:来自一个工作负载的请求发送到另一个工作负载的 ClusterIP 服务，但没有设置相关性，只会被路由到关联 pod 的子集。此服务的 Endpoints 对象确实显示了所有 pod IP。
我做了一个小实验来弄清楚发生了什么。
实验
我将 minikube 设置为具有 3 个副本的“路由器”工作负载，将请求发送到同样具有 3 个 pod 的“后端”工作负载。路由器只是向服务名称发送请求，如 http://backend .
我通过 http://$MINIKUBE_IP:$NODE_PORT 向路由器服务发送了 100 个请求，因为它暴露为 NodePort服务。然后我观察了哪些后端 pod 实际处理了请求。我多次重复这个测试。
在大多数情况下，只有 2 个后端 pod 处理任何请求，偶尔会出现所有 3 个都处理的情况。在这些实验中，我没有看到所有请求都发送到一个的地方，尽管我在 AKS 中运行其他测试之前已经看到它发生了。
这使我得出这样的理论，即路由器与其连接的后端 Pod 保持持久连接。鉴于有 3 个路由器和 3 个后端，所有 3 个路由器“坚持”到一个后端的可能性为 11%，在 3 个路由器之间，它们坚持到其中的 2 个后端的可能性为 67%，每个路由器有 22% 的可能性路由器坚持不同的后端 pod(1 对 1)。
这是路由器到后端连接的一种可能组合(共 27 种):

禁用 HTTP Keep-Alive
如果我使用 Transport在路由器的 http 客户端中禁用 HTTP Keep-Alives，然后我向路由器发出的任何请求都会根据需要在每次测试运行时均匀分布在不同的后端之间。

client := http.Client{
    Transport: &http.Transport{
        DisableKeepAlives: true,
    },
}
resp, err := client.Get("http://backend")

所以这个理论似乎是准确的。但这是我的问题:

使用 HTTP KeepAlive/持久连接的路由器实际上如何导致一个路由器 Pod 和一个后端 Pod 之间的单一连接？

有一个kube-proxy在中间，所以我希望路由器 pod 和 kube-proxy 之间有任何持久连接。以及在kube-proxy之间和后端 pod 。

此外，当路由器进行 DNS 查找时，它会找到 集群IP 每次都使用后端服务，那么如果它不知道 Pod IP，它如何“坚持”到 Pod？

使用 Kubernetes 1.17.7。

Answer 1

此 excellent article详细介绍了您的问题。
Kubernetes 服务确实不会对长期 TCP 连接进行负载平衡。
在后台服务(在大多数情况下)使用 iptables分发 Pod 之间的连接。但是iptables它不是设计为平衡器，而是防火墙。它无法进行高级负载平衡。
作为弱替代iptables可以以一定的概率创建(或不创建)与某个目标的连接 - 因此可以用作 L3/L4 平衡器。这个机制是什么kube-proxy使用有点模仿负载平衡。

Does iptables use round-robin?

No, iptables is primarily used for firewalls, and it is not designed to do load balancing.
However, you could craft a smart set of rules that could make iptables behave like a load balancer.
And this is precisely what happens in Kubernetes.

If you have three Pods, kube-proxy writes the following rules:

• select Pod 1 as the destination with a likelihood of 33%. Otherwise, move to the next rule
• choose Pod 2 as the destination with a probability of 50%. Otherwise, move to the following rule
• select Pod 3 as the destination (no probability)

What happens when you use keep-alive with a Kubernetes Service?

Let's imagine that front-end and backend support keep-alive.
You have a single instance of the front-end and three replicas for the backend.
The front-end makes the first request to the backend and opens the TCP connection.
The request reaches the Service, and one of the Pod is selected as the destination.
The backend Pod replies and the front-end receives the response.
But instead of closing the TCP connection, it is kept open for subsequent HTTP requests.
What happens when the front-end issues more requests?
They are sent to the same Pod.

Isn't iptables supposed to distribute the traffic?
It is.
There is a single TCP connection open, and iptables rule were invocated the first time.
One of the three Pods was selected as the destination.
Since all subsequent requests are channelled through the same TCP connection, iptables isn't invoked anymore.

此外，说 也不完全正确。 kube-proxy 在中间 .
不是 - kube-proxy本身不管理任何流量。
它所做的一切 - 它创建了 iptables 规则。
它是 iptables谁实际聆听、分发、执行 DNAT 等。
类似问题 here .