Question

目前的配置：
- 运行16个pod，使用谷歌ping发现的基于JBoss TCP的群集。容器在Kubernetes集群上部署为有状态集。
无负载的初始集群按预期工作，没有任何单一问题，但是当负载增加时，观察到以下行为：
- 在管理初始加载期间，某些pod变得不可用，因此这些pod已自动重启。
- 重新启动这些pod之后，它们以新的IP地址开始，但是相同的主机保留在带有旧IP的JBoss发现文件中。结果，此发现文件包含具有多个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

实现目标的方法很少：

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

2使用Calico CNI plugin并使用注释：

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

用于指定pod的IP地址。有关如何在群集中配置Calico的信息，请参阅documentation.

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

JBOSS / Wildfly集群和Kubernetes -

1 个答案: