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

Question

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

场景 1： 我执行 CURL 命令来访问服务。在执行 curl 命令时，我引入了 Pod-1 的就绪失败。我看到没有新请求发送到 Pod -1。这很好

场景 2： 我有 Java 客户端并使用 Apache Commons Http 客户端库来启动与 Kubernetes 服务的连接。连接建立并且工作正常。当我介绍 Pod-1 的就绪失败时，问题就来了。我仍然看到客户端仅向 Pod-1 发送请求，即使服务只有 Pod-2 的端点。

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

有人能解释一下为什么按照上面描述的方式工作吗？？

Answer 1

kube-proxy（或者更确切地说是它生成的 iptables 规则）在更改端点映射时故意不关闭现有的 TCP 连接（这是失败的就绪探测将触发的）。多年来，在许多票证上对此进行了很多讨论，但对于是否应该改变行为几乎没有达成共识。现在你最好的选择是使用 Ingress Controller 来处理 HTTP 流量，因为它们都会实时更新并绕过 kube-proxy。您还可以在响应中发回 Keep-Alive 标头，并在 N 秒或请求后终止持久连接，但这只会缩小错误窗口。