点火式ReadinessProbe

Question

在Kubernetes中部署ignite集群时，我遇到了一个阻止集群成员加入组的问题。如果我使用readinessProbe和livenessProbe，即使延迟低至10秒，它们的节点也永远不会连接在一起。如果我去掉这些探头，它们就能很好地找到对方。

因此，我的问题是:您是否可以使用这些探测来监视节点的健康状况，如果可以，什么是适当的设置。最重要的是，对Ignite来说，什么是好的、快速的健康检查呢？

Answer 1

更新：

After posting on the ignite mailing list, it looks like StatefulSets are the way to go. (Thanks Dmitry!)

我想我将在下面的逻辑中自我修复任何分段问题，尽管希望它不会经常被触发。

原始答案：

我们有同样的问题，我认为我们有一个可行的解决方案。Kubernetes发现spi在服务准备就绪时列出服务。

这意味着如果启动时没有准备好的pods，ignite实例都会认为它们是第一个，并创建自己的栅格。

集群应该能够自我修复，如果我们有一个确定性的方法来失败的豆荚，如果它们不是‘权威’网格的一部分。

为了做到这一点，我们保留了对TcpDiscoveryKubernetesIpFinder的引用，并使用它来定期检查点燃pods的列表。

如果该实例所在的集群不包含列表中按字母顺序排列的第一个ip，我们就知道我们有一个分段拓扑。杀死进入该状态的pod应该会导致它们再次出现，查看服务列表并加入正确的拓扑。

Answer 2

我也面临着同样的问题，使用嵌入到Java spring应用程序中的Ignite。

正如您所说的，Kubernetes Deployment spec.template.spec.container上的readinessProbe:有一个副作用，即阻止Kubernetes Pods在相关的Kubernetes Service上作为Endpoints列出。

尝试不使用任何readinessProbe，似乎确实工作得更好(Ignite节点都加入了相同的Ignite集群)

然而，这有一个不受欢迎的副作用，即在还没有准备好的时候暴露Kubernetes Pod，因为Spring还没有完全启动……