在Kubernetes內部署一個點火羣集，我找到了阻止羣集成員加入羣組的問題。如果我使用readinessProbe和livenessProbe，即使延遲低至10秒，它們的節點也不會互相連接。如果我刪除這些探針，他們發現對方很好。Ignite ReadinessProbe
所以，我的問題是：你可以使用這些探測器來監視節點的健康狀況，如果是的話，什麼是適當的設置。最重要的是，無論如何，對Ignite來說，快速健康檢查會有什麼好處？
更新：
我想我會在下面的邏輯離開自愈任何分割問題，但希望它不會被經常觸發。
原來的答覆：
我們有同樣的問題，我認爲我們有一個可行的解決方案。 Kubernetes發現spi在服務準備就緒時列出服務。
這意味着，如果在啓動時沒有準備好的容器，點燃實例都認爲它們是第一個並創建自己的網格。
如果我們有一種確定性的方法來確認pod失敗，如果它們不是「權威」網格的一部分，那麼集羣應該能夠自我修復。
爲了做到這一點，我們保留對TcpDiscoveryKubernetesIpFinder的引用，並使用它來定期檢查點火窗格列表。
如果實例是不包含列表中按字母順序排列的第一個ip的集羣的一部分，我們知道我們有一個分段拓撲。殺死進入該狀態的豆莢會導致它們再次出現，查看服務列表並加入正確的拓撲。
我懷疑它曾經用這些探針進行過測試。你能否提供你的配置以及你需要的任何信息來澄清你正在做什麼以及哪些不能按照你的期望工作？ –
它是由apacheignite/ignite 2.0.0構建的專有鏡像，所以我不能提供太多的細節，但我可以說它是一個點陣容器集羣，它配置了幾個緩存，卡桑德拉戒指。發現服務是文檔中提供的服務的逐字拷貝，除了一些值。我只能假設發現步驟受到以下事實的干擾：節點由於讀性探測初始延遲而不能看到它自己，因此它陷入了奇怪的狀態。 – CyrusK
即使我將初始延遲下降到0，它仍然會干擾。 – CyrusK