1

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

有人可以解释为什么他们按照上面描述的方式工作吗？

4

1 回答 1

1

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

于 2020-05-04T03:38:49.283 回答