K8s自动扩缩容场景下MongoDB副本集动态连接串配置问题

两个核心问题导致你遇到主节点切换后无法写入的故障：

1. 连接串种子节点配置错误。MongoDB驱动的副本集自动发现逻辑，是先连接你传入的种子节点，拉取副本集内部保存的成员列表，之后根据拓扑信息自动路由读写请求、感知主节点切换。你之前只配置了mongo-0.mongo.mongo.svc.cluster.local单个种子节点，一旦这个节点出现故障、网络分区，驱动根本无法连通任何节点获取最新的副本集拓扑，自然找不到新当选的主节点mongo-2，直接抛出not primary错误。所谓“带replicaSet参数就可以自动发现所有节点”的说法，前提是你传入的种子节点列表里至少有一个节点在线可达。
2. 架构配置存在本质错误。MongoDB副本集不支持直接通过HPA扩缩容。副本集成员的增删必须主动执行rs.add()/rs.remove()命令修改副本集配置才会生效，直接调整StatefulSet副本数拉起的新Pod，不会自动加入副本集；缩容时直接删除Pod，还会在副本集配置里残留无效节点，触发选举异常、脑裂等问题。你现在使用的cvallance/mongo-k8s-sidecar本身对节点动态增删的处理存在延迟，多数版本不会主动清理缩容后的无效节点配置，长期运行必然出现拓扑不一致的问题。

先修正扩缩容逻辑 #

• 如果只是用副本集实现高可用，直接删除HPA配置，将副本集固定为3节点即可。MongoDB副本集的核心作用是高可用冗余，不是水平扩容，副本数超过3个之后，多出来的节点只会增加主节点写入时的数据同步压力，不会提升写入性能，生产环境用3节点副本集完全可以满足绝大多数场景需求。
• 如果确实有动态调整副本数的需求，不要用原生HPA直接操作StatefulSet，替换为专门的MongoDB Operator（比如MongoDB官方社区Operator、KubeDB），Operator会在副本数变化时主动执行副本集配置修改，保证新节点正常加入、旧节点被正确剔除，避免拓扑和实际运行节点不一致。

配置适配动态场景的连接串 #

不要硬编码单个Pod的域名作为种子，直接使用StatefulSet绑定的Headless Service作为种子地址，连接串配置如下：

mongodb://mongo.mongo.svc.cluster.local:27017/webhook?replicaSet=rs0&readPreference=primary&connectTimeoutMS=3000&serverSelectionTimeoutMS=5000&retryWrites=true

这个方案的原理：

• 你在StatefulSet中配置的serviceName: mongo就是对应的Headless Service，解析该域名会返回所有匹配标签的MongoDB Pod IP，相当于自动给驱动提供了全量在线节点作为种子，不需要硬编码mongo-0/mongo-1这类固定Pod域名，不管副本数怎么调整，只要Pod处于运行状态，就会被Headless Service纳入解析列表，驱动总能找到可达的节点拉取最新拓扑。
• 驱动连通任意一个节点后，会自动拉取副本集成员列表，实时感知主节点切换，自动将写入请求路由到新的主节点，不会再出现找不到主节点的问题。

必要的校验项 #

• 确认MongoDB启动参数中--bind_ip配置为0.0.0.0，避免跨Pod访问被拦截。
• 执行rs.config()查看副本集成员配置，确认每个成员的host字段都是可被业务Pod解析的集群内域名（格式为mongo-x.mongo.mongo.svc.cluster.local:27017），如果这里配置的是Pod IP，Pod重建后IP变化会导致驱动连接失败。
• 给驱动配置合理的超时与重试参数，MongoDB主节点选举通常有3-10秒的不可用窗口，开启retryWrites后驱动会自动重试写入请求，避免选举窗口期的报错直接透传到业务层。

注意：硬编码多个固定Pod域名的方式仅适用于副本数固定的场景，完全无法适配动态扩缩容需求，使用Headless Service作为种子是K8s上部署有状态集群的标准方案，MongoDB、Kafka、ZooKeeper等有状态服务都采用这种方式实现客户端动态发现。

内容的提问来源于stack exchange，提问作者user7649760