StatefulSet 更适合 MongoDB 副本集，因其提供固定 Pod 名、有序启动、Headless Service 可解析 DNS、独立 PVC 绑定；Deployment 无法满足稳定网络标识、独立存储和启动顺序要求，易致初始化失败或数据损坏。
StatefulSet 为什么比 Deployment 更适合 MongoDB 副本集
MongoDB 副本集要求每个节点有稳定网络标识（如 mongo-0.mongo）、独立持久化存储、启动顺序可控——这些 Deployment 根本做不到。StatefulSet 自动提供：固定 Pod 名（mongo-0、mongo-1）、有序滚动更新、DNS 可解析的 Headless Service，以及与 PVC 的一一绑定关系。
常见错误是直接套用 Deployment 模板，结果副本集初始化失败，日志里反复出现 no reachable servers 或 host not found in replica set。根本原因是 Pod IP 频繁变动、无固定 DNS 名、多个 Pod 共享同一份 PVC 导致数据损坏。
- 必须搭配 Headless Service（
clusterIP: None），否则mongo-0.mongo解析不到 - 每个
StatefulSetPod 必须声明独立的volumeClaimTemplates，不能复用同一个 PVC - 初始化时需等待所有 Pod 进入
Running且Ready状态，再执行rs.initiate()，否则副本集成员无法互相发现
如何正确配置 MongoDB 的 PVC 和 StorageClass
PV 和 PVC 不是配对完就万事大吉——MongoDB 对磁盘 I/O 敏感，尤其写密集场景下，慢盘会拖垮整个副本集心跳检测，导致频繁主从切换。
常见坑是用默认 StorageClass（比如 standard 在 GKE 上是 HDD），或在本地开发环境用 hostPath，结果 mongod 启动卡住，日志报 Failed to create directory /data/db: Permission denied（实际是挂载后权限不对）。
- 生产环境务必使用支持
ReadWriteOnce且低延迟的StorageClass，例如 AWSgp3、Azuremanaged-premium -
volumeClaimTemplates中的accessModes必须是["ReadWriteOnce"]，MongoDB 不支持共享写入 - 若用
hostPath测试，需在容器内显式chown -R mongodb:mongodb /data/db，否则因 UID 不匹配无法写入 - 建议为
data和journal分开挂载（通过多个volumeMounts），但多数云厂商 PVC 不支持子路径隔离，实际常共用一个 PVC
副本集初始化脚本必须绕过 Kubernetes 启动顺序陷阱
Kubernetes 保证 mongo-0 先启动，但不保证它已监听 27017 或能响应 mongosh 连接——直接在 initContainer 里执行 rs.initiate() 十有八九失败。
典型现象：Pod 日志显示 waiting for primary，kubectl exec mongo-0 -- mongosh --eval "rs.status()" 报 not master and slaveOk=false，其实是 mongo-1 和 mongo-2 尝试连接 mongo-0 时，后者 MongoDB 进程还没 ready。
- 不要在
initContainer中调用rs.initiate()；改用主容器内的livenessProbe或单独的postStarthook - 推荐做法：用一个轻量
job在所有 Pod Ready 后执行初始化，命令类似mongosh "mongodb://mongo-0.mongo:27017" --eval "rs.initiate({ _id: 'rs0', members: [{ _id: 0, host: 'mongo-0.mongo:27017' }, { _id: 1, host: 'mongo-1.mongo:27017' }, { _id: 2, host: 'mongo-2.mongo:27017' }] })" - 务必在
mongod启动参数中加--replSet rs0和--bind_ip_all（或明确列出集群内 DNS 名），否则副本集成员无法握手
连接应用时别把 mongo-0.mongo 当成固定入口
应用代码里硬写 mongodb://mongo-0.mongo:27017 是危险操作——它只是副本集的一个节点，不是路由入口。一旦 mongo-0 降级为 Secondary，应用直连就会读不到最新写入（除非显式设 readPreference=primaryPreferred）。
更严重的是，如果应用只连单个节点，Kubernetes 滚动更新时 Pod 重建，连接池会断开重连，而客户端若没正确处理 TopologyChangeEvent，可能卡死或持续报 Connection refused。
- 应用应连接 Headless Service 的 DNS 名（如
mongodb://mongo.mongo.svc.cluster.local:27017），驱动会自动发现全部成员 - 连接字符串必须包含
?replicaSet=rs0，否则驱动不会启用副本集模式，故障转移失效 - Java 驱动需确保版本 ≥ 4.7，Go 驱动需启用
DirectConnection=false（默认值），否则可能跳过种子节点发现逻辑 - 测试阶段可用
kubectl run mongo-test --rm -it --image=mongo:6 -- mongo "mongodb://mongo.mongo:27017/?replicaSet=rs0"验证发现是否正常
真正麻烦的从来不是写 YAML，而是 MongoDB 副本集对网络稳定性、磁盘行为、启动时序的隐式依赖——这些在裸机上被忽略的问题，在 K8s 里会被放大成不可预测的脑裂或初始化失败。动手前先确认三点：StorageClass 的 IOPS 是否达标、Headless Service 的 DNS 能否从每个 Pod 内解析、以及你的 MongoDB 驱动是否真的理解副本集拓扑。
