重新启动工作节点上的网络接口后，流量未正确路由

Question

我们有一个有 2 个副本的 statefulset，每个 pod 上都有 Postgres 实例。一个充当主控，另一个充当副本。

暴露的服务有2个，一个是PG主服务，一个是PG副本服务。两个服务都没有选择器，并且有 2 个端点共享其相关服务的名称。

Postgres pod 的 IP 将被修补到端点，以便在访问服务时可以将流量路由到正确的 pod。

例如PG master service对应同名的endpoint，该endpoint中有运行master Postgres实例的pod的ip。

还有另一个流量 pod 将建立与主 Postgres 服务的数据库连接。

问题是：

1.traffic pod（用JDBC发出DB连接）和PG master pod在同一个worker节点（我们称之为worker1）。

2.PG副本pod在另一个worker(worker2)中。

3.运行一个测试用例：“关闭worker1上的网络接口，休眠60s，占用worker1上的网络接口”

4.然后将之前的PG replica pod提升为master，将之前的PG master pod降为replica。

5.traffic pod 的目标地址是 PG master 服务名称，但此时它连接到副本 pod。因此，流量可能会尝试以“只读”模式写入 PG 并且测试用例失败。

kube-proxy 模式是 iptables。 我们怀疑 kube-proxy 中的 iptables 没有及时更新路由信息。这意味着 iptables 可以比 Traffic pod 建立 DB 连接晚一点更新路由信息。

我们重新启动了 kube-proxy，此后该问题未再出现。那很奇怪。 所以我们希望知道它的根本原因，但还没有找到线索。

这里是 kubectl 版本：

•Kubernetes version (use kubectl version):
 Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:50:19Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
 Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"91fb1371fc570cfd3b3052012ce68fdd78b41c07", GitTreeState:"clean", BuildDate:"2020-10-28T08:47:48Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}

谢谢。

Answer 1

是吗？这只是发生的事情，没有办法以原子方式更新事物，因为世界不是事务性的。任何进行这种故障转移的主动-被动 HA 系统都会有一段时间系统不收敛。重要的是 Postgres 本身永远不会有多个主节点。它可以少于一个，但永远不会更多。听起来您可以正常工作，降级的副本将处于只读模式，并且发送给它的任何写入查询都会收到错误。