StatefulSet 部署 MongoDB 副本集必须依赖 volumeClaimTemplates 自动创建 PVC 并绑定 PV，手动 shell 脚本挂载既因容器隔离和权限限制而无效，又会破坏 Pod 序号与 PVC 的强绑定关系，导致数据不一致、DNS 解析失败及滚动更新异常。
StatefulSet 部署 MongoDB 副本集不能靠“写个挂载脚本”解决——PV 必须由 StatefulSet 自动绑定，手动挂载脚本既无效也不可控。
为什么不能用 shell 脚本挂载 PV 到 MongoDB 容器
StatefulSet 的 Pod 生命周期和存储绑定完全由 Kubernetes 控制器管理：volumeClaimTemplates 会为每个 Pod 自动生成 PersistentVolumeClaim，并由 PVC 触发 PV 绑定。你在容器里执行 mount 或写脚本挂载宿主机路径，不仅会被容器 rootfs 隔离（根本不可见），还会绕过 Kubernetes 存储编排逻辑，导致副本间数据不一致、重启后 PVC 丢失、滚动更新失败。
- Pod 内无权执行
mount（默认被CAP_SYS_ADMIN限制） - 宿主机路径（如
/data/mongo）在不同节点上不共享，违背副本集高可用前提 - StatefulSet 的序号标识（
mongo-0、mongo-1）与 PVC 名称强绑定，手动干预会破坏这一映射
正确做法：用 volumeClaimTemplates + headless Service 构建副本集
核心是让每个 Pod 拥有独立、可持久、可预测的存储，并通过无头 Service 实现 DNS 可解析的稳定网络身份。
-
serviceName字段必须指向一个headless Service（即clusterIP: None），否则 Pod DNS 名（如mongo-0.mongo-svc.default.svc.cluster.local）无法解析 -
volumeClaimTemplates中的storageClassName需与集群中实际存在的 StorageClass 名称一致（如standard、managed-premium），否则 PVC 会处于Pending状态 - MongoDB 启动命令中必须显式指定
--replSet和--bind_ip_all，且初始化需在所有 Pod Ready 后，通过kubectl exec连接mongo-0执行rs.initiate()和rs.add()
示例关键片段：
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mongo
spec:
serviceName: "mongo-svc" # 必须匹配 headless Service 名
replicas: 3
template:
spec:
containers:
- name: mongo
image: mongo:6.0
args:
- "--replSet"
- "rs0"
- "--bind_ip_all"
ports:
- containerPort: 27017
volumeMounts:
- name: mongo-persistent-storage
mountPath: /data/db
volumeClaimTemplates:
- metadata:
name: mongo-persistent-storage
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 10Gi
常见失败现象及定位方式
部署后 Pod 卡在 Pending 或 ContainerCreating 是最典型问题，别急着改脚本，先查底层资源状态。
- PVC 处于
Pending：运行kubectl get pvc，看STATUS列；再执行kubectl describe pvc，检查Events中是否提示no persistent volumes available或storageClassName does not match - Pod 处于
Init:0/1或反复重启：用kubectl logs查 MongoDB 启动日志，常见错误是--previous Failed to connect to 127.0.0.1:27017（说明副本集未初始化）或Permission denied（宿主机插件如 hostpath-provisioner 未正确配置 SELinux 上下文） - 副本集成员显示
STARTUP2卡住：说明 DNS 不通，执行kubectl exec mongo-0 -- nslookup mongo-1.mongo-svc，验证能否解析到对应 Pod IP
真正需要你写的“脚本”只有一行初始化命令
等全部 3 个 Pod 进入 Running 状态且 kubectl get pvc 全部为 Bound 后，只需执行一次初始化：
kubectl exec mongo-0 -- mongosh --eval "
rs.initiate({
_id: 'rs0',
members: [
{ _id: 0, host: 'mongo-0.mongo-svc.default.svc.cluster.local:27017' },
{ _id: 1, host: 'mongo-1.mongo-svc.default.svc.cluster.local:27017' },
{ _id: 2, host: 'mongo-2.mongo-svc.default.svc.cluster.local:27017' }
]
})"
注意：mongosh 是 MongoDB 6+ 推荐的 shell，旧镜像用 mongo；DNS 名必须严格匹配 headless Service 名和命名空间；任意成员地址写错，都会导致初始化失败且需删除 rs0 数据目录重试。
StatefulSet 的存储可靠性不取决于你写了多少挂载脚本，而取决于 PVC 绑定是否成功、StorageClass 是否提供真实持久化、以及副本集初始化时各成员网络是否可达——这三者缺一不可，其余都是干扰项。
