我不确定Ping是否是一个好主意。您不关心服务器的一般状态;你关心它是否能接收连接。
活动探测器有一个超时，所以将来当您启动一个新的副本时，有状态集中的新pod可能会在等待复制结束时失败。
您应该使用rs.status（）并获取“myState”字段。

• myState* 是0-10之间的整数标志。有关所有可能的状态，请参见this。

如果由于某种原因，rs.status（） 命令失败，这意味着ping也会失败。
然而，成功的ping并不意味着服务器已经准备好接收连接和提供数据，这才是您真正关心的。

探针

启动探针，myState等于1或2

这意味着启动探测器将耐心等待，直到服务器准备就绪，无论它是主服务器还是副本服务器。

就绪探测，myState等于1或2

这意味着，无论何时副本需要回滚或正在恢复，或者无论 mongod 决定它还没有准备好接受连接或提供数据，这都会让Kubernetes知道这个pod还没有准备好，并将请求路由到sts中的其他pod。

Livenes probe，myState不等于6、8或10

这意味着，除非服务器状态为UNKOWN、DOWN或REMOVED，否则Kubernetes将假定此服务器处于活动状态。
让我们测试一个场景！

• sts启动，第一个pod处于STARTUP，myState = 0
• 启动探测等待
• 第一个MongoDB节点就绪，myState = 1
• 启动探针最终通过。现在准备和活性探针开始行动
• 触发新副本，第二个pod处于STARTUP，myState = 0
• 新的复制品成功地加入集合。myState = 5
• 新的复制品准备就绪。myState = 2
• 启动探针最终通过。现在准备和活性探针开始行动
• • 该行动了 *
• 一个修改了数百份文件的大规模操作在主系统上被回滚
• 第二个pod现在处于ROLLBACK，myState = 9，就绪探测失败。第二个pod现在未就绪
• 所有连接现在都发送到PRIMARY
• 第二个pod已完成回滚
• 第二个pod现在作为SECONDARY返回，myState = 2，活动探测成功，pod返回READY状态
• MongoDB数据库管理员搞砸了，并发出了一个命令，从复制集中删除了辅助数据库，myState = 10
• liveness探测失败，Kubernetes杀死pod
• sts想要两个复制品并再次启动第二个分离舱。。

All good：）