JBOSS/Wildfly clustering and Kubernetes -

Question

1. 当前配置：
   • 16 个 pod 正在运行，基于 JBoss TCP 的集群，具有谷歌 ping 发现功能。容器作为有状态集部署在 Kubernetes 集群上。
2. 没有负载的初始集群按预期工作，没有任何单一问题，但是当负载增加时，观察到以下行为：
   • 在管理初始负载期间，某些 Pod 变得不可用，因此这些 Pod 会自动重新启动。
   • 重新启动这些 Pod 后，它们从新的 IP 地址开始，但相同的主机保留在 JBoss 发现文件中，其中包含旧 IP。因此，此发现文件包含具有多个 IP 地址的主机。

aaa-ops-stage-0        b6418a02-4db3-0397-ba2b-5a4a3e274560         10.20.0.17:7800        F
aaa-ops-stage-1        d57dc7b7-997f-236e-eb9f-a1604ddafc8f         10.20.0.10:7800        F
aaa-ops-stage-1        63a54371-111e-f9e9-3de5-65c6f6ff9dcd         10.20.0.16:7800        F
aaa-ops-stage-1        2dfeb3d8-6cc4-03e0-719e-b4dbb8a63815         10.20.1.13:7800        T
aaa-ops-stage-0        8053ed47-ba1b-5bb1-fcd2-a2cffb154703         10.20.0.9:7800  F
aaa-ops-stage-0        7068cd6c-ff83-dd5d-1610-e5c03f089605         10.20.0.9:7800  F
aaa-ops-stage-0        6230152a-1bc7-30ed-0073-816224bcdc26         10.20.0.14:7800        F

• 当发生这种情况并重新启动 pod 时，此 pod 的引导速度非常慢，因为它尝试将集群消息发送到上述发现文件中的所有记录。因为 aaa-ops-stage-0 有一个新的并且只有一个 IP，所以所有其他 aaa-ops-stage-0 只是超时。如果 pod 0 的重新启动次数很多，则我们在发现文件中还有更多记录。这通常也会增加每次 pod 重新启动时的启动时间，因为它会出现新的 IP，并且超时会变得更长。
• Pod 配置中实现了就绪探测，用于更改新启动的 Pod 的状态，通过这一点，负载均衡器知道 Pod 何时准备好接收请求。遗憾的是，由于上述大量超时，Pod 永远不会完全启动，因为就绪情况探测会在 60 秒不可用后重新启动 Pod。结果最终所有 Pod 都卡在重新启动循环中，服务完全停止。

我相信，如果我们有可能使用粘性 IP，并且当 pod 以 10.20.0.17 开头时，它会在重新启动期间保留此 IP。通过这样做，我们将避免上述行为，并且不会超时。没有超时将完全减少从就绪情况探测触发的重启，并且服务将保持正常运行，并且不会计量我们产生的负载。

问题是是否有可能对正在运行的 Pod 使用静态或粘性 IP 地址，以及这些 IP 是否有可能在重新启动期间持续存在？也欢迎任何其他建议！

Answer 1

有几种方法可以实现您的目标：

1 使用 kubernetes DNS 地址，而不是 K.Nicholas 所写的 IP 地址。

2 使用印花布CNI插件并使用注释：

annotations:
cni.projectcalico.org/ipAddrs: "["192.168.0.1"]"

用于指定容器的 IP 地址。 有关如何在集群中配置 Calico 的信息，请参阅文档。

顺便说一下，使用粘性 IP 地址不是一个好习惯。