JBOSS / Wildfly集群和Kubernetes --Java 学习之路

当前配置：
正在运行的pod，基于JBoss TCP的群集，带有谷歌ping发现 . 容器在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是否可能在重启期间保持不变？任何其他建议也是受欢迎的！

1 回答

0
实现目标的方法很少：

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

2使用Calico CNI plugin并使用注释：
```
annotations:
        cni.projectcalico.org/ipAddrs: "[\"192.168.0.1\"]"
```
用于指定pod的IP地址 . 有关如何在群集中配置Calico的信息，请参阅documentation.

顺便说一句，使用粘性IP地址不是一个好习惯 .
回复于 2024-05-18T15:36:02+08:00

JBOSS / Wildfly集群和Kubernetes -

1 回答

相关问题