应使用statefulset+volumeclaimtemplates为每个pod分配独立pvc，确保readwriteonce访问模式，配合节点标识隔离数据路径，从根源避免锁冲突。
核心思路是：避免多个 pod 同时访问同一份持久卷路径，尤其要防止因异常终止导致的锁文件残留。statefulset + volumeclaimtemplates 是 kubernetes 中解决该问题的标准且最可靠方式。
用 StatefulSet 替代 Deployment 部署有状态服务
Deployment 的 Pod 是可互换的，所有副本默认挂载同一个 PVC（或通过 subPath 共享 PV），极易引发锁冲突（如 Ignite 的 lock 文件、Redis 的 appendonly.aof 写锁、MySQL 的 ibdata 文件竞争）。而 StatefulSet 为每个 Pod 分配唯一序号（如 mysql-0、mysql-1），配合 volumeClaimTemplates 可自动为每个 Pod 创建独立 PVC 和底层 PV，从根源上实现存储隔离。
- 每个 Pod 拥有专属 PVC，不会与其他实例争抢同一卷路径
- PVC 名称按规则生成（如
www-web-0），绑定关系稳定可追溯 - 滚动更新时，Pod 按序号逆序终止（
mysql-1→mysql-0），新 Pod 启动前旧 Pod 已释放锁和资源
确保存储访问模式与工作负载匹配
检查 PVC 的 accessModes 是否合理。对大多数单实例有状态服务（MySQL、PostgreSQL、Redis 主节点、Ignite Server），必须使用 ReadWriteOnce（RWO），禁止配置为 ReadWriteMany（RWX）并让多个 Pod 挂载同一卷——这是锁死的常见源头。
-
ReadWriteOnce：仅允许单节点上的单个 Pod 挂载，天然规避跨 Pod 锁竞争 - 若误配
ReadWriteMany（如 NFS 或某些云盘支持），需立即修正 PVC 并重建 StatefulSet - 确认 StorageClass 的 provisioner 能正确供应 RWO 类型卷（例如 AWS EBS、Azure Disk、GCP PD 默认即 RWO）
清理残留锁文件需谨慎操作
当 Pod 异常终止（如节点宕机、OOMKill）后重启失败，日志出现 Unable to acquire lock to file，说明旧锁文件仍存在。此时不能直接进节点删文件，而应先确认锁是否真实“僵死”：
- 执行
kubectl get pod -o wide查看该 Pod 是否已调度到其他节点；若原节点仍有残留容器进程，先清理 - 通过
kubectl exec -it <pod-name> -- ls -l /path/to/lock/dir</pod-name>进入新 Pod 确认 lock 文件是否存在且无进程持有 - 仅在确认无活跃进程占用时，才通过
kubectl exec删除 lock 文件（如rm /ignite/work/db/node00-/lock） - 更安全的做法是：缩容 StatefulSet 到 0，等待所有 PVC/PV 清理完成，再重新扩容
应用层适配：启用唯一实例标识与本地路径隔离
部分中间件（如 Apache Ignite、Elasticsearch、ZooKeeper）需主动区分节点身份。即使用了 StatefulSet，若所有 Pod 都往同一子路径（如 /data）写数据，仍可能锁冲突。应在容器启动命令或配置中注入 Pod 序号，实现路径分离：
- 在容器内用
hostname或DOWNWARD_API获取metadata.name，拼接出唯一工作目录（如/data/$(hostname)） - Ignite 示例：设置 JVM 参数
-DIGNITE_WORK_DIR=/ignite/work/$(hostname)，使 lock 文件落在不同子目录 - MySQL/Redis 虽通常单实例，但若做多副本集群，也应为每个实例分配独立数据目录，而非共享 volumeMounts 下的同一 mountPath
