就绪探测和Apache通用Http客户端

Question

我有一个配置了2个后端PODS的服务的简单OpenShift设置。PODS已配置就绪探头。该服务通过NodePort公开。所有这些配置都很好，它可以像预期的那样工作。一旦就绪探测失败，服务就会将POD标记为不可达，并且任何新请求都不会路由到pod。

场景1:执行CURL命令访问服务。在执行curl命令时，我引入了Pod-1的就绪故障。我发现没有新的请求被发送到Pod -1。这很好。

场景2:我有一个Java客户端，并使用Apache Commons Http客户端库发起到Kubernetes Service的连接。连接已建立，并且工作正常。当我介绍Pod-1的就绪故障时，问题就来了。我仍然看到客户端只向Pod-1发送请求，即使服务只有Pod-2的端点。

我的直觉是，当通过NodePorts公开时，HttpClient使用持久连接和服务，Http连接的目的地地址是POD-1本身。因此，即使就绪探测失败，它仍然会向Pod-1发送请求。

有人能解释一下为什么他们以上述方式工作吗？

Answer 1

kube-proxy (或者更确切地说，它生成的iptables规则)在更改端点映射(这是失败的就绪探测将触发的内容)时，故意不关闭现有的TCP连接。多年来，这在许多罚单上讨论了很多，但对于是否应该改变这种行为，通常几乎没有达成一致意见。现在，您最好的选择是使用一个入口控制器来处理HTTP流量，因为这些都是实时更新并绕过kube-proxy的。您还可以在响应中发回一个Keep-Alive标头，并在N秒或请求后终止持久连接，尽管这只会缩小不好的窗口。