在Kubernetes中部署一个点燃集群，我解决了阻止集群成员加入该组的问题。如果我使用readinessProbe和livenessProbe，即使延迟低至10秒，它们也不会相互连接。如果我删除这些探针，他们会发现彼此都很好。
所以，我的问题是：您是否可以使用这些探针来监控节点运行状况，如果是，那么适当的设置是什么。最重要的是，无论如何，对Ignite来说什么是好的，快速的健康检查？
答案 0 :(得分：0)
<强>更新
我想我会留下以下逻辑来自我修复任何分段问题，但希望它不会经常被触发。
原始回答：
我们遇到了同样的问题，我认为我们有一个可行的解决方案。 Kubernetes发现spi会在服务准备就绪时列出服务。
这意味着如果在启动时没有现成的pod，则点燃实例都会认为它们是第一个并创建自己的网格。
如果我们有一个确定的方法来失败pod，如果它们不属于“权威”网格，那么群集应该能够自我修复。
为此，我们保留对TcpDiscoveryKubernetesIpFinder的引用，并使用它定期检查点燃窗格列表。
如果实例是不包含列表中按字母顺序排列的第一个ip的集群的一部分，我们知道我们有一个分段拓扑。杀死进入该状态的pod会导致它们再次出现，查看服务列表并加入正确的拓扑。
答案 1 :(得分：0)
使用嵌入在Java spring应用程序中的Ignite，我面临着同样的问题。
正如您所说，Kubernetes readinessProbe: Deployment上的spec.template.spec.container具有副作用，可以防止Kubernetes Pod s列在相关的Kubernetes {{1} }为Service
尝试不使用任何Endpoint似乎确实更好（Ignite节点都加入了相同的Ignite群集）
然而，由于Spring尚未完全启动，因此具有在尚未准备就绪时暴露Kubernetes readinessProbe的不良后果……